- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Thu, 23 Jan 2003 12:00:56 +0100
- To: <www-webont-wg@w3.org>
I thought I should try and list other thoughts on AS&S that I have had but not yet sent to the list. I have labelled each point from A to Q (omitting I and O) but they are not in that order. 2 Abstract Syntax ================= A: No ability to annotate annotations (see http://lists.w3.org/Archives/Public/www-webont-wg/2003Jan/0411.html ) B: A plausible change would be to permit (unnamed) descriptions as part of the ontology i.e. directive ::= 'Annotation(' URIreference URIreference ')' | 'Annotation(' URIreference dataLiteral ')' | 'Imports(' URI ')' | axiom | fact | description this would make the articulation of what are legal RDF graphs more attractive in that the current restriction that all unnamed descriptions must be used somewhere would go. This makes it more conformant with the constraints on unnamed individuals which is that they can be used once only. C: suggest replace axiom ::= 'DisjointClasses(' description { description } ')' with axiom ::= 'DisjointClasses(' description description ')' this does not impact expressive power of language, but means that the mapping rules can be set up to respect a no bnode is the object of more than triple rule, that is easy to articulate. P: suggest drop the concept of imports closure from the abstract syntax completely (see N below). I think only the RDFS version works. 3 Direct Semantics ================== D: I think the annotation entailment problem could be attacked by having separate concepts of consistency and entailment in the direct semanitcs and for the exchange syntax. This could fix the problem by defining the exchange syntax entailment as: RDF/XML-doc-A OWL DL-entails RDF/XML-doc-B if abstract-doc-A entails abstract-doc-B and RDF/XML-doc-A RDFS-entails annotations-in-RDF/XML-doc-B where abstract-doc-A is an arbitrary abstract syntax version of the imports closure of RDF/XML-doc-A. 4 Mapping ========= E: I am revising my acceptance of the description of OWL DL in RDF graphs being informative. Certain classes of developer will use this description more than the very difficult to use mapping rules. I believe that should divergences emerge that we should no prejudge whether the correct erratum is a change in the description of the RDF graphs, or a change in the mapping rules, or a change in the abstract syntax. F: The mapping rules require that XML schema datatypes be declared as rdfs:Datatype iff they are used in some part of the graph other than in a cardinality constraint. I suggest this be relaxed by: - making the mapping rule datatypeID => datatypeID rdf:type rdfs:Datatype . optional for the built-in XML Schema Datatypes - making a new mapping rule *nothing* => datatypeID rdf:type rdfs:Datatype . that can be applied any number of times This would allow the ommission of declarations for the built-in types, and not require deletion of declaration that were no longer used, or imported from a set of user defined datatypes. G: Suggest EquivalentClasses(description1 … descriptionn) => T(description<sub>i</sub>) owl:sameClassAs T(description<sub>i+1</sub>) . 1?i<n This allows blank nodes to conform with the no bnode is the object of more than one triple rule. Q: on EquivalentClasses and unmodified DisjointClasses Also unclear as to whether a blank node resulting as the main node of T(descriptioni) for one instance is the same or not as the blank node resulting for another instance. e.g. Equivalen(<a>,unionOf(<a>,<b>),<b>) could transform unionOf(<a>,<b>) into triples once (my understanding) or twice (once to say its the sameAs <a>, the second time to be the sameAs <b>). L: introduction I think this could be improved with additional text along the lines of: [[ OWL DL has semantics defined over the abstract syntax and a concrete syntax consisting of a subset of RDF graphs. Hence it is necessary to relate specific abstract syntax ontologies with specific RDF/XML documents and their corresponding graphs. This section defines a many-to-many relationship between abstract syntax ontologies and RDF graphs. This is done using a set of nondeterministic mapping rules. Thus to apply the semantics to a particular RDF graph it is necessary to find one of the abstract syntax ontologies that correspond with that graph under the mapping rules and to apply the semantics to that abstract ontology. The mapping is designed so that any of the RDF/XML graphs that correspond to a particular abstarct ontology have the same meaning, as do any of the abstract ontologies that correspond to a particular RDF/XML graph. Moreover, since this process cannot be applied to RDF graphs that do not have corresponding abstract syntax forms, the mapping rules implicitly define a set of graphs, which syntactically characterise OWL DL in RDF/XML. Since running the mapping rules backwards is difficult an alternative syntactic characterization of OWL DL in RDF graphs is also given. ]] M: rule for imports The rule Imports(URI) => U owl:imports URI . should be replaced with Imports(URI) => U* owl:imports URI . where U* is any URI This is because the subject of an imports triple: - may be any of the documents in the imports closure - may be subject to an xml:base directive - is completely ignored in OWL Full imports closure rules This probably holds with the Annotations too - that some care needs to be taken over not constraining U very much at all. This needs more thought. N: 4.2 In the first Definition: there is a sequencing problem with imports closure. How can we apply the direct imports closure to an RDF graph, without first finding its abstract form. Suggest change the hyperlink to be to the rdfs version of the concept rather than the direct version. I suspect this makes the concept of imports closure redundant in the abstract syntax (see P). (note I am suggesting the wholesale replacement of your descriptive text, and making it to be on the same normative status as the mapping rules definition of OWL DL and OWL Lite) 5: RDFS compatible ================== (I have still not properly reviewed this part) H: owl:Property is not part of the language (IOP can be part of the model theory) J: Suggest that it would be clearer, and more correct, if the following were specified as subclasses of owl:ObjectProperty owl:InverseFunctionalProperty owl:TranstiveProperty owl:SymmetricProperty I believe the current (nearly DL)-entailments hold in the RDFS version of the DL semantics unnecessarily: <owl:DatatypeProperty rdf:ID="p"> <rdfs:comment>An empty property</rdfs:comment> <rdfs:range rdf:resource="&xsd;negativeInteger"/> <rdfs:range rdf:resource="&xsd;nonNegativeInteger"/> </owl:DatatypeProperty> misentails <owl:TranstiveProperty rdf:ID="p"/> K: suggest that the third condition on OWL Full IOP = CEXTI(SI(rdf:Property)) be strengthened to IOOP = CEXTI(SI(rdf:Property))
Received on Thursday, 23 January 2003 06:01:06 UTC