Re: Various result forms

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
-- 
-eric

office: +1.617.258.5741 NE43-344, MIT, Cambridge, MA 02144 USA
cell:   +1.857.222.5741

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

Received on Wednesday, 5 May 2004 10:15:16 UTC