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

(catching up too slow recently ...  :-/)

+1 to "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)"

BTW: some of my colleagues suggested do an "implicit recursive
import closure", by means of dereferencing (namespace) URIs used
for properties and classes (by classes, one could... in the simplest
case just mean the objects of rdf:type triples) in the graph which they
consider for reasoning, cf. [1]. If you consider a graph always
as this closure, and assume that "dereferning" the properties and  
classes
brings you to the respective ontologies defining those you don't
need a separate mechanism for merging an ontology into the named  
graph...

... now that might sound confusing, so better with an example:

in your example that would be:

  assume that the graph :p
  has the triple
    :p range :C

  and you ask the query for type triples over the graph :G1
    :s :p :o
    :p range :C

thus, the "implicit imports closure" of :G1 is
    :s :p :o

and therefore a query for type triples over the graph :G1
i.e.

    SELECT *
    FROM NAMED :G1
    FROM NAMED :p
    WHERE { GRAPH ?G { [] rdf:type :C } }

could return ?G->:G1, if we consider the semantics to consider this  
implicit imports closure.
It might sound a bit far-fetched, but this is actually useful if you  
try reasoning/querying over linked data...
... this implicit imports closure is e.g. what is used in sindice.com
(although the query language supported on sindice is far simpler than  
SPARQL)
that is, it makes sense for finding the ontologies dereferenced in Web  
documents, which
rarely use owl:imports... (hands up: "who put an owl:imports in her/ 
his foaf-file?")

best,
Axel


1.
Renaud Delbru, Axel Polleres, Giovanni Tummarello, and Stefan Decker.  
Context dependent reasoning for semantic documents in sindice. In  
Proceedings of the 4th International Workshop on Scalable Semantic Web  
Knowledge Base Systems (SSWS 2008), Karlsruhe, Germany, October 2008.
http://www.polleres.net/publications/delb-etal-2008.pdf

On 12 Oct 2009, at 14:47, Birte Glimm wrote:

> 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 22:45:50 UTC