Enabling Access to Web Resources through SecPODE-based Annotations
•Transferir como PPT, PDF•
1 gostou•323 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (8)
Semelhante a Enabling Access to Web Resources through SecPODE-based Annotations
Semelhante a Enabling Access to Web Resources through SecPODE-based Annotations (20)
Último
Último (20)
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
- 4. SWWS 2010 4 Ontology-based Interoperability Traditional Ω SysA SysC SysB SysD SysE SysA SysC SysB SysD SysE
- 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).
- 8. SWWS 2010 8 SecPODE Ontology (II)
- 12. SWWS 2010 12 Access Control Policy
- 13. SWWS 2010 13 ABAC Policy
- 14. Access Control Policy Interoperability (I) SWWS 2010 14
- 15. Access Control Policy Interoperability (II) SWWS 2010 15
- 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.
Notas do Editor
- 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.