RE: XSRQL proposal

> -----Original Message-----
> From: public-rdf-dawg-request@w3.org
> [mailto:public-rdf-dawg-request@w3.org]On Behalf Of Seaborne, Andy
> Sent: Monday, June 28, 2004 2:18 PM
> To: 'Howard Katz'; public-rdf-dawg@w3.org
> Subject: RE: XSRQL proposal
>
> Howard,
>
> I have got through the XsRQL proposal - nicely written document
> and I have a
> good sense of what XsRQL is and does.  I particularly liked the
> style except
> the yellow (!) ...

My colour adviser picked #ffff99 out of her Color-Your-World palette, but
she's not adverse to other suggestions ...

>
> A few "straightforward" questions:
>
> 1/ Is the output always syntactic?  Some of the examples are explicitly
> creating strings in the query itself.

> In RDQL, the output is not defined: indeed, in Jena, the output is a Java
> structure with the real RDF Java objects so you can switch
> between query and
> other APIs.  The formatted output shown in the tutorial is based
> on feeding
> queries to a general result as formatter as accessed through the command
> line wrapper.  The decision on formatting is not part of the query process
> but part of the formatting process.

This is pretty well the same for XQuery/XsRQL: formatting is not a part of
the language. What comes out of the query engine is a sequence of
xsd:integers, xsd:strings, uris and the like, and if you didn't do any
formatting yourself, they all get serialized to text and everything gets
smushed together into one long contiguous string! That said, most XQuery
vendors seem to provide either a default pretty-print or a user-specified
mechanism for turning pretty-printing on and off. Most of my examples assume
the user will do his or her own formatting; ergo a simple chr() function to
allow the user to at least insert tabs and linefeeds. I think I've also got
a prolog declaration in the tutorial that explicitly turns on
auto-formatting, but <marketspeak>I think one of the nice things about the
language is the ability to allow the user to control his/her own
formatting -- if that's what they want to do.</marketspeak>

>
> 2/ XsRQL is strong on the construction side of results: how do
> you see this
> working with rules?

Unfortunately I don't know enough about rules to be able to say.

>
> 3/ The data model has subjects, predicates and objects and the syntax uses
> cues to indicate what is a predicate using @.  How do I write a query that
> does
>
> (?x ?x anything)

I'm assuming that your "anything" might also be called "something" -- ie,
it's *not* a variable but an actual specific object. If that's correct (is
it?), then you'd say:

   { *, @*, anything }

and would get back all triples that terminate in an "anything" object.

>
> Which would match the well known "rdf:type rdf:type rdf:Property."  RDF
> works on URIrefs rather than types so I wonder if this makes a
> difference or
> not.

  { rdf:type, @rdf:type, * } would pick up all the triples with rdf:Property
objects.

>
> [More common would be queries that work on properties and then access any
> domain and range constraints use a predicted URI is a property and as a
> subject.]
>
> 4/ (checking question) In
>
> { $libby, @newFoaf:Name, $libby/@foaf:name/* }
>
> does the generation create many triples, one for each match of
> $libby/@foaf:name/* or a triple with a sequence for the object value?  I
> presume it's the former.

Right, one triple per match.

If you've got a single <libby> triple in the 3store:

        <libby>  newFoaf:name   "libby_name"

you'll get it back:

        <libby>   newFoaf:name    "libby_name"

If you've got multiple <libby> triples:

       <libby>   newFoaf:name   "libby_name_1"
       <libby>   newFoaf:name   "libby_name_2"

you'll get all of them back.

>
> 5/ Could you add collections to the types?  This seems quite
> tricky to deal
> with in any triple oriented RDF query language.

I'm still confused about how collections work in RDF (ie, what are artifacts
of RDF/XML requirements and what exists at the triples level?), so I don't
know. It's time I figured that out however ...

Howard

> 	Andy
>
>
> -------- Original Message --------
> > From: public-rdf-dawg-request@w3.org <>
> > Date: 27 June 2004 21:40
> >
> > I've finished my XSRQL proposal, which can be found at
> > http://www.fatdog.com/xsrql.html. You'll notice I've shortened the
> > acronym slightly: XSRQL stands for XQuery-style RDF Query Language. I
> > hope this latest addition to the query-language canon isn't
> > considered overly XS-ive (groan).
> >
> > I'm slightly embarrassed; I've gone totally overboard on
> > this. (If you encounter graffiti in public lavatories
> > reading, "Stop me before I write again!", it was probably
> > me.) In any event, those who don't have the time or the
> > desire to plow through the proposal in its entirety can
> > probably get a fairly quick idea of what the language is
> > about by reading the introduction [1] and then skipping to
> > the section on the path language [2] . You might also find
> > the Examples section [3], which looks at several examples of
> > code in both RDQL and XSRQL, of interest. Once you've
> > recovered from that, you can go back and read the rest at your leisure.
> >
> > I'd be honoured if somebody would volunteer to pick this up
> > for evaluation before the agenda deadline (July 7?). I'm
> > around through this coming Tuesday evening, so if anybody has
> > any questions, either get a hold of me before then or after
> > I'm back from vacation on the 6th.
> >
> > Ta,
> > Howard
> >
> > [1] http://www.fatdog.com/xsrql.html#Introduction
> >
> > [2]  http://www.fatdog.com/xsrql.html#Path%20language
> >
> > [3] http://www.fatdog.com/xsrql.html#Examples
>

Received on Monday, 28 June 2004 19:24:31 UTC