Re: Review Mapping to RDF Graphs

On Mittwoch, 8. April 2009, Peter F. Patel-Schneider wrote:
> From: Markus Krötzsch <mak@aifb.uni-karlsruhe.de>
> Subject: Review Mapping to RDF Graphs
> Date: Tue, 7 Apr 2009 23:38:07 +0200
>
> > Hi Boris, hi Peter,
> >
> > below are my review comments for the RDF mapping. Overall, I found the
> > document sufficiently clear and accessible, even if some minor glitches
> > remain. My version was from this morning, so some things may overlap
> > with
> > Michael's comments.
> >
> > Cheers,
> >
> > Markus
>
> Thanks for the very detailed comments.  Here are responses to most of
> them---I'm deferring to Boris for a couple.

Great. I agree with the below comments (including the ones that say "maybe 
later" -- that's exactly what I meant to suggest with "Minor") and I am happy 
with the according changes. 

Regards,

Markus


>
> > * [Minor] Ontology O maps to RDF graph T(O), but graph G maps to
> > ontology O_G;
> > better use a consistent syntax (regarding the position of the parameter
> > O/G)?
>
> There might be a possibility to fix this post-LC, as it would just be a
> presentation change, but fixing now might require some delicate editing.
>
> > * [Editorial] Naming issues: I guess "OWL DL" should now be "OWL 1 DL"
> > (see
> > http://www.w3.org/2007/OWL/wiki/Naming).
>
> Done.
>
> > * [Editorial, minor] "word &mdash; word": AFAIK there are two ways of
> > writing dashes correctly in [typesetted] English: "word&mdash;word"
> > and "word &ndash; word" (or, in LaTeX: "word---word" or "word --
> > word").
>
> Yeah, yeah.  I'm picky about this too, but I've pretty much given up.
>
> There is quite a bit of variation on whether to use an m-dash or a
> spaced n-dash, which may be partly a difference between Cambridge style
> and Oxford style.  (I prefer Oxford---Ian, strangely enough, prefers
> Cambridge.) I wonder if W3C has a preference.
>
> > * [Minor] Section 1 and 2: Regarding the style of introducing the
> > meaning of
> > entity labels/placeholders:
> > ** Section 1 says "*:x denotes an IRI" but this is not used in Section 2
> > where
> > it says "U denotes an IRI" instead. Other notation of Section 1 (like
> > "_:x")
> > is used in Section 2, however. I see that "U" refers to the structural
> > spec
> > while "_:x" is RDF syntax; maybe introduce "*:x" only later (i.e. in
> > Sec. 3)?
>
> These are used in Section 3.  It might be better to move this bit to the
> beginning of Section 3, but I'll be lazy on this one.  :-)
>
> > ** Many other labels are used without being introduced,
> > e.g. "ontologyIRI". I
> > assume the current policy is to use unintroduced (mnemonic) identifiers
> > whenever the meaning of the identifier is clear from the context --
> > maybe one
> > could mention this.
>
> Might be better, but I think that the current situation is "good enough".
>
> > * [Minor] Section 2.1: "if the mapping of a construct refers to the
> > mapping of a subconstruct" Maybe it would be clearer to say "if the
> > mapping T(E) of a construct E is used in the position of a subject,
> > predicate or object of a generated triple".
>
> Maybe, I'm not quite convinced.  :-)
>
> > * [Editorial] Table 1 for "DisjointObjectProperties( OPE1 OPE2 )" uses
> > "op1" and "op2" in the second column where "OPE1" and "OPE2" should be
> > used.
>
> Fixed.
>
> > * [Minor] The second example in Section 2.2 is actually an example for
> > the axiom annotations introduced only in Section 2.3. Up to that
> > point, only annotations for ontologies have appeared (in Table 1). Not
> > sure if this is a real problem.
>
> This is supposed to be illustrating the mapping of the embedded
> Annotation, I think.  There is a bit of a forward reference, but not a
> true problem, as far as I am concerned.
>
> > * [Bug] Section 3: Generally, it is somewhat unfortunate that "G" is
> > both the input graph and the place where remaining triples are
> > stored. The outcome of the parsing, e.g., is denoted O_G, but G at the
> > end of the parsing is not the same as G at the beginning of the
> > parsing. So when recursively adding content to O_G while changing G,
> > the expression O_G is actually different in each loop. Similar remarks
> > apply to expressions like Decl(G) and Imp(G). I fear that this can
> > only be solved by using another G' (or whatever) for triples that
> > still require processing, although this adds more notation to the
> > document.
>
> Yeah, a cleanup might be in order.  The intent should be clear,
> however.   We'll try to figure out if a decent improvement can be made
> here.
>
> > * [Editorial] Section 3: the bullet points say "curly braces { }" but
> > "square brackets '[ ]'" -- use single quotes consistently.
>
> Fixed.
>
> > * [Bug?] "When a list pattern is matched to G, all variables yi and yj
> > with i ≠ j MUST be matched to different nodes; furthermore it MUST NOT
> > be possible to match the list pattern to two maximal subsets of G such
> > that some variable in the first pattern instance is matched to the
> > same node as some (possibly different) variable in the second pattern
> > instance." Doesn't this disallow multiple lists to have the same
> > (concrete, IRI-named) elements? I guess only list bnodes should not be
> > reused, while list members can (but the bnodes are the "xi" in this
> > pattern, not the "yi").
>
> Yes indeed.  This is fixed to use the xi, and a couple words added.
> Making it all completely formal is probably more difficulty that it is
> worth, however.
>
> > * [Bug] Section 3.1.1 state that "the triple x owl:imports *:y .  is
> > removed from G." but also that there is a precondition that "the
> > values for x and *:y have not already been considered" If it can
> > actually occur that a triple is found in the parsing for which x and
> > *:y have already been considered, then this triple is not removed. Is
> > this intended? But I guess this simply cannot occur and the
> > precondition is redundant.
>
> Hmm.  I think that the precondition is indeed redundant, but I'll defer
> to Boris on this one.
>
> > * [Bug] Section 3.1.1: "ontology document accessible from the IRI *:y
> > is retrieved [...] The document is parsed into an RDF graph G'." There
> > is some confusion of terminology here, I think: ** An "ontology
> > document" according to Syntax must represent an instance of Ontology,
> > and hence is never lacking its header.  ** Ontology documents may have
> > arbitrary encodings, so to parse them into RDF graphs, one would need
> > to apply the mapping T to the extracted ontology structure.
> >
> > But I think "parsing" here really refers to parsing an RDF syntax
> > (only RDF/XML syntax?), and the imported non-ontology document must be
> > in some RDF syntax for the further steps to be meaningful. Some
> > reference to an RDF spec for possible syntaxes and their parsing might
> > be in order.
>
> Yes.  Changed to remove "ontology" and fiddle with reference to SS&FS,
> and then everything goes through.  If the document is not in an RDF
> syntax, then the RDF parsing will fail.
>
> > * [Bug?] Related to the previous note, 3.1.1 also mentions "an
> > owl:imports triple pointing to an RDF graph G'" But the "graph" in RDF
> > seems to be what the "ontology" is in OWL, and the property really
> > points to an RDF document.
>
> graph -> document encoding, which should be adequate here.
>
> > * [Editorial] In Table 6, row 2, column 3, line 1 there is an additional
> > final
> > single quote in "*:x rdf:type owl:ObjectProperty' .'".
>
> Fixed.
>
> > * [Minor] Defintion of the set "RIND".
> > ** This notation differs from others such as Imp(G) and Decl(G) where
> > G is always included as an argument. Even if it is intended to
> > distinguish RIND from Imp() and other notation that appears in Syntax,
> > it should still depend on G.
> > ** I did not find the mnemonics of "RIND" very obvious.
> > ** It is somewhat strange that it is emphasised that RIND is initialised
> > to the empty set. Should this also be stated for Ind(G) etc. then?
>
> RIND is like CE, DR, etc.  They also don't mention G and are explicitly
> initialized.  (I'm not sure where Ind(G) appears in the mapping
> document.)
>
> > * [Minor] Section 3.2 "This section specifies [...] the set AllDecl(G)
> > of all declarations for G" This sentence is not very clear. This
> > section does not say anything more about AllDecl(G), and it certainly
> > does not specify it (indeed, it is already required initially in Table
> > 9). Maybe one could have two sentences: one saying that the section
> > defines the parsing and the resulting ontology, and another one
> > stating that AllDecl(G) is defined as in Syntax.
>
> This needs fixing, I think, but I'm deferring to Boris.
>
> > * [Editorial] Section 3.2.1 I think "map an IRI or a blank node x"
> > should be "map an IRI or blank node x".
>
> Either is acceptable, I think.
>
> > * [Minor] Section 3.2.1 "this is written as CE(x) = ε ..."  Here "this"
> > refers to a universal condition over all possible x, while the quoted
> > statement refers to only one such x.
>
> Yeah, but a bit of informality here is OK, I think.
>
> > * [Editorial] Section 3.2.2: "to each IRI or a blank node x" (remove
> > "a")
>
> Yes indeed.  Fixed.
>
> > * [Bug] Section 3.2.4: According to Syntax, no 0-ary data ranges are
> > possible, hence the cases for DataSomeValuesFrom and DataAllValuesFrom
> > in Table 13 should also require that n >= 1 like it is done in Table
> > 14 (based on Table 14 I assume that this is not silently assumed for
> > this notation).
>
> Yes.  Fixed.
>
> > * [Bug] Section 3.2.5: A similar remark applies to the last row of
> > Table 18 (oneOf with at least one member).
>
> Yes.  Fixed.
>
> > --
> > Markus Krötzsch
>
> Diffs are
>
> http://www.w3.org/2007/OWL/wiki/index.php?title=Mapping_to_RDF_Graphs&diff=
>21538&oldid=21511
>
> peter


-- 
Markus Krötzsch
Institut AIFB, Universität Karlsruhe (TH), 76128 Karlsruhe
phone +49 (0)721 608 7362          fax +49 (0)721 608 5998
mak@aifb.uni-karlsruhe.de          www  http://korrekt.org