Re: generalizing SOURCE in SPARQL for extended rdf stores

Benjamin Nowack wrote:
 > Hi,
 >
 > I was wondering if DAWG considered extension possibilities
 > for quad, quintuple, 6-tuple, etc stores to make it
 > possible to offer support for special flags or triple
 > attributes without having to use a non-recommended query
 > language.

There have been no proposals for this and they weren't identified in the use 
case and requirements document.

 >
 > I know that RDF is a triple model, but I saw that SOURCE
 > is part of the current SPARQL draft.

There are changes in this area : you can see the editor's draft at:

http://www.w3.org/2001/sw/DataAccess/rq23/
sections 8 and 9

Everyone else seems to look at it :-)

The change is that the model of query is that it is over a collection of named 
graphs and one unnamed graph.  This has been implemented in several systems to 
date - with variations - and is an attempt to agree the approach.  Using 
collections of named graphs is a way people havce been addressing some of the 
issues you highlight below.


 > SOURCE is a nice (and
 > practial) extension, but reflects only one of the potential
 > needs of an RDF store. I'd for example like to use custo
 > triple stores tailored to the capabilities of my tools.
 > This may be stores which have "creatorId", "lastModified",
 > or "addedDate" attributes, or a "probablySpam" flag.

Hmm - open ended set of flags for non-standard usage.  I do not think a spec is 
useful in providing such an extension because the queries are not portable. I'd 
expect this to be addressed as non-stand language extensions as client and 
publisher have to agree the flags meaning anyway.

As you note in your second message, reification is an option here so there does 
not seem to be sufficient evidence that n-tuples is the right mechanism.  Specs 
are a balance between agreeing to exact definition of what people already do and 
a common approach to new features.

I see your comment is really one against the use case and requirments document.

If you would like to create a use case and send that, we'd be most grateful.

 > These extensions are clearly not worth to be part of a
 > standardized QL, but may be needed (or at least handy)
 > for specific applications. Wouldn't it make sense to
 > generalize the mechanism used for SOURCE to allow
 > implementors of extended rdf stores to still use SPARQL?
 >
 > Hm, I could probably simply use FROM to implement this
 > functionality (e.g. by using "true (?s ?p ?o)" as a
 > parameter value:
 > [[[
 > ...
 > FROM <http://foo.com/q?probablySpam=true%20%28%3Fs%20%3Fp%20%3Fo%29>
 > ...
 > ]]]
 > ) but can the querying client be sure that NULL-bindings
 > will return an empty result? And a more standardized
 > solution for additional restrictions would be nicer, e.g.
 > something along
 > [[[
 > ...
 > SELECT ?s  ?p  ?o
 > WHERE ( ?s rdf:type foaf:Person )
 >       ( ?s ex:ppd ?ppd )
 >       ( ?ppd rdf:type foaf:PersonalProfileDocument )
 >       ( ?ppd foaf:primaryTopic ?s )
 > RESTR SOURCE <http://trustMe.com/ppdDump> (?s ex:ppd ?ppd)
 > RESTR SOURCE ?ppd (?s ?p ?o)
 > RESTR addedDate "2004-01-13" ( ?s ?p ?o )
 > ]]]
 > could allow me to find all personal information "added today"
 > of people whose personal profile documents were verified
 > by the trustMe.com service, e.g. in order to update a local
 > contact management tool on a daily basis. (sorry for wrong
 > use of sparql, only just started working with it)
 >
 > (hm, the semweb idea would then probably lead to the
 > use of URIs for extended restrictions, such as dawg:SOURCE
 > or foo:addedDate..)
 >
 >
 > just some thoughts, don't want to hold you up...
 >
 > regards,
 > benjamin
 >
 > P.S.: In section "9: Querying the Origin of Statements"
 > in the SPARQL WD [1], the foaf:PersonalProfileDocument
 > class is used as a predicate. (A property equivalent to
 > the ex:ppd I'm using above does not exist in foaf (yet),
 > foaf currently uses the foaf:primaryTopic property to
 > link the PPD to the description of the person.)

Thanks for the correction - I'll fix the editor's draft.

 >
 > [1] http://www.w3.org/TR/rdf-sparql-query
 >
 > --
 > Benjamin Nowack
 >
 > appmosphere web applications
 > Kruppstr. 100
 > 45145 Essen, Germany
 >
 > http://www.appmosphere.com/

Received on Monday, 17 January 2005 12:00:47 UTC