- From: Seaborne, Andy <andy.seaborne@hp.com>
- Date: Wed, 5 May 2004 15:47:14 +0100
- To: "Eric Prud'hommeaux" <eric@w3.org>, "Seaborne, Andy" <andy.seaborne@hp.com>
- Cc: public-rdf-dawg@w3.org
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