W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > April to June 2005

Re: non-empty default graphs

From: Eric Prud'hommeaux <eric@w3.org>
Date: Fri, 3 Jun 2005 05:53:42 -0400
To: Dan Connolly <connolly@w3.org>
Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-ID: <20050603095342.GL1967@w3.org>
On Thu, Jun 02, 2005 at 11:01:51AM -0500, Dan Connolly wrote:
> 
> On Thu, 2005-06-02 at 11:06 -0400, Eric Prud'hommeaux wrote:
> > On Thu, Jun 02, 2005 at 09:29:09AM -0500, Dan Connolly wrote:
> > > Your example has two conflicting descriptions of
> > > the dataset. Pick one, please.
> 
> > Perhaps i over-abbreviated. This particular query service has no
> > innate data (unlike, say, a database of the CIA World Fact Book).
> > There are also two rdf files, lies and truth, out there on the web.
> 
> OK, now I understand which one you meant, but
> I think I've lost the point. Do you mean to argue
> for or against some design?
> 
> 
> > > > Thus, if the defualt database *may* be contiminated, you need to fall
> > > > back to the more verbose form of provenance constraint:
> > > >   SELECT ?stuff
> > > >   FROM <truth.rdf>
> > > >   FROM NAMED <lies.rdf>
> > > >   WHERE { GRAPH <truth.rdf> { <TheMoon> <isMadeOf> ?stuff } }
> 
> Is that intended to be an argument against the rq23 1.367 design?

Yes.

> It seems like just a neutral fact, from where I sit. If
> you're querying some service and you don't know what dataset(s)
> it uses, life is hard. That's what SADDLE is/was all about. I hope
> we get this round of specs done soon enough to get to that
> part of the design space.

Thesis: NamedGraphs provides a syntactic shorthand for one sort of
query (single trust model) on one sort of server (one with a
pre-existing default graph that matches the trust model of your
query). For other queries, NamedGraphs must fall back to the same
expressions used in Source (12-Oct) queries.


Named Graphs caters to the scenario where your default graph is
"trusted" and you have a set of sources that you want to query, but
you don't want their data in the default graph. For example, this
Trusted query in Named Graphs (rq23) with the default graph having a
trusted status:

  SELECT ?payee ?amount ?memo
    FROM bob:bills
    FROM NAMED bob:work
   WHERE {
	?check f:payTo ?payee .
	?check f:amount ?amount .
      GRAPH bob:work {
	?check f:reference ?ref .
	?ref f:description ?memo } }

With the Source (12-Oct) proposal, you must explicitly express your
trusted graphs in order to query isolated graphs:

  SELECT ?payee ?amount ?memo
    LOAD bob:bills bob:work
   WHERE {
      SOURCE d:bobsBills {
	?check f:payTo ?payee .
	?check f:amount ?amount } .
      SOURCE bob:work {
	?check f:reference ?ref .
	?ref f:description ?memo } }


When you introduce more trusted documents, the assumption of trusting
the default graph has a more terse syntax:

NamedGraphs (assumes bob:work is not in the default graph):
  SELECT ?payee ?amount ?memo
    FROM bob:bills bob:bank bob:credit
    FROM NAMED bob:work
   WHERE { ?check f:payTo ?payee .
	   ?check f:amount ?amount .
      GRAPH bob:work { ?check f:reference ?ref .
		       ?ref f:description ?memo } }

Source (works regardles of what's in the default graph):
  SELECT ?payee ?amount ?memo
    LOAD bob:bills bob:bank bob:credit bob:work
   WHERE {
      SOURCE ?g1 { ?check f:payTo ?payee } .
      SOURCE ?g2 { ?check f:amount ?amount } .
      SOURCE bob:work { ?check f:reference ?ref .
			?ref f:description ?memo } .
      FILTER ?g1=bob:bills || g1=bob:bank || g1=bob:credit .
      FILTER ?g2=bob:bills || g2=bob:bank || g2=bob:credit }

There is a form of NamedGraphs that works regardles of what's in the
default graph, but it behaves exactly as the Source query:
  SELECT ?payee ?amount ?memo
    FROM NAMED bob:bills bob:bank bob:credit bob:work
   WHERE {
      GRAPH ?g1 { ?check f:payTo ?payee } .
      GRAPH ?g2 { ?check f:amount ?amount } .
      GRAPH bob:work { ?check f:reference ?ref .
		       ?ref f:description ?memo } .
      FILTER ?g1=bob:bills || g1=bob:bank || g1=bob:credit .
      FILTER ?g2=bob:bills || g2=bob:bank || g2=bob:credit }

The NameGraphs trust of the default graph is only good for one trust
domain. The default trust pattern above:

   WHERE { ?check f:payTo ?payee .
	   ?check f:amount ?amount .
      GRAPH bob:work { ?check f:reference ?ref .
		       ?ref f:description ?memo } }

has two trust domains, (bob:bills bob:bank bob:credit) and
(bob:work). This query sensibly used the default graph as the merging
place for the larger set:

    FROM bob:bills bob:bank bob:credit
    FROM NAMED bob:work

If we introduce more trust domains, especially those where a merge is
expected, the syntactic advantage of the default graph diminishes:

  SELECT ?payee ?amount ?memo ?memories
    FROM bob:bills bob:bank bob:credit
    FROM NAMED bob:work bob:work-schedule bob:drinking-buddies
   WHERE { ?check f:payTo ?payee .		# default graph
	   ?check f:amount ?amount .
      GRAPH ?g1a { ?check f:reference ?ref } .	# g1* graph
      GRAPH ?g1b { ?ref f:description ?memo } .
      GRAPH bob:drinking-buddies { ?ref b:memories ?memories } .
      FILTER ?g1a=bob:work || g1a=bob:work-schedule .
      FILTER ?g1b=bob:work || g1b=bob:work-schedule }


-- 
-eric

office: +81.466.49.1170 W3C, Keio Research Institute at SFC,
                        Shonan Fujisawa Campus, Keio University,
                        5322 Endo, Fujisawa, Kanagawa 252-8520
                        JAPAN
        +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +81.90.6533.3882

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Friday, 3 June 2005 09:53:45 GMT

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