W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > October to December 2009

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

From: Birte Glimm <birte.glimm@comlab.ox.ac.uk>
Date: Mon, 12 Oct 2009 14:47:02 +0100
Message-ID: <492f2b0b0910120647k79c12383g7e05575a04f34cd2@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: SPARQL Working Group <public-rdf-dawg@w3.org>
see below

2009/10/12 Ivan Herman <ivan@w3.org>:
> Just thinking a bit further...
>
> Ivan Herman wrote:
>>
>> Birte Glimm wrote:
>>> [snip]
>>>> Just for my understanding, based on your latest text (thanks for having
>>>> added it, b.t.w.!)... if I have
>>>>
>>>> <A> standing for the graph
>>>> :p rdfs:range :AA
>>>>
>>>> <B> standing for the graph
>>>> :p rdfs:domain :BB
>>>>
>>>> <C> standing for the graph
>>>> :x :p :y
>>>>
>>>> then the query:
>>>>
>>>> SELECT ?g
>>>> FROM NAMED <A>
>>>> FROM NAMED <B>
>>>> FROM <C>
>>>> WHERE {
>>>>   GRAPH ?g { :y a ?type }
>>>> }
>>>>
>>>> will return ?g-><A>, right?
>>> I would not say so. In this query you have not merged that data from
>>> the three graphs that you consider. Your query will go through all
>>> three graphs (the 2 named and the default graph) and try to find a
>>> binding for the variables in each graph without considering the data
>>> from the other graphs. I.e., you can first try ?g-><A>, but <A> alone
>>> does not provide a binding for ?type and entailment cannot do much if
>>> you have only the triple :p rdfs:range :AA. Then you go on to ?g-><B>,
>>> but again, the triples from <B> alone do not give a binding for ?type.
>>> Now you try the default graph, but that alone does also not give any
>>> type information and there is no answer for the query.
>>>
>>
>
> This may not be a problem, but I must add that if this is what we mean
> than this means RDFS reasoning on named graphs fairly difficult to use.
> What this means that a specific named graphs should always include both
> the vocabulary part _and_ the data itself (this is where the missing
> import mechanism backfires). Indeed, for the default graph, I can have
> as many FROM statements as I want, some of those getting hold of the
> vocabulary and others of the data, this is not a possibility for a named
> graph... Or do I miss something again?

That is how I also understand it. Named graphs are only useful under
entailment regimes if they include schema/TBox/vocabulary part and the
data. That is a limitation and it is hard for me to judge how big a
limitation that is in practise. Axel did send a link to some proposal
for a language extension to fix this, but this has an effect on the
general query language and is no longer limited to entailment regimes.
For a FPWD my suggestion would be to clearly identify the status as is
(limited usefulness of named graphs) and pointers to solutions how
this could be fixed (either as concrete suggestions for extension
marked at risk or just an informative suggestion of future
extensions).

> As I said, we may want to live with this, but it is worth noting to
> ourselves...

Definitely it should be noted.
Birte

> Ivan
>
> --
>
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>



-- 
Dr. Birte Glimm, Room 306
Computing Laboratory
Parks Road
Oxford
OX1 3QD
United Kingdom
+44 (0)1865 283529
Received on Monday, 12 October 2009 13:47:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:40 GMT