Re: Re 2: [TF-ENT] Querying datasets with default plus named graphs

[snip]

>> There is issue 43 -- can we close that now?
>
> I am not entirely clear about whether that issue can be closed, admittedly.
> the issue text says:
> "Should entailment-regimes be declared over the whole dataset or individual
> graphs?"

In my understanding we are just discussion issue 43.

> Let me try to summarise the ongoing discussion here:
>
> - we seem to all agree that entailment should not imply inferences across
> graphs
agreed

> - SD currently only allows to declare the same entailment regime for each
> graph
>  on a single endpoint, since sd:supportedEntailment is declared per a
> service.
That would be fine by me, but at least Andy and users of Jena plus
maybe other woud like a more fine grained definition.

> - there are examples where people use different entailment regimes for
> different
>  graphs in the same dataset. this can not be covered by current SD
yes (BTW, for OWL even different entailment regimes don't help you
finding direct sub-/superclasses. OWL reasoners usually support
queries for direct sub-/superclasses, but that would not be accessible
with SPARQL. )

> - Do we all need to extend SD here? Should it allow to declare different
> entailment
>  regimes for different graphs in the default dataset of the service?

If we go that way, then I think we would need something like a default
entailment regime (which could be the one as specified currently in
the SD doc). For example, if I query
SELECT ?t FROM <http://example.org/a.rdf> FROM
<http://example.org/b.rdf> WHERE { ex:x a ?t . }
then I need to know which entailment will be used. We cannot assume
that this is neccessarily simple entailment. So what we have in the SD
document is necessary. We might want to additionally allow systems to
declare that they use another entailment regime for certain (named)
graphs to cover Andy's use case. I don't see that this causes
problems, but is an addition to the service description document.

I don't see that it will cover Axel's use case of "importing" without
import statements all ontologies/RDF(S) documents that are mentioned
in the queried graph. For OWL that does not make much sense since you
have imports and I mostly use http://exampl.org/... in my ontologies
because I mostly write small test cases for our reasoner. I do not
want those to be dereferenced/lead to any imports. I personally don't
like systems that just do stuff for me that I didn't tell to do just
because the system wants to be "helpful". I can see systems offering a
switch to enable/disable such a behaviour, but I don't think this
belongs into the SPARQL spec. If the absence of imports is a serious
issue for RDF(S), I would prefer to extend the query language so that
you can state which additional vocabulary is required. This of course
adds to the tasks the WG has to do and it seems to me that this has a
bigger impact than the addition that Andy suggests for SD. For that
reason I am not pushing that.

> Before closing the issue,  I'd like to solicit a few more opinions/examples
> for that.
> (Birte? Greg? Others?)
> I am not entirely sure at this point whether this is actually a new issue
> and 43 as
> it was raised is indeed done.

It is done if we agree that SD should be extended to cover per graph
entailment regimes. If we have time during the next telecon, we can
have a strawpoll on that.

Birte

>
> best,
> Axel
>
>
>



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

Received on Sunday, 18 October 2009 20:00:35 UTC