ReviewRdfMappingMay08MichaelSchneider

From OWL
Jump to: navigation, search

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]

Michael Schneider

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 ..."
Response to the review comment:
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.

Response to the review comment:
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.

Response to the review comment:
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).

Response to the review comment:
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.)

Response to the review comment:
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?

Response to the review comment:
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.

Response to the review comment:
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").

Response to the review comment:
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.

Response to the review comment:
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?

Response to the review comment:
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.

Response to the review comment:
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.

Response to the review comment:
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".