W3C home > Mailing lists > Public > www-rdf-rules@w3.org > January 2003

Variables in predicates (was: RE: RDF query testcases?)

From: Seaborne, Andy <Andy_Seaborne@hplb.hpl.hp.com>
Date: Sun, 19 Jan 2003 17:48:18 -0000
Message-ID: <5E13A1874524D411A876006008CD059F038D40B3@0-mail-1.hpl.hp.com>
To: "'Jos De_Roo'" <jos.deroo@agfa.com>, "Libby Miller <Libby.Miller" <Libby.Miller@bristol.ac.uk>
Cc: www-rdf-rules@w3.org

Libby, Jos,

Variables for predicates do come up in some circumstances.  Purely
subjectively, from looking at queries that people have posted, there seem to
be a number of different parts in RDQL triple pattern and the query
structure - there is a "locate" part, an "extract" part and a "filter" part.
The "locate" part of the triple patterns pins down the set of resources of
interest, the "extract" part pulls out information to do with that object
and the "filter" part applies some non-RDF level constraints.  These sort of
queries are not straight "RDF queries" in the sense that the output has been
formatted to the tuples result table style.

Illustration:

SELECT ?x, ?prop, ?value
WHERE
      (?x  <employeeId> "1234")	// Locate: identifying property
	(?x  ?prop  ?value)           // Extract

where we get all the (property,value) pairs for a particular person.
Variable predicates tend to come up in this part but not in the locate part.
Filtering on the predicate would enable the properties retrieved to be just
from some known vocabularies.

Dave Reynolds, in: 
http://lib.hpl.hp.com/techpubs/2002/HPL-2002-327.html
discusses extracting subgraphs and bArcs, where there is scope for filtering
predicates based on vocabulary in his RDF-QBE system.

	Andy



> -----Original Message-----
> From: Jos De_Roo [mailto:jos.deroo@agfa.com]
> Sent: 16 January 2003 17:56
> To: Libby Miller <Libby.Miller
> Cc: Jos De_Roo; www-rdf-rules@w3.org
> Subject: Re: RDF query testcases?
> 
> 
> 
> 
> > So, looking at
> >
> > http://www.agfa.com/w3c/euler/
> >
> > and particularly the questions like
> >
> > http://www.agfa.com/w3c/euler/gedcom-query.n3
> >
> > you're using n3 to describe an RDF graph and _interpreting_
> the graph
> > as a query, is that right? like Pat Hayes said I think - an
> RDF graph
> > with a question-mark at the end? So the graph means something
> > different - a question, rather than a set of statements.
> 
> right, exactly you that right, Pat explained very clearly
> 
> > I like this approach very much for testing especially
> (though I'd use
> > N-triple rather than N3, there's not a big difference for something
> > like this I don't think).
> 
> well I guess you meant ntriples with qnames as is
> currently provided in Jena 1.6 output, but indeed
> there's not a big difference
> 
> >                           The only issue I can see is that queries
> > (although rarely in my experience) could have blank 
> predicates, anbd
> > predicates can't be bnodes in RDF as far as I know. Do you
> think this
> > matters?
> 
> well I can only speak based on my experience with
> the 227 testcases that we currently have spawned
> from http://www.agfa.com/w3c/euler/etc5 and in
> there we haven't needed it, but you're right, we
> have to think about that...
> 
> > For the results, cleverer backends might produce more
> results in for
> > the same query, and we'd have to take this into account for
> describing
> > the results.
> 
> I see
> actually we have that either a single result
> (in the form of a proof or an explanation)
> is returned or all answers with the --think
> command line argument
> not very human readable, just to get an idea
> see http://www.agfa.com/w3c/euler/etc5-proof.n3
> where you could pay no attention to indented stuff
> 
> 
> -- ,
> Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
> 
Received on Sunday, 19 January 2003 12:52:05 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:53:10 GMT