RE: Various result forms

Eric - good point.  I missed multiple subgraphs, one per query solution in
flavours a) and b).

	Andy

-------- Original Message --------
> From: Eric Prud'hommeaux <mailto:eric@w3.org>
> Date: 5 May 2004 15:15
> 
> On Wed, May 05, 2004 at 01:20:27PM +0100, Seaborne, Andy wrote:
> > 
> > To try to put requirements 3.2 (Variable Binding Results) and 3.5
> > (Subgraph Results) in some kind of context ...
> > 
> > There are a number of result forms that people have used or
> > suggested:  I know of: 
> > 
> > 1/ Variable bindings
> >    Common for the case of get data out of RDF
> > 
> > 2/ Result set in RDF
> >    As 1/ - encoded in RDF
> > 
> > 3/ RDF=>XHTML/XML
> > 
> > 4/ Subgraph extraction:
> >    Actually, two forms:
> > 4a/ The query pattern with variables substituted for each
> >     solutions and result merged.  Reexecuting the query     gives the
> > same results. 4b/ The triples from the graph that were matched.
> >     Would include, for example, the subclass resource
> >     when asked (?x rdf:type x:superclass).
> > 
> > 4a == 4b for an RDF graph with no inference processing.
> 
> I think there's another dimension to 4:
> 
> 4?1/ Distinct subgraphs for each solution (isolated by the
>      result protocol) ala the following three subgraphs:
>   (?descendent ex:ancestor ?ancestor) =>
>   ?descendent | ?ancestor   | subgraph
>   Sue         | SuezMom     | Sue ancestor SuezMom.
>   Sue         | SuezGrandma | Sue ancestor SuezMom.
>               |             | SuezMom ancestor SuezGrandma.
>   Joe         | JoezMom     | Joe ancestor JoezMom.
>     Note: the variable bindings need not be present for this
>           answer form to be useful.
> 
> 4?2/ Aggregate graph:
>   (?descendent ex:ancestor ?ancestor) =>
>   Sue ancestor SuezMom.
>   SuezMom ancestor SuezGrandma.
>   Joe ancestor JoezMom.
>     This form is more terse than 4?1 as it needed to serialize
>     "Sue ancestor SuezMom" only once. It also requires no
>     protocol to separate the graphs.
> 
> /me discharges 2004-05-04T15:59:49Z <ericP> ACTION: EricP
> write up implementation experience of 3.4 Subgraph Results :
> 
> The Annotea service uses Algae for querying and updating. The algae
> API provides a set of solutions with variable bindings and supporting
> subgraph (4b1, actually). It was easiest for us to design the Annotea
> protocol to use RDF/XML directly over HTTP. Therefor, the server
> merges all the subgraphs for each query solution and returns the
> result as a single RDF graph [2]. There is some inefficiency in this
> approach as the client needs to take the graph apart again to use it
> for marking up the annotated document.
> 
> Rob voiced objections to Reqirement 3.5: subgraph results which I
> believe is the aggregate graph (4?2 above). I suspect his objection
> would carry to distinct subgraphs as *any* graph communication will
> require serialization of the KB's knowledge as RDF (or development of
> another language). 
> 
> > 5/ RDF => RDF
> >    Templating - a generalisation of 4/ where a template (RDF graph
> > with variables in it) is used to create new RDF at the server. At the
> > F2F this was voted against as a requirement.
> > 
> > 
> > Getting information out of RDF directly is 1,2,3.  Part of a larger
> > processing system (distributed) is 4 & 5.
> > 
> > 
> > 1/ is about the problem of getting information (node and arc labels)
> > out of RDF; 2/ is A way of recording 1/.  I have used 2/ to give
> > access to query languages from (other language) toolkits that have no
> > query capability.  I execute the query remotely (all it takes is to
> > pass a string from application to server - the client toolkit does
> > not need to understand the QL) and use the result set format [1] as
> > the transfer syntax.  That's convenient because the client toolkit
> > can parse and work with the returned RDF.  Having the client
> > requirements simple can, for small devices, take many forms - this is
> > one of them. 
> > 
> > 3/ is important for the display of information directly from RDF
> > sources. Using XQuery/XSLT/etc looks to be useful (practical,
> > utilizes programmer skills, builds on existing work, what people
> > expect, ...). 
> > 
> > 4 & 5 are about getting some RDF out of another (larger, remote) RDF
> > dataset.  The results would be further manipulated before going to
> > the user, and that includes passing in on to other machines where the
> > final destination of user/application is not the one making the
> > query; instead the extracted subgraph is sent on to other places.
> > This is RDF=>RDF, for example, passing around RSS entries.  The
> > general requirement is that part of a large, remote target graph is
> > extracted and deliver for further, local processing. 
> > 
> > For 4/, examples include the "tell me about" queries and the use of
> > the pattern of query to define the subgraph.  In fact, 4a gives an
> > alternative way of approaching the example above if the client
> > toolkit does have the QL. Re-execution is much, much cheaper,
> > essentially as there are so few negative search branches to follow. 
> > 
> > 	Andy
> > 
> > [1]
> http://www.w3.org/2003/03/rdfqr-tests/recording-query-results.html
> [2] http://www.w3.org/2001/Annotea/User/Protocol#Querying

Received on Wednesday, 5 May 2004 10:49:29 UTC