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 06:05:32 UTC