Re: flexible SPARQL reification construct instead of hard-wired SOURCE keyword

Benjamin Nowack wrote:
> 
> 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"
> ]]]

In the new style I think that's just:

SOURCE  <http://trustMe.com/ppdDump> (?s ex:ppd ?ppd)

that is, graph <http://trustMe.com/ppdDump> asserts (?s ex:ppd ?ppd)

There would then be triples about <http://trustMe.com/ppdDump> saysing when it 
was added, what its trust status is etc etc.

[incidently that query may be not what you want - ?s is likely to be a bNode in 
the unnamed graph]

> 
> 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.

That would be reification AND the original triple.  That makes the triple 
asserted as true.

> 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

Never too late.

I'll take this as a suggestion for syntax support for reification and pass it 
onto the working group as such.

	Andy

> 
> [1]
> http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2005Jan/0002.html
> 
> --
> Benjamin Nowack
> 
> appmosphere web applications
> Kruppstr. 100
> 45145 Essen, Germany
> 
> http://www.appmosphere.com/
> 
>

Received on Monday, 17 January 2005 12:05:19 UTC