Re: Review Mapping to RDF Graphs

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.

> * [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

Received on Wednesday, 8 April 2009 00:14:42 UTC