Re: Comments on Entailment Regimes from Zhe Wu

On 8 February 2011 16:33, Matthew Perry <matthew.perry@oracle.com> wrote:
> Hi,
>
> Here are some comments from Zhe Wu.

Thanks. I comment inline below.

See
http://www.w3.org/2009/sparql/docs/entailment/xmlspec.xml
for the updated version.

Birte

> - Matt
>
> -------------------------------------------------------------------------------
> Some comments I have so far for the entailment regimes doc.
>
> Overall it is very well written.
>
> - fn: is not referenced at all. We can get rid of it.

Good point, removed.

> - in Section 1.3, ".... and is E-equivalent to AG"   We probably want to
> define E as an entailment regime.
>  Right now, it seems to come from nowhere.

Yes, that came out of context there. I added the sentence:
The SPARQL Query conditions for using a logical entailment relation E,
such as RDFS-entailment, instead of sub-graph matching for the case of
a consistent active graph are repeated below for clarity. An overview
of how the different entailment regimes satisfy these conditions
follows.
... list of conditions...


> - in the paragraph before 2.3, sentence "Under the modified condition not
> even rdf:_1 would be a solution and even the BGP ex:a  ex:b ?x . would have
> an empty solution" is a bit tricky to read (with the dot in the middle of
> the sentence).
> ==>
> "Under the modified condition, rdf:_1 would not be a solution. Further, BGP
> ex:a ex:b ?x would have no solution at all."

done

> - In the first table in Section 3
>  ... sk(P(BGP)) are ground and RDF entailed by sk(SG)
> ==>
>  ... sk(P(BGP)) are ground and RDFS entailed by sk(SG)

Hm, I think I had corrected that, but apparently not...
Done now.

> - I am a bit confused about if a SPARQL query should return a blank node
> (skolemized).
>  In 2.1, the document says "Clearly, the Skolemized blank nodes should not
> occur in query results."
>  However, in the SELECT ... COUNT(?author) example in 3.2, we are actually
> counting them.

I tried to rephrase that part in 2.1 and added also another example.
What that paragraph is meant to say is that the bnodes are to be
returned in the results and not the Skolem constants for the bnodes.
I.e.,
G: ex:s ex:p _:o
BGP: ex:s ex:p ?o
yields one solution, which is a blank node (either _:o or if the
scoping graph renamed _:o we could get another bnode), but never sk:o
(or whatever the Skolem function turns _:o into). For implementation
purposes that means that bnodes can mostly just be treated as
constants as in subgraph matching.

> - The canonicalization related discussion in 4.1 is a bit odd. Basically
>  different vendors can return different answers. What is the problem of
> enforcing a canonicalization?
>  Otherwise, we will get different number of results, different counting,
> .... Not too good for interoperability.

I am all for that, but this is a problem already relevant for SPARQL
in general as some systems load
ex:s ex:p "1.00"^^xsd:decimal
as
ex:s ex:p "1.0"^^xsd:decimal
and at the last F2F it was decided that canonicalization should not be
enforced.

Furthermore, I think the text is not actually correct in saying that
the two triples
ex:s ex:p "100.0"ˆˆxsd:decimal .
ex:s ex:p "100.00"ˆˆxsd:decimal .
would be parsed into one triple if canonicalisation is performed. I
think we would rather get two identical triples, which, however, give
just one answer as opposed to two answers if no canonicalization is
performed.

I see choices:
a) remove the D-Entailment regime entirely
b) enforce canonicalization for systems that want to do D-entailment
c) leave it as it is

a) is my favourite since D-Entailment is anyway quite meaningless
unless a datatype map is fixed. Otherwise we have one D-Entailment
system that just handles xsd:integers, another one that does only
xsd:string, others that do all of xsd, etc
b) is my next favourite
but both a) and b) will need WG consent as I understand it, which
wasn't there last time we discussed it.

> I have gone through the RL part as well. Seems fine.
>
> I haven't looked carefully into OWL 2 RDF-based semantics entailment.
>
>



-- 
Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283520

Received on Tuesday, 8 February 2011 20:08:29 UTC