On 01/02/07, Thomas Winningham <[EMAIL PROTECTED]> wrote:
> Check out SPARQL,

Absolutely. Couple of other points:

You do have the option of getting the results (view) in RDF/XML using
CONSTRUCT, or SPARQL results XML format, but also several of the
SPARQL engines support a JSON equivalent of the results format - handy
for in-browser processing.

The current SPARQL spec doesn't include aggregate functions, things
like COUNT and GROUP BY, but I think some of the implementations
support these as extensions (along with custom extensions which could
do calculations or whatever). It's also possible to do aggregates on
the results (grouping with XSLT 1.0 can get hairy, but XSLT 2.0 has
built-in support and it should be trivial with JSON).

Something I think is a useful pattern is a two-phase query, first do a
CONSTRUCT (producing an intermediate RDF model) and then do a SELECT
on those results. The advantage here is that CONSTRUCT allows you to
map across vocabularies, so although the CONSTRUCT will be tied to the
domain vocabulary of the soure data, the SELECT can be
domain-independent.

Not long ago in some contract work I used this with a made-up report
vocabulary in the middle, and it meant that the logical query was
separated from the presentation part of the code  (I had preset
queries for SELECT feeding preset XSLT to produce HTML).

I didn't have chance to look into it, but the Fresnel vocabulary might
make a good candidate for using in the intermediate model.

re. fun with CONSTRUCT, see also:

http://www.thefigtrees.net/lee/blog/2007/01/using_rdf_on_the_web_a_vision.html

http://dannyayers.com/2006/12/24/merging-results-from

Cheers,
Danny.

/me giggles at male_members


-- 

http://dannyayers.com
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general

Reply via email to