Re: [TF-ENT] A few comments on RDFS Entailment section

Axel,
I saw your mail late.
See below:

2009/10/6 Axel Polleres <axel.polleres@deri.org>:
[snip]
> FWIW, I think the issue of the behavior of names graphs (which I think
> is essential to have at least a word about when) aiming to make entailment
> usable in practice was already mentioned - in some disguise at [1].
>
> Say, our dataset DS1 is:
>  Default Graph: GraphFOAF, Graph1, Graph2, and any of the graphs that
> compose the default graph are also named graphs
>
> where:
>
> GraphFOAF is:
>  foaf:Person rdfs:subClassOf foaf:Agent.
>
> Graph1 is:
>  :a a foaf:Person.
>
> Graph2 is:
>  :b a foaf:Person.
>
> Query:
>
> SELECT * {?x a foaf:Agent}
>
> I assume that we agree that the answers should be
>
>  ?x = :a ?x = :b

I guess we should all agree for RDFS entailment. It is clear because
here all triples of the named graphs are also in the default graph
(the default graph is a merge of the named graphs) and you query the
default graph.

> however, this one will always have an empty result:
>
> SELECT * {GRAPH Graph1{ ?x a foaf:Agent}}
Yes.
> and I don't we how I could use the current BGP extension mechanism to change
> that
> behavior except "merging" all ontologies I want to do reasoning aobut into
> *any*
> named graph in the dataset.

Yes, as Andy also pointed out, the question is in fact answered by
12.6 and the only way to get a merge behaviour is to ask the query
processor to create that merge in a new default graph:
SELECT * FROM Graph1_IRI WHERE { ?x a foaf:Agent . }

I am totally fine with that. I would rather have problems with having
to have inferences over all graphs. It just needs clarification in the
entailment doc and references to the relevant sections in the SPARQL
1.0 doc (12.6) I think. In [1] it is acknowledged that you can do the
above, but you cannot merge ontologies (data) into a named graph. I
can see that this could be an extension, but there is enough to be
done already and this is clearly an extra feature that I would rather
not have to tackle now.

> At [1] it was proposed to parameterize the overall used ontologies with a
> language construct, but that feature which would provide a workaround for
> the problem
> didn't find much support and was dropped (It would BTW need an extension of
> the notion of Dataset, described in
> [2]). That's ok, but woud there be any other ideas how to reasonably get
> ontological
> inference into named graphs from a conceptual point of view?

If avoiding it is fine with the spec (and it is even required) we
shouldn't go there I suggest.

What is more of an issue and also mentioned by [1] is how to tell a
query processor which entailment regime it should use (and possibly
diffrent ones for different parts of the query). Maybe that is solved
my service descripions (I hope the problem goes away by not looking at
it ;-) ) or endpoint descriptions, but maybe we have to address that
at some point...

Birte

>
> best,
> Axel
>
> 1. http://www.w3.org/2009/sparql/wiki/Feature:ParameterizedInference
> 2. Giovambattista Ianni, Thomas Krennwallner, Alessandra Martello, and Axel
> Polleres. Dynamic querying of mass-storage rdf data with rule-based
> entailment regimes. ISWC 2009.
>
>
>
>



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

Received on Wednesday, 7 October 2009 15:43:14 UTC