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

Re: Requirement 3.1 rewording

From: Pat Hayes <phayes@ihmc.us>
Date: Wed, 5 May 2004 10:13:09 -0500
Message-Id: <p06001f01bcbeb31ec405@[]>
To: "Seaborne, Andy" <andy.seaborne@hp.com>
Cc: public-rdf-dawg@w3.org

>On Wed, May 05, 2004 at 10:47:50AM +0100, Seaborne, Andy wrote:
>>  3.1 Multiple RDF triple matching
>>  The query langauge must include the capability to restrict matches on the
>>  RDF graph by providing more than one RDF triple pattern to be satisified in
>>  one query.
>This is -- with very small modifications -- the new wording in my
>working copy of the UC&R doc. I think it's an improvement over
>path/edge talk. We'll see if consensus forms around it.

This is better than the 'path' way of talking. It seems to me however 
that all these proposed wordings are hesitating at the edge of what 
needs to be said, which is that a query pattern must be allowed to be 
an RDF graph pattern rather than simply a single triple pattern. A 
graph, in this context, is just a set of triples, recall. There is no 
need to talk explicitly about shared variables: if one allows 
variables to occur in a graph then one would need special conditions 
to avoid shared variables, so not saying anything implicitly allows 

One other point, the phrase 'the RDF graph' here may be too 
restrictive, and in any case isnt clear enough. Some querying 
services might use more than one graph, or might access a constantly 
changing graph. So I'd suggest that we choose a phrase like 'server' 
(or 'source' or 'base' or 'answer' or some such) and use it 
consistently as a name and as a qualifier, as in 'server graph', 
meaning the notional RDF graph used by the server to answer the query.

Pat Hayes


IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Wednesday, 5 May 2004 11:13:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:00:26 UTC