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



> -----Original Message-----
> From: public-rdf-dawg-request@w3.org [mailto:public-rdf-dawg-request@w3.org]
> On Behalf Of Ivan Herman
> Sent: 12 October 2009 13:12
> To: Birte Glimm
> Cc: SPARQL Working Group
> Subject: Re 2: [TF-ENT] Querying datasets with default plus named graphs
> 
> 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?

No, I don't think so. FROM and FROM NAMED have an asymmetry which is inconvenient sometimes.  FROM/FROM NAMED can't always describe the union named graph in the dataset you might want [*].  There have been proposals for FROM NAMED <..> AS <..> which allows a union named graph to be described but last time we decided not to go that far.

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

Yes, to ourselves.

> 
> Ivan

 Andy

[*] Well, it can but you might like the way to do it :-)

....





FROM NAMED <http://service?query=CONSTRUCT{?s?p?o}WHERE{{GRAPH<A>{?s?p?o}}UNION{GRAPH<B>{?s?p?o}}}>

give or take some encoding.  Makes the graph name a bit untidy.

:-)

Received on Monday, 12 October 2009 15:56:30 UTC