Re: Review of the RDF Mapping (Action 315)

> Hi!
> 
> This is my review of the RDF Mapping. Well, not quite, there is one
> issue that I consider significant enough to have a separate mail on
> it. This mail also contains medium problems (marked by "!") and even
> somewhat serious issues (marked by "!!!"), everything else is
> non-critical. Besides these points, the document is in LC-shape.
> 
> Note: I did not look into Evren's review, so there may be overlap.
> 
> * §2.1, 1st par: The explanation there ("recursive definition") is hard
> to understand. I admit that I did not get it even after reading it a
> second time. Perhaps explain by example, or reword the text.

I'm not sure how to reword and keep both brevity and correctness.  I've
made a slight change, which might help.

> * Table 1, property restrictions: The triple order in cardinality
> restrictions is first *cardinality, second onProperty. For value
> restrictions it's the other way around. Let's have a common order: That
> of cardinality restrictions, because there the "characteristic" triple
> comes before the "boring" onProperty. Same for §3. This will also ease
> the comparison with the RDF-Based Semantics, which also uses a coherent
> ordering (I hope :)).

I've put the onProperty first, as it is common to everything, and
doesn't bury the characteristic triple in the middle.

> * §2.2, second example:
> 
>    AnnotationAssertion( a:Peter
>        Annotation( ... )
>        rdfs:label "Peter Griffin"
>    )
> 
> I think the order of the arguments is wrong: Shouldn't it be:
> 
>    AnnotationAssertion( 
>        Annotation( ... )
>        rdfs:label a:Peter "Peter Griffin"
>    )
> 
> ?

Yes, fixed.

> * §2.2, both examples: Why is the string "Peter Griffin" mapped to
> /"Peter Griffin"^^xsd:string/? Why not to a plain literal?

Yes, and should be so written.  Fixed in several places.

> * §2.3.1, 2nd par: "This is the case for the following axioms:"
> Actually, some of these axioms can also be built with complex
> class/property expressions on their LHS and RHS, and will then be mapped
> to a multi-triple RDF encoding. Thus, I suggest to say something like:
> "This [may be] the case for the following axioms:"

No.  If there a complex sub-constructs, then these triples don't count.
I've upgraded the discussion to make this clear.

> * §2.3.1, par after 1st example: duplicate "such".

Fixed.

> * §3, 1st and 2nd par: Both paragraphs speak about "ontology documents
> that can be parsed into RDF graphs". There seems to be some redundancy,
> maybe rephrasing the two paragraphs is helpful. Further, I don't know
> whether "ontology documents" should be mentioned at all, since the RDF
> mapping entirely deals with (abstract) RDF graphs.

I believe that any redundancy here is benign, and maybe useful.  The
talk about documents is to allow later talk about importing.

> * (!) §3, 3rd par: "If a triple pattern contains a variable number of
> triples, the maximal possible subset of G MUST be matched." I consider
> this statement a very important rule. Currently, it is surrounded by
> rather informal statements, so people will easily overlook it. It should
> probably be separated from the rest of the text, similar to the
> restrictions to punning in 3.2.1.

I've half-separated it, by putting the notation stuff into a separate
paragraph.  I've also added a "Note that".

> * §3.1, 1st par: The sentences misses a "." at its end.

Fixed.

> * §3.1.1, item list:
> ** Shouldn't this be an ordered list (1,2,3)?

OK.  Changed.

> ** I would say that in the 2nd item, the phrase "using an appropriate
> RDF syntax" is redundant (at least it doesn't seem to provide any
> relevant information for the rest of the document).

Agreed.  Fixed.

> * Table 4, both entries, LHS: I think there should be another constraint
> "{ k >= 0 }" to make clear that there do not need to be any import
> directives.

OK.  Added.

> * (!) Table 5, entry on "owl:Ontology": I think these triples are
> already removed in Table 4, so the entry seems redundant to me.

These are for other "ontologies", e.g., the target of imports triples.

> * (!) Table 8, and preceding text: I don't think that talking about
> "anonymous individuals" is a good idea here. This term is defined in
> Section 5 of the Structural Spec and means something different. None of
> these blank nodes are anonymous individuals, but are rather "syntactic"
> "root nodes" for connecting multi-triple encodings of language
> constructs. I currently call them "root node" in the RDF-Based
> Semantics, but I'm open for a better name.

Changed to "Reification Nodes".

> * (!) Table 10, both entries, LHS: According to the texts, "z" may be an
> IRI or a blank node. But what is with literals?

Oops.  Added literal to this mix.

> * Table 16, owl:hasKey: Is it deliberate that the sets "y1,...",
> "z1,..." and "w1,..." are not enclosed in "{ }"? Looks like a typo.

You mean in T(SEQ y1 ... yn) etc.  Yes, this is very deliberate.  These
are not sets.

> * Table 16, deprecation vocabulary: I guess that it is deliberate that
> there are no constraints such as "CE(*:x) or DR(*:x) (for
> DeprecatedClass)? Just for the case that this has been overlooked.

Hmm.  This is semi-deliberate, I guess.  It could be added, I supposed,
but the given translation picks up some RDF graphs that would otherwise
not be captured.

> * Table 16, annotation axioms (subproperty, domain, range): as for
> deprecation: There are no constraints, but I again guess that this is
> deliberate?

Annotation subproperty has the constraints.  The other two don't, as
there is no requirement that domains and ranges of annotation properties
be classes - they could be datatypes, for example, or just about
anything.

> * Table 17: The LHS of the table entry refers to "Table 17". But this
> table *is* Table 17.

Table 16!

> * (!) Table 17: The table contains the triple "s *:p o .". According to
> the conventions in §1, "o" denotes either an IRI or a blank
> node. However, literals should also be possible. I suggest to explicitly
> state this in the table, instead of introducing yet another convention
> symbol.

Fixed.

> * Text preceding Table 18: "Finally, the patterns from Table 18 are
> matched in G, the resulting axioms are added to OG." Replace the second
> "," by an "and"?

Yes, fixed.

> * Table 18: For the singleton "unionOf" and "intersectionOf" axioms, the
> LHS contains "y1", while the RHS contains "y".

Fixed.

> * (!!!) Table 18: I think that the OWL 1 RDF Mapping allows for
> AllDifferent axioms with empty and singleton sets, just as for the
> booleans and enumerations. However, Table 16 only covers cases for n >=
> 2. So there probably should be two additional mappings for these
> scenarios in Table 18 as well.

Not so.  The syntax in OWL 1 is:

fact ::= 'SameIndividual(' individualID individualID {individualID} ')'
      | 'DifferentIndividuals(' individualID individualID {individualID} ')'

> Best,
> Michael

Diffs are:

http://www.w3.org/2007/OWL/wiki/index.php?title=Mapping_to_RDF_Graphs&diff=21349&oldid=21227

peter

Received on Monday, 6 April 2009 21:51:51 UTC