These slides were presented @ 6th International IFIP Workshop on Semantic Web & Web Semantics and describe the SecPODE ontology and its application in the education domain.
08448380779 Call Girls In Friends Colony Women Seeking Men
Enabling Access to Web Resources through SecPODE-based Annotations
1. Enabling Access to WebEnabling Access to Web
Resources throughResources through
SecPODE-based AnnotationsSecPODE-based Annotations
Quentin Reul, and
Gang Zhao
2. SWWS 2010 2
Overview
• Motivation
• Background
– What is an ontology?
– DOGMA
• SecPODE Ontology
• Application
• Conclusion
5. SWWS 2010 5
What is an ontology?
• An ontology is a server-stored shared
agreement on the semantics of data,
processes and rules in a given domain.
• It enables concepts to be:
– Unambigous
– Findable
– Interoperable
– Modular/reusable
7. SWWS 2010 7
SecPODE Ontology (I)
• Declarative rather than procedural
• Extended to express specific types of
security policies (e.g. access control
policies).
16. SWWS 2010 16
Conclusion
• Developed an ontology of Security
Policies
• Showed how this ontology could be
used to enable interoperability
17. SWWS 2010 17
DOGMA Reference
• Spyns, P., Tang, Y., Meersman, R.: An Ontology
Engineering Methodology for DOGMA. In Journal of
Applied Ontology, 3:13-39, 2008
• Spyns, P., Meersman, R., Jarrar, M.: Data modelling
versus ontology engineering. SIGMOD Record Special
Issue on Semantic Web, Database Management and
Information Systems 31(4):12-17, 2002
• de Moor, A., De Leenheer, P., Meersman, R.: DOGMA-
MESS: A meaning evolution support system for
interorganizational ontology engineering. In: Proc. of the
14th International Conference on Conceptual Structures,
(ICCS 2006), Aalborg, Denmark.
Hinweis der Redaktion
Credential validation transforming external attributes into things that can be internally understood.
Figure 1 shows how a service requester tries to access a resource from a service provider via a Web browser. The browser sends the request to the service provider and checks whether the information received from the service requester are sufficient to gain access to the resource. Note that we assume that both services commit to SecPODE as a upper ontology even though they may commit to different domain ontologies.
DOGMA (Developing Ontology-Grounded Methods and Applications) is a formal ontology engineering framework that is not restricted to a particular representation language. The main difference to existing ontology engineering approaches (e.g. METHONTOLOGY) is the separation between the lexical representation of concepts and their semantic constraints. This separation makes reuse of plausible facts easier since agreement on domain rules is much harder to reach than an agreement on the conceptualization.
Consequently, a DOGMA inspired ontology decomposes the ontology into a lexon base and a layer of reified ontological commitments. The lexon base layer stores plausible binary fact-types, called lexons. A lexon is a natural language statement representing the relation between two concepts. Intuitively, a lexon may be read as: within the context γ, head may have a relation with tail in which it plays a role, and conversely, in which tail plays a corresponding co-role. For example, the lexon <Research, Author, writes, written by, Book> can be read as: in the context Research, Author plays the role of writes Book and Book plays the role of being written by Author. The goal of the Lexon Base is to reach a common and agreed understanding about the ontology terminology and is thus aimed at human understanding.
The Commitment Layer mediates between the lexon base and its application. It consists of a finite set of axioms that specify which lexons of the Lexon Base are interpreted and how they are visible in the committing application, and (domain) rules that semantically constrain this interpretation. For example, it allows the application owner to define the properties (e.g. transitivity) of subsumption (i.e. is-a/subsumes) within his/her application. Moreover, commitments provide mappings between the lexon base layer and the data layer (in databases).
Declarative represent the core concepts rather than the rules needed to apply them (e.g. Datalog, Jess, Lisp, Prolog, etc.).
A security policy defines a set of conditions, which are evaluated to determine a set of actions may be performed on a target. For example, an access control policy could state that only placement advisors (i.e. the condition) have the right to consult (i.e. the action) the CV of a student (i.e. the target).
The effect of a security policy provides a statement committing the system to enact the action articulated in the policy. For example, the effect of an access control policy would be to grant or deny access to a target. In distributed systems, every security policy is given an identifier (e.g. URN) to uniquely refer to it within an information system as well as a natural language description of what the policy actually does. A security policy is written by an agent (e.g. system admin) and is recorded to provide provenance.
Semantic Interoperability between a Service Provider (SP) and a Service Requester (SR).
SP and SR may use:
Same vocabulary for attributes, but different vocabulary for their values
Different vocabularies for attributes and their values
The browser sends the request to the service provider and checks whether the information received from the service requester are sufficient to gain access to the resource. Note that we assume that both services commit to SecPODE as a upper ontology even though they may commit to different domain ontologies.