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

SOURCE - Choosing what to query and querying the origin of statements

From: Dave Beckett <dave.beckett@bristol.ac.uk>
Date: Mon, 8 Nov 2004 16:28:19 +0000
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>
Message-Id: <20041108162819.760aeb09@hoth.ilrt.bris.ac.uk>

Here is a rough proposal to update to 
sections 8 and 9 with respect to the SOURCE issue.

There are plenty of issues related to this discussed already but
let's see how this does.

A quick comparision to named graphs/named containers/earlier work
- No access to individual named graphs (i.e. no SOURCE <uri>)
- It does imply dynamic RDF-merging, but it could be de-emphasised
  that it's not required at run time, but the result must be as-if
  that had been done.
- No bnode graph names (issue)
- Left out DISTINCT for now, that's a result thing



8 Choosing What to Query

A SPARQL query is against a single RDF *Query Graph*.  This graph may
be constructed through logical inference, and never materialized.  It
can be arbitrarily large or infinite.  The Query Graph is a virtual
RDF-merge operation over a set of *RDF Graphs*:

  Definition: Query Graph

  Given a set of RDF Graphs {RG1, ..., RGn}, the Query Graph QG is
  an RDF graph formed from the RDF-merge of the set {RG1, ..., RGn}.

  All of the graphs RG1...RGn have *Graph Names* GN1...GNn which are
  URI References (URIrefs) 

where RDF-merge is defined in RDF Semantics 0.3 Graph Definitions

The Query Graph can be defined in the following ways:

1) In the SPARQL query language using the FROM clause

   See below.

2) By the SPARQL protocol

   ISSUE: Depends on protocol doc.  Probably works by giving the set
   of URIrefs of the graphs? or giving a URIref for the query graph?
   or query service?

3) Against a default query graph if neither of 1) or 2) are given.
   This is application-specific.

In the SPARQL query language the FROM clause can specify the set of
graphs by either giving their names or giving the URIs for a resource
that can be used to retrieve the graph.

(Q8.1) The query

  FROM <http://www.w3.org/2000/08/w3c-synd/home.rss>
  WHERE ( ?x ?y ?z )

creates a Query Graph by using the resource at URI 
to provide RDF triples, making an RDF graph RG1.  Graph RG1 is named
by the URI and constructs a query graph from the set {RG1}.

(Q8.2) The query

  FROM <http://www.w3.org/2000/08/w3c-synd/home.rss> NAMED <http://example.org/>
  WHERE ( ?x ?y ?z )

Constructs the same query graph but names the graph RG1 <http://example.org/>

(Q8.3) The query

  FROM NAMED <http://example.org/>
  WHERE ( ?x ?y ?z )

Creates a query graph from a set of 1 graph named <http://example.org/>
The URI here is not for resource retrieval.

When multiple graphs are given in FROM, the RDF-merge of the set of
graphs is performed to create the query graph.

The query
  FROM <uri1>, <uri2>
  WHERE ( ?x ?y ?z )

creates a query graph from the RDF-merge from the set of graphs {RG1, RG2} 
  RG1 is the RDF graph formed by retrieving the resource at uri1 and
    named uri1
  RG2 is the RDF graph formed by retrieving the resource at uri2 and
    named uri2

A SPARQL implementation MAY not support graph names in which case the
queries that use only the NAMED keyword will fail - Q8.3

  Possible extension:

  Allow graphs with a local name (blank node label)

    SELECT *
    FROM NAMED _:a, NAMED _:b
    WHERE ( ?x ?y ?z )

  rather than relying on the application-specific choice 3) above.

  However details below would have to be changed to forbid returning
  the blank nodes of the names in results.

9 Querying the Origin of Statements

While the RDF data model is limited to expressing triples with a
subject, predicate and object, many RDF data stores augment this with
a notion of the source of each triple.  Typically, implementations
associate RDF triples or graphs with a URI specifying their real or
virtual origin.  The SOURCE keyword allows you to query or constrain
the source of the following triple pattern or nested graph
pattern. The general form of the SOURCE query is:

 SOURCE ?var (?s ?p ?o)

When SOURCE ?var is given before a triple, the variable will be bound
to all of the known *Graph Names* for that triple.  A data store that
does not support graph names SHOULD provide no binding for the SOURCE

  D9.1 Data:

  Graph G1 named <aliceFoaf.n3>
  @prefix  foaf:  <http://xmlns.com/foaf/0.1/> .

  _:1 foaf:mbox <mailto:alice@work.example>.
  _:1 foaf:knows _:2.
  _:2 foaf:mbox <mailto:bob@work.example>.
  _:2 foaf:age 32.

  Graph G2 named <bobFoaf.n3>
  @prefix  foaf:  <http://xmlns.com/foaf/0.1/> .

  _:1 foaf:mbox <mailto:bob@work.example>.
  _:1 foaf:PersonalProfileDocument <bobFoaf.n3>.
  _:1 foaf:age 35.

  The Query Graph is the RDF-merge of {G1, G2}

  Q9.1 Query:

  PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
  SELECT ?mbox ?age ?ppd
  WHERE       ( ?alice foaf:mbox <mailto:alice@work.example> )
	      ( ?alice foaf:knows ?whom )
	      ( ?whom foaf:mbox ?mbox )
	      ( ?whom foaf:PersonalProfileDocument ?ppd )
  SOURCE ?ppd ( ?whom foaf:age ?age )

  R9.1 Result:
  mbox                      	age 	ppd
  <mailto:bob@work.example> 	35 	<bobFoaf.n3>

This query returns the email addresses of people that Alice knows. It
also returns their age according to their PersonalProfileDocument
documents, as well as the URI of the graph. Alice's guess of Bob's
age (32) is not returned.

Any variable that is not bound must not match another variable that
is not bound. Thus,

  Query Q9.2:
  PREFIX foaf:    <http://xmlns.com/foaf/0.1/>
  SELECT ?given ?family
  WHERE SOURCE ?ppd ( ?whom foaf:given ?family )
	SOURCE ?ppd ( ?whom foaf:family ?family )

will match only if the source of both triples are known and the same.

A SPARQL implementation MAY not support graph names in which case the
SOURCE ?var parts are ignored.



Named Containers

Named Graphs and TriX

Named Graphs, Provenance and Trust
Carroll, Jeremy J.; Bizer, Christian; Hayes, Patrick; Stickler, Patrick
HPL-2004-57, 20040513 

Received on Monday, 8 November 2004 16:30:16 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:45 UTC