From: Stefan Decker (email@example.com)
Dear all, please find attached a first draft of the layer proposal with some suggestions for changes. I apologize for the late notice - I hope it will be still possible to discuss some of the language features and proposed changes, and to point out mistakes or wrong assumptions. Thanks and all the best, Stefan DAML+OIL Layer 1 1.0 Introduction ---------------- DAML+OIL has its roots in description logic. Description logics developed were developed originally from as a formalization of frame based systems. Modeling languages like UML or Entity Relationship models are quite popular (also for ontology engineering tasks). However, it is not easy to see how current DAML+OIL relates to traditional frame-like modeling languages like UML, and support for the full DAML+OIL language requires a full fledged description logic inference engine. It seems unlikely that every application will use a Description Logic Engine. Furthermore large scale applications (100k classes and more) require simple computational mechanisms. Thus large scale application needs to built upon software which is not able to support the complete DAML+OIL language. To avoid fragmentation and facilitate exchange of ontologies the definition of several layer of DAML+OIL seems worthwhile. Then language users and tool vendors are able to publish their level of compliance with the full DAML+OIL specification. In this paper we propose language features which can be supported within large-scale ontology-based applications without using an inference engines. ************************************************************* Goal of this style guide is to provide a useful language, which * allows to define simple ontologies * enables checking of integrity constraints for instances * can be deployed in large scale applications (> 100k concepts) * can be deployed by average programmers ************************************************************** Checking ontologies for inconsistencies (and thus providing the expressive power to create inconsistencies) is not our primary concern. 2.0 Layers ---------- 2.1 DAML+OIL: Level 0 Language ------------------------------ DAML+OIL is essential identical to RDF Schema ( with the semantic clarification and restrictions that DAML+OIL defined) 2.1 DAML+OIL: Level 1 --------------------- a) Class Elements contains: rdfs:subClassOf value: simple Class and simplified Property Restrictions daml:sameClassAs value: simple Class daml:equivalent value: simple Class zero or more enumeration elements. b) Property Restrictions daml:Restriction daml:toClass (with just a simple class as value) daml:hasValue daml:hasClass (with just a simple class as value) daml:cardinality daml:maxCardinality daml:minCardinality daml:cardinalityQ (with just a simple class as qualifier) daml:maxCardinalityQ (with just a simple class as qualifiers daml:minCardinalityQ c) Property elements rdf:Property rdfs:subPropertyOf (note that the handling of subPropertyOf also requires some reasoning. For compatibility purposes it seems appropriate to have subProperties in Layer 1. rdfs:domain (simple class as value) rdfs:range (simple class as value) daml:samePropertyAs daml:equivalentTo daml:inverseOf (also inverse requires some reasoning. However, daml:inverseOf seems to be to useful to be left out) daml:TransitiveProperty daml:UniqueProperty (can be used as integrity constraints) daml:UnambigousProperty (to be used as integrity constraints) d) Instances daml:sameIndividualAs daml:equivalentTo daml:differentIndividualFrom (but see Proposed Changes) 3 Removals from DAML+OIL Layer 1 -------------------------------- Complex Class Expressions Axioms ( Disjoint Declarations) 4 Proposed Changes ------------------ Unique Name Assumption ---------------------- The unique name assumption is often quite useful when dealing with large datasets. Since this will be the usual usecase of DAML+OIL Level 1, I would propose to make the unique name assumption the default case. Equivalences are usually the exception. Not adopting the unique name assumption as the default case would result in an large amount of daml:differentIndividualFrom statements. Property Restrictions ---------------------- Viewing Property Restrictions as class expressions is a unusual viewpoint for people used to object oriented or frame based modeling. The was also a major point of critique to DAML+OIL. The reference description says: "Notice that the restrictedBy element which was associated with slot-restrictions in earlier versions of the language has now been removed, since it is completely synonymous with subClassOf." While this might be true, users of OO language of a naive understanding what restrictions are, but not how it relates to subClasses. Complex Datatypes ----------------- Complex XML-Schema Datatypes currently don't have a RDF graph representation. This requires more complex processing, storage and query software. Complex Datatypes should be given a graph representation. Cardinality ----------- Since daml:cardinality is really superflous and a possible source of confusion and inconsistencies, it should is discarded from level 1. Languages Header ---------------- An an example for an ontology header look at the following definition: <Ontology rdf:about=""> <versionInfo>$Id: reference.html,v 1.10 2001/04/11 16:27:53 mdean Exp $</versionInfo> <rdfs:comment>An example ontology</rdfs:comment> <imports rdf:resource="http://www.daml.org/2001/03/daml+oil"/> </Ontology> The namespace of the current document is treated as an object on its own, but is otherwise unrelated to the defined classes and properties in this ontology. Another approach is to explicitly create an ontology object, which acts as an container object for the defined properties, classes and axioms. Using the container approach it is easy detectable, which classes belong to which ontology. This treatment is necessary, since applications don't talk about documents any more (like they would in the XML world). Instead applications talk about RDF models (= sets of statements). A common way to operate with sets of statements are set theoretic operations (union, difference, etc). So it is possible to compute the union of two RDF models representing two different ontologies, which results in another RDF model. where it is not possible to distinguish the ontologies without an explicit analysis of the namespaces of the classes.
This archive was generated by hypermail 2.1.4 : 04/02/02 EST