W3C home > Mailing lists > Public > public-rdf-dawg-comments@w3.org > June 2005

Re: SPARQL Query Results XML Format

From: Ian Harrison <harrison@AI.SRI.COM>
Date: Wed, 15 Jun 2005 11:37:56 -0400
Message-ID: <42B04B54.9030109@ai.sri.com>
To: Dave Beckett <dave.beckett@bristol.ac.uk>
CC: public-rdf-dawg-comments@w3.org
Dave

Dave Beckett wrote:

>On Tue, 14 Jun 2005 11:59:03 -0400, Ian Harrison <harrison@AI.SRI.COM> wrote:
>
>  
>
>>Have you considered having more meta-data in the head element, e.g. to 
>>record the query (or ref to query), plus dataset (or ref to dataset) 
>>queried). Otherwise there doesn't seem to be any information identifying 
>>where the result bindings came from?
>>    
>>
>
>The WG hasn't consider this, as far as I recall.  Do you mean identifying
>the query and dataset (say by URIs) or including it, such as a literal
>string for the query, something else for the dataset?
>  
>

Yes, I'm thinking  of some sort of UUID/URI to the query and to the dataset.

>  
>
>>The motivation for this comes from work we're doing. In that work we do 
>>graph matching over a dataset, which (although currently stored in a 
>>relational database)  is a set of triples, such as (memberOfGroup 
>>Person1 Group1). We'd like to be able to store the query results for 
>>later retrieval and want to have provenance of the results, for several 
>>reasons
>>
>>1) To know which graph matching application made the match, so we can 
>>compare results between different pattern matchers
>>    
>>
>
>That's recording the application, not the graph(dataset) or query - is
>that a different use case?
>

No it's additional meta-data, so my requiremnets are 1) application 2) 
query and 3) dataset information recording

>
>  
>
>>2) To know which dataset we matched against, so that if the dataset 
>>changes then we'd be able to understand why results might differ 
>>(ideally we'd want provenance not jyust at the high-level name/id of 
>>dataset, but at the individual data triple level too).
>>    
>>
>
>>From what you say earlier, to you a dataset is a reference to a database
>which is a single graph.  SPARQL's dataset is a slightly different and
>wider concept.
>  
>

Currently for our testing we're only using a single physical database. 
In that database is, from my understanding of hte term, hundreds of 
connected graphs.. I suppose there is a single meta-graph, if you 
consider that there is a conceptual link from each graph root node to a 
node naming he dataset with the link being something like containedIn. 
However, conceptually the applications we're building could 
(simulatneously) query over an infinite amount of datasets to match 
against (which could be conceptialised as one big virtual dataset), for 
the sue case where data is spread out among multiple datasets.

>  
>
>>3) To know what pattern matching parameters were set. These include 
>>obvious things like max number of results to return, or a time point/no 
>>of cpu cycles to expend on the query. This also includes, for inexaxt or 
>>approximate graph pattern matchers things like maximum cost, which are 
>>used if you have something like an ontological edit distance matching 
>>algorithm.
>>    
>>
>
>This sounds like a richer description requirement.  Could this be
>met by external metadata, pointed to from the query results by a URI?
>

I guess as children of the application meta-data which I discussed 
above. The same query could be posed again and again against different 
applications, or the same application but with slightly differetn 
parameters. We could leave it to the server to generate this meta-data, 
in the same way that Describe results are controlled by the application 
srever.

>
>  
>
>>4) Results from one application might be used as (port of) a query to 
>>another application. This could occur if you had a serial workflow, when 
>>each application had a specialised capability (e.g. group finding), 
>>whereas the next application was an event matcher (with temporal 
>>constraint checking). Alternatively you might have a parallel workflow, 
>>where you divide the problem in parts (sub-graphs) , task to separate 
>>applications, and then merge the results all back together.
>>    
>>
>
>Thanks for your feedback.
>
>Dave
>
>  
>

-- 
Ian Harrison                Email: harrison@ai.sri.com
SRI International           Phone: 917 535 3976
380 Degraw Street           
Brooklyn, NY 11231          WWW: http://www.ai.sri.com/~harrison
Received on Wednesday, 15 June 2005 15:38:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:14:48 GMT