Re: [ENT] Review comments on the SPARQL 1.1. Entailment regime document

Ivan, others,
I'll just comment on the non-RIF issues that I have addressed in the
document. I'll probably be offline until Sunday night, but I hope we
can sort out the RIF related issue soon too.

Birte

[snip]

> -----------
> Editors' note right before section 3: this editor's note was present in the previous draft and we got no comments on that from the community. As far as I know the WG is o.k. with the design choices taken by the document. I therefore wonder whether it is still relevant to keep those editors' notes...
>
> This is true for possibly other editorial notes that did appear in earlier versions.

I have now removed those that have not been changed since the last PWD.

> -----------
> Question/comment on Section 6.6.2
>
> I think I would also add some more explanation to the sentence 'Without C2 one would...'.

> My understanding is that a pure inference would generate a possible values for ?x going through all possible datatypes with their combination with facets, which would then generate an infinite number of those. But C2 restricts that to those appearing explicitly in the vocabulary. If I am mistaken, that would still include ?x/xsd:date, ?x/xsd:NMTOKEN, etc, right? Ie, this select will return a whole bunch of things...

Actually there was a mistake in the example. I now have to examples
with a bit more explanation. One example where the variable binds to
literals, which can cause infinite bindings and another example, where
the variable binds to datatypes such as xsd:integer etc.  In the later
case there are only finitely many bindings since bindings are only to
atomic values (IRIs, literals, bnodes) and complex ranges composed by
restricting an existing datatype with facets cannot be used as
binding.
The whole section was moved up to the RDF-Based Semantics regime and
is now in Sec. 5.1.

> Is that so? Maybe adding some additional explanation at that point might be useful
>
> -----------
> I am lost in Section 6.6.3. In the last part you refer to a query with two variables, ?s and ?d, and I am not sure what query you are talking about...
>
> I presume that the sparql example is simply missing?

Yes, the query was in an editor's note in the previous PWD, but didn't
get copied when to the right place in this version.

> I was thinking about SELECT ?s ?x WHERE { ?s ex:dp ?x }...

Correct. I added it and the whole section is now 6.3.2.

[snip a RIF comment]

> -----------
> Section 7.1
>
> I also have an issue with the way rif:imports is defined. The text says that the _Graph_ should contain the predicate rdf:imports. This means, if my understanding is correct, that I cannot use that in the query, ie, I cannot have a query that says
>
> SELECT *
> WHERE {
>   [] rdf:imports <...pathtoruleset...>
>   ... all kinds of patterns
> }
>
> In other words, I cannot dynamically assign rule sets to the dataset. For a user this looks like a serious restriction because that means that the dataset provider dictates the rule sets it has, rather than the user.
>
> Isn't it possible to say that the rdf:imports can also be part of the BGP and has, well, the same semantics of referring to a rule set?
>
> Actually, the same question applies to various OWL regimes, too. Can I have a [] owl:imports <...> in my BGP? Should we allow this?

I think we have discussed this already before and the BGP is really
not the place where these things should go IMO. A BGP just tests
something, either whether the triples match to the queried graph or
whether they are entailed by the queried graph. Even if you have a BGP
such as
{ [] owl:imports ?x }
the only natural interpretation is to consider that as a query that
asks whether the queried graph contains an import statement. In OWL
RDF-Based Semantics, you would get the IRIs of the imported ontologies
back because these triples are just normal triples under RDF-Based
Semantics. Under Direct Semantics you wouldn't get an answer because
such triples are non-logical and not entailed no matter which binding
you try.

What you can do in any regime is to create a new default graph that
contains the triples from all documents in the FROM part of the query.
E.g.,
SELECT ?x FROM IRI_1, IRI_2 WHERE { ?x ex:p ex:o }
uses the triples from both IRI_1 and IRI_2 to find the answers with
whatever ent. reg. is being used.

Received on Thursday, 13 May 2010 20:14:24 UTC