Raw

PS. Check comments. On irc AndyS pointed out that my queries are my test is well borked, but I've not had chance yet to get back to this. In the meantime sbp's got another relevant post up.

While not cataloguing street furniture, sbp's been looking at RDF templating, mentioning a SPARQL+XSLT approach. I like this way too (though I guess if I knew Javascript better I might find the JSON results easier to work with).

Whatever, in the past I found it useful for templating to insert a CONSTRUCT query phase (to map the vocab to something generic) before the SELECT query (which produces the results using generic terms). This way there's a separation between what you might loosely call the semantic mapping (CONSTRUCT, to some extent the SELECT's WHERE clause) and the presentation (the bindings/result bit of the SELECT, the XSLT). You can change the parts fairly independently, allowing reuse. I never got past the vague notion, but I also had a feeling it might be possible to pronounce Fresnel this way.

There is one bit in all this which is a real hassle, as Sean notes - SPARQL isn't very good at lists. In all fairness, lists are a bit of an Achilles' Heel for RDF in general (which is a little irritating, especially since you don't even have to think about them in things like XML), although the Lispiness of Collections (rdf:List etc) seems more correct than the DIY semantics of Containers (rdf:Seq etc).

I couldn't resist having a go at translating Sean's rules into SPARQL CONSTRUCTs. My first pass didn't work, not sure if I had the OPTIONALs right but the second pass showed up another problem.

The source data example is:

@prefix : <http://inamidst.com/whits/plays#> .


#


[ :play :Hamlet; :dialogue (


   [ :by _:Pol; :quote "Doe you knowe me my Lord?"; :tln
"1210" ]


   [ :by _:Ham; :quote "Excellent well, you are a
Fishmonger."; :tln "1211" ]


)] .

I rewrote sbp's rules like this:

(rule1.rq)

prefix : <http://inamidst.com/whits/plays#>prefix rdf:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#>


#


CONSTRUCT


{


    ?d :membersFromPlay ?play .


}


WHERE


{


    [ :dialogue ?d; :play ?play ].


}

(rule2.rq)

prefix : <http://inamidst.com/whits/plays#>


prefix rdf:
<http://www.w3.org/1999/02/22-rdf-syntax-ns#>


#


CONSTRUCT


{


    ?member :play ?play .


    ?subd :membersFromPlay ?play


}


WHERE


{


 [ :membersFromPlay ?play;


    rdf:first ?member;


    rdf:rest ?subd ].


}

Got no results :-(

I may well have made other mistakes, and there's a very good chance I'm missing something obvious here, but it seems like ARQ doesn't have built-in knowledge of rdf:first, rdf:rest - here's my test:

prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>


#


CONSTRUCT


{


     ?s ?p ?o


}


WHERE


{


     ?s rdf:first ?o


}

I'll be a little surprised if this isn't my mistake, will nudge AndyS to shed light later.

I don't have time to play with this right now, but this set me thinking a bit. Rules like this probably need to be run in a particular sequence. When examining lists with SPARQL, you have the choice between really ugly enumerated lists in the query, or you have to apply more than one query. Might be time to drop the notion of SPARQL as a one-shot operation. How about, in say Python:

while ASK(queryA, graph):


    graph = CONSTRUCT(queryB, graph)














xml = SELECT(queryC, graph).xml


print XSLT(stylesheet, xml)

Unfortunately rdflib doesn't yet support CONSTRUCT, but Redland/Rasqal does. Can't remember whether Tabulator's Javascript SPARQL kit does or not.

Not sure how far meta it'd be productive to go with this, but this could produce a rather cute little language. Hmm, does Ruby have a SPARQL CONSTRUCT anywhere?

@en