RE: Review of the RDF Mapping (Action 315)

Hello,

Thanks Peter for responding to this review. I've made two minor tweaks to the
document.

1. In the introduction, you added the "unless specifically overridden" clause to
the definition of the notation for various parts of RDF graphs. It seems to me,
however, that overriding notation might confuse readers. Furthermore, the only
place where overriding was taking place was in the annotations. Therefore, I've
modified the document as follows:

- I've removed the "unless specifically overridden" clause.
- I've introduced xlt as a notation for any type of node.
- I've modified the parts that refer to annotations to use the new notation.


2. I've rephrased slightly Section 2.3.1 to make it clear what is the main
triple and in which case which transformation is to be applied.


Please let me know should you find any problems in what I've changed.

Regards,

	Boris


> -----Original Message-----
> From: public-owl-wg-request@w3.org [mailto:public-owl-wg-request@w3.org] On
> Behalf Of Peter F. Patel-Schneider
> Sent: 06 April 2009 22:54
> To: schneid@fzi.de
> Cc: public-owl-wg@w3.org
> Subject: 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=213
> 49&oldid=21227
> 
> peter

Received on Tuesday, 7 April 2009 10:59:24 UTC