RE: Proposed XQuery requirement and/or objective

This is a good time to note that I had made a technical error in the
TreeHugger/XQueryFA summary that I presented to Eric and the group several
weeks ago (would provide a pointer here but can't find the email at the
moment). I had said that TreeHugger operated at the RDF/XML serialization
level. This was incorrect: I spoke with Damien by email last week and found
out that his engine speaks directly to the underlying Jena model.

The XQueryFA approach could work either way.

Regrets on this morning's telecon btw. I'll be out of the office.

Howard

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org
> [mailto:public-rdf-dawg-request@w3.org]On Behalf Of Seaborne, Andy
> Sent: Tuesday, July 20, 2004 3:05 AM
> To: Rob Shearer; public-rdf-dawg@w3.org
> Subject: RE: Proposed XQuery requirement and/or objective
>
>
>
> Rob,
>
> Could you compare this with the functional accessor style, for example,
> Jonathan Robie's presentation at the last W3C technical plenary which
> describes a function library approach?
>
> http://www.w3.org/2004/Talks/tp-robie/Overview-1.html
>
> and its conclusions:
> """
> + DAWG may still want a language rather than a function library
> + Anyone can write a function library as needed
> """
>
> > Now that the group has at least given a line in the sand by starting
> > with BRQL, I'm hoping to go through that spec and map each of the
> > constructs in that language back to fragments of XQuery, since it seems
> > likely that BRQL is subsumed by an XQuery extended with only a few
> > external functions.
>
> That would be useful - I look forward to reading that.
>
> 	Andy
>
> -------- Original Message --------
> > From: Rob Shearer <>
> > Date: 20 July 2004 01:46
> >
> > While I completely agree that a mature strawman spec would help out a
> > lot, my contention from the start has been that XQuery is a valid
> > strawman, and that a few simple extensions for RDF can be defined which
> > meet all the requirements we need.
> >
> > The simplest addition is to just add an external function
> > (http://www.w3.org/TR/xquery/#id-function-calls) which tests for the
> > existence of an RDF triple. Within Network Inference this is called
> > this 'related', but Simon suggested the name "asserted". A perfectly
> > valid query asking whether Rob worked for Network Inference would be:
> >
> > asserted(http://foo/Rob, http://foo#worksFor,
> > http://foo#NetworkInference)
> >
> > which would return an xs:boolean. The larger goal of using XQuery is
> > that you could then embed this query within a larger XQuery
> > application:
> >
> > for $member in doc(http://foo/people.xml)/Person
> > where asserted($member/URI, http://foo#worksFor,
> > http://foo#NetworkInference)
> > return $member/name
> >
> > which is meant to iterate across all "Person" elements in some XML
> > document and figure out whether they work for NI or not based on some
> > RDF (which is assumed to be implicit in the query's context). You might
> > even be able to encode the whole query within an XPath expression and
> > avoid the 'for' construct; the point is that you can build very complex
> > queries based on the features provided by the full XQuery language.
> >
> > The real value comes if you also provide a function, perhaps called
> > "nodes", which returns every URI used as a subject or object anywhere
> > in the RDF. Now you can use XQuery FLWOR expressions to get SQL-like
> > functionality:
> >
> > <membersAndSpouses>{
> > for $member in nodes()
> > for $spouse in nodes()
> > where asserted($member, http://foo#memberOf, http://foo#DAWG)
> >    and asserted($member, http://foo#marriedTo, $spouse)
> > return <member>{$member}</member><spouse>{$spouse}</spouse>
> > }</membersAndSpice>
> >
> > Which generates some spiffy XML based on RDF. Of course, since RDF has
> > an XML serialization, you can also generate RDF as output. (Or you
> > could extend XQuery further to return a sequence of native RDF triples
> > instead of XML nodes.)
> >
> > Now that the group has at least given a line in the sand by starting
> > with BRQL, I'm hoping to go through that spec and map each of the
> > constructs in that language back to fragments of XQuery, since it seems
> > likely that BRQL is subsumed by an XQuery extended with only a few
> > external functions.
>

Received on Tuesday, 20 July 2004 09:20:47 UTC