Warning:
This wiki has been archived and is now read-only.
ReviewRdfMappingMay08MichaelSchneider
Action 147: Review of the RDF Mapping (by Michael Schneider, May 08)
This is my review of the RDF mapping (Action 147). It refers to the following version of the RDF mapping document:
[1]
Contents
- 1 List of bugs and suggestions
- 1.1 Old document abstract
- 1.2 Typos in sec. 1
- 1.3 Introducing term "constant" in sec. 1
- 1.4 Have the mapping table in own subsection
- 1.5 Lists as sets of objects
- 1.6 Mapping of "basic terms"
- 1.7 Datarange complements
- 1.8 n-ary Restrictions
- 1.9 Data QCRs
- 1.10 Question about Inverse property expressions
- 1.11 Question about entity annotations
- 1.12 Annotations: Single triple Axioms
- 1.13 Reverse Mapping: "should" or "must"
- 1.14 Table 3 on Ontology Headers
- 1.15 Table 4: Typo in header
- 1.16 Table 6: Proposed Rearangement
- 1.17 Sec. 3.2 typo
- 1.18 Table 8: ExpandAnnotations
- 1.19 Table 9: Ontology Annotations
- 1.20 Table 11: Typo
- 1.21 Table 16 (multi-triple axioms)
- 1.22 Removal of typed vocabulary
- 1.23 Deprecation Vocabulary
List of bugs and suggestions
Old document abstract
Consider removing / replacing this recurrent abstract:
"OWL 2 extends the W3C OWL Web ontology language with a small but useful set of features ..."
At the 2F2F it has been decided that all documents should have a boiler-plate part of the abstract that is the same across all documents.
Typos in sec. 1
Typo 1
"... let RDF(O) [be] the set of RDF triples ..."
Missing "be".
Type 2
"... by applying the reverse[-]transformation ..."
The "-" seems wrong, but I am not sure.
Introducing term "constant" in sec. 1
In the item list:
"* ct denotes an RDF literal."
I would add "(a constant)", since this term is used later several times in this document.
Have the mapping table in own subsection
In sec. 2, both the introductory stuff and the large table are at the toplevel of this section, while there is a dedicated subsection for a Annotated Axioms. I suggest to have table 1 in its own subsection (2.1).
Lists as sets of objects
Before table 1:
"In this section, T(SEQ y1 ... yn) denotes the translation of sets of objects ..."
At least in the case of sub property chains, the ordering is of relevance. So one should better talk about "sequences" instead of "sets".
Mapping of "basic terms"
In table 1, directly under the mapping of ontology headers, there is a list of expressions "C", "Class(C)", etc. They don't have a mapping on their own, but will only be mapped as a part of larger expressions, for which mappings exist. I wonder why they are listed in table 1.
These are necessary because, although they do not produce triples, they define the main node. Therefore, these have to be included in the table.
Datarange complements
That's the problem with the URI "owl:complementOf". I have sent a separate mail on this: [2].
n-ary Restrictions
There are entries of the form
SomeValuesFrom( DPE1 ... DPEn DR )
and dito for AllVauesFrom
Problem 1
I have never seen these expressions before, and I don't understand which purpose they have.
These are there in anticipation of n-ary datatypes. they have been included in the member submission, and therefore they are also present in the current version of the mapping. In any case, I do not see these as pertaining to the RDF mapping --- they are part of a larger issue of n-ary datatypes.
Problem 2
"n > 2" should probably be "n >= 2".
Problem 3
The SomeValuesFrom restriction is mapped to:
_:x rdf:type owl:Restriction . _:x owl:onProperty T(SEQ DPE1 ... DPEn) _:x owl:someValuesFrom T(DR)
This overloading of owl:onProperty will lead to problems with OWL 2 Full. If an ontology contains the above triples, then the already existing semantic condition for ordinary SomeValue restrictions will entail that the list header of the sequence (which is some bNode) is a property. It will probably be easy to create examples which show absurd consequences from this.
But there is, as always, an easy way out: Just use a different URI, e.g.:
'owl:onProperties' (plural form)
Data QCRs
The Data QCRs use the URI "owl:onDataRange" to refer to the, well, data range. On the other hand, datatype restrictions use the URI "owl:onDatatype". Was it intended to use different names?
From an OWL Full perspective, it is generally better to have different URIs for different features. However, in this particular case, sharing the URI 'owl:onDatatype' does not seem to lead to problems. In the antecedents of the respective OWL 2 Full semantic conditions, this URI will occur in the context of distinct sets of other URIs (most notably 'owl:withRestrictions' for datatype restrictions, and 'owl:qualifiedCardinality' otherwise).
DatatypeRestriction uses owl:onDatatype because it really takes a datatype, and QCRs take owl:onDataRange because they take a data range. I don't mind changing either name; however, I haven't made any changes because I wasn't sure whether the above comment actually provided an unambiguous recommendation.
Question about Inverse property expressions
There are mappings for both
PropertyAssertion( InverseOf(OP) a1 a2 )
and
InverseOf(OP)
Question: If an expression of the first form is in an OWL-DL/FS ontology: Do both mappings apply, or only the first one?
(Note: A question like this should be answered by either pointing to the place in the document, where this question gets answered, or should lead to adding an explanation in the document.)
I think the mapping is correct as it is and that the document requires no additional explanation. The operator T is applied recursively top-down. Consider now the case when it is applied to a PropertyAssertion. If the assertion is of the form PropertyAssertion( InverseOf(OP) a1 a2 ), this matches only to the second variant of the translation operator (the one that handles PropertyAssertion( InverseOf( OP ) a1 a2 )), and this version of the operator does not recursively invoke the translation of InverseOf. Hence, there is no ambiguity. I don't mind adding a commen somewhere, but the problem is that it is not clear to me where the comment should be added; furthermore, the comment should be "just apply T recursively in the way we defined it".
Question about entity annotations
Table 1 contains FS expressions such as
EntityAnnotation( Class(C) ... )
Question: Why the "Class(C)"? Is punning the reason?
Yes.
Annotations: Single triple Axioms
Typo 1
"This is the case [of] the following axioms: ..."
Shouldn't this be "for"? (I never get these things right!)
Typo 2
In the 3rd example ("n-ary datatype declaration") the owl:datatypeArity is in both cases
"n"^^xsd:positiveInteger
instead of
"2"^^xsd:positiveInteger
Wrong axiom list
The list contains:
"SubPropertyOf (with or without property chains on the subproperty)"
But currently, a sub chain expression is mapped to a multi-triple axiom.
This is btw. stated after the first example.
If I understood this comment properly, the problem is that the section was called "Axioms that Generate a Single Triple", while property chains generate more than one triple. To address this comment, I have now renamed the whole section and I have tried to make this distinction clear. Please let me know if I have misunderstood something here.
Wrong Example
I think the second example (about sub property chains) is wrong. The RDF mapping is
_:y rdfs:subPropertyOf a:hasSister _:y owl:propertyChain _:z1 ...
So I believe that an axiom annotation should simply add triples to the bNode '_:y', instead of reifying the "main triple":
_:y rdfs:comment "An aunt is a mother's sister."
This should be analog to the example in 2.1.3 ("Axioms Represented by Blank Nodes").
No, this is not how things are meant to work. The blank node _:y represents the property chain and not the actual axiom; hence, it would be incorrect to attach the annotation to _:y. The property inclusion axiom is represented by the triple (_:y rdfs:subPropertyOf other), so this is the triple that needs to be reified in order to attach the annotation to it. Now I do agree that the title of this section was misleading, so I changed it. I didn't change, however, the transformation of this axiom.
Reverse Mapping: "should" or "must"
"If a pattern contains a variable number of triples, it should be matched to the maximal possible subset of G."
I think it should be "must" in this case. :)
Table 3 on Ontology Headers
Problem 1
It should probably be stated that "k >= 0", i.e. that there don't need to be any imports triple.
I don't think so: in the forward translation it was assumed that the number of imports is arbitrary (i.e., there was no special statement that k must be larger than 0). I think this is handled also by the fact that all patterns are to be matched in the maximal way.
Problem 2
I don't quite understand how the condition is meant:
"{ G does not contain triples y z *:x y rdf:type owl:Ontology z rdf:type owl:OntologyProperty }
Is this an "anyOf" or an "allOf"? I.e. is it necessary that all these triples have to exist in order to make the ontology DL-invalid?
These triples are a part of a triple pattern that should not be matchable in G. I have tried to make this clearer by employing a different style of formatting. This side-condition solves a particular backwards compatibility problem. Imagine you have the following triples: (a rdf:type owl:Ontology), (a owl:imports b), (b rdf:type owl:Ontology). Now the problem is with the triple (b rdf:type owl:Ontology): the RDF mapping in OWL 1.0 was imprecise as to whether this triple should be placed into the RDF graph for b rather than the RDF graph for a. The side-condition in the mapping is used to exclude such triples --- that is, you should identify *:x such that no ontology property points to it.
Table 4: Typo in header
"Table 4. triples to be [D]eleted ..."
Should be "[d]eleted".
Table 6: Proposed Rearangement
I think one can have table 6, without the middle column, before table 5. In this case I think table 5 would provide all the declarations of the middle column.
Sec. 3.2 typo
"... then the ontology header and declarations [is] determined ..."
Should be "[are] determined".
Table 8: ExpandAnnotations
I had to read sec. 3.4 twice in order to (hopefully) understand the purpose of the ExpandAnnotations set in Table 8. I think it has to do with punning. There should be one sentence saying what the purpose is.
Table 9: Ontology Annotations
As far as I understand it, the ontology properties (e.g. 'owl:priorVersion') are all built-in annotation properties. So the condition
{ AP(owl:priorVersion) != epsilon }
is always true.
However, it took me some time to see this. So I suggest to say a sentence on this in the explanation of table 9.
Section 3.3 of the mapping document contains an explicit statement that AllDecl(O) contains the declarations of all built-in properties, and the functions CE, DR, OPE, DLP, and AP are initialized based on AlLDecl(O). Therefore, the above observation should be clear. I really don't know what to say here other than "just apply the mapping precisely as it has been defined."
Table 11: Typo
Right header:
"... then DR(_:x) is set to this [object property] expression."
This smells like a copy&paste error. :)
Table 16 (multi-triple axioms)
Something seems to be wrong in this table. The first row maps to
Annotation( *:y ct ) // two entries
while the third row maps to
Annotation( _:x *:y _:z ) // three entries
Removal of typed vocabulary
In the reverse mapping of sub property axioms, there is still an occurrence of a typed Functional Style expression:
SubObjectPropertyOf
Deprecation Vocabulary
I don't see how deprecation tags are mapped from FS int RDF.
The other way around, I can see mappings such as:
*:x *:y_i ct_i [ *:x rdf:type owl:DeprecatedClass ]
== RDF2FS ==>
EntityAnnotation( Class( *:x ) Annotation( *:y_i ct_i ) [ Deprecated ]
But we need to come from such entity annotations back to RDF again.
The mapping above is included just for backwards compatibility. If an OWL 2 ontology contains a deprecation, it will be serialized into RDF in the new way, as an annotation with the owl:deprecated annotation property and value "true".