RE: XQuery syntax for BRQL semantics

> > XQuery syntax makes it quite straightforward to add as much, or as
> > little, structure as you like to a result:
> > 
> > for $x in dawg:anything(), $name in dawg:anything() $mbox in
> > dawg:anything()
> > where dawg:related($x, foaf:name, $name)
> >   and dawg:related($x, foaf:box, $mbox)
> > return <x><name>{$name}</name><mbox>{$mbox}</mbox></x>
> > 
> > <x><name>Johnny Lee
> > Outlaw</name><mbox>mailto:jlow@example.com</mbox></x>
> > <x><name>Peter 
> Goodguy</name><mbox>mailto:peter@example.org</mbox></x>
> 
> 
> That's a significant difference. BRQL queries return
> binding sets or graphs; handling arbitrary XQuery data
> models is different.

One of the points I've raised repeatedly is that 'returning' and
'handling' are two quite different things. In practice, users are going
to have to consume result sets somehow. This XQuery syntax obviously
does require users to be much more explicit in terms of what they are
'returning', but offers very substantial advantages in terms of
'handling', since the result can be as simple or complex as the user
desired. What's more, if the result does encode complex structure users
can use existing and popular technologies to process that structure
instead of grappling with new custom libraries. (How much code has gone
into various programmatic DBI layers over the years?)

> And how does this proposal handle returning graph
> results? I suppose another function to go with
> dawg:anything() to return the original graph would
> do it.

It's perfectly valid to return a sequence of triples, although I again
admit that users need to be much more explicit about this within XQuery
than in BRQL. Adding another function to construct a triple from
subject, predicate, and object is entirely reasonable.


On the whole, this is a good point, though. I think the biggest
extension this syntax makes to BRQL is all the machinery to format
results, so this XQuery fragment is not quite subsumed in functionality
by BRQL.
The formatting features I propose, however, are based on what we've
arrived at within Network Inference to make such features as simple to
implement as possible. Copying constant strings with a few substitutions
thrown in is only a few man-hours of work, in our experience.

Received on Tuesday, 7 September 2004 16:38:36 UTC