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

[Fwd: flexible SPARQL reification construct instead of hard-wired SOURCE keyword]

From: Seaborne, Andy <andy.seaborne@hp.com>
Date: Mon, 17 Jan 2005 12:15:21 +0000
Message-ID: <41EBAC59.7020200@hp.com>
To: RDF Data Access Working Group <public-rdf-dawg@w3.org>

This comment includes a suggestion for syntax support for reification.  This has 
come up before.

Any suggestions for the syntax?

This would be good to do: syntactic support would mean the same as writing out 
the reification long-hand.  A parser can rewrite this and the query engine never 
see it - or a system that wants reification hints can chosoe to pass with through.


-------- Original Message --------
Subject: flexible SPARQL reification construct instead of hard-wired SOURCE 	keyword
Resent-Date: Fri, 14 Jan 2005 18:39:57 +0000
Resent-From: public-rdf-dawg-comments@w3.org
Date: Fri, 14 Jan 2005 19:39:16 +0100
From: Benjamin Nowack <bnowack@appmosphere.com>
Organization: appmosphere web applications
To: public-rdf-dawg-comments@w3.org

hi again,

an adjusted version of my comment from yesterday[1] as
just some extended food for thought. The idea is to
introduce a reification shortcut that could be used for
the SOURCE use cases and also for any other custom rdf
store extension:

SELECT ?s  ?p  ?o
WHERE ( ?s rdf:type foaf:Person )
       ( ?s ex:ppd ?ppd )
       ( ?ppd rdf:type foaf:PersonalProfileDocument )
       ( ?ppd foaf:primaryTopic ?s )
REIF  (?s ex:ppd ?ppd) sparql:source <http://trustMe.com/ppdDump>
       (?s ?p ?o) sparql:source ?ppd
       (?s ?p ?o) ex:addedDate "2004-01-13"

The reification constraint pattern
  ([s] [p] [o]) [prop] [value]
would mean that there had to be an rdf:Statement with [s],[p],[o]
as rdf:subject,rdf:predicate,rdf:object, and that there's also
a matching ([statement] [prop] [value]) triple. store developers
could freely decide how to implement this extended functionality
(explicit reification or with quads etc.) but the query syntax
could be generic. and using URIrefs for the [prop]s instead of
a single built-in SOURCE keyword for n-tuple stores would
keep SPARQL extensible.

regards and apologies for the (probably too) late comments,


Benjamin Nowack

appmosphere web applications
Kruppstr. 100
45145 Essen, Germany

Received on Monday, 17 January 2005 12:15:49 UTC

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