Comments on: Who needs ‘AS’ in SPARQL?

By: TechnicaLee Speaking: SPARQL Calendar Demo: Retrieving Calendar Events

TechnicaLee Speaking: SPARQL Calendar Demo: Retrieving Calendar Events — Sun, 21 May 2006 12:01:40 +0000

[...] This is an ugly hack. Anyone reading this should be outraged. I was, but sometimes deadlines beckon. This is an ugly hack not least of all because the all of those ics2rdf URLs are invalid URL syntax (the reserved characters in the ical query parameter should be URL escaped). A possible solution would be to extend our calendar convention to require that a person’s FOAF data contain a triple along the lines of: <http://example/myCalendar.ics> ex:asRDF <http://torrez.us/services/ics2rdf/?ical=http%3A//example/myCalendar.ics>. That’s ugly, also, but perhaps a bit better. When we look at the queries that deal with people’s interests and make use of data from upcoming.org, we’ll see that this is a more general problem: when we access non-RDF data as RDF, how do we semantically associate the (different) URLs of (different) representations of the same data in a manner which is relatable within a SPARQL query? Elias wrote about this dilemma and solicited opinions ranging from handling this at an application level (but how do we do that with the current SPARQL Protocol over the web?) to extending the expressibility of SPARQL FROM NAMED clauses. [...]

By: Dave Beckett

Dave Beckett — Sat, 25 Mar 2006 05:20:45 +0000

There’s already a pseudo design for recording graph names in rdf/xml. The way to delimit rdf graphs is the rdf:RDF element itself, all it needs is a tiny syntax extension of an attribute such as rdf:graphURI to give the graph inside a URI name. *If* RDF/XML was worth extending.

An xml:base on the root rdf:RDF element seems an interesting way without an extension I guess it is OK.

By: Richard Cyganiak

Richard Cyganiak — Sat, 25 Mar 2006 01:21:36 +0000

I don’t know, and I’d also like to know what others think. Some wider discussion of the pragmatics around SPARQL graph names would certainly be good.

By: Elias

Elias — Fri, 24 Mar 2006 19:46:29 +0000

Richard, I think it’s a good idea. I wonder what others think about it, would it get any traction in a best practices kind of setting?

By: Richard Cyganiak

Richard Cyganiak — Fri, 24 Mar 2006 19:38:46 +0000

In line with Michael’s brainfart, I think it wouldn’t be *completely* crazy if the SPARQL processor used the xml:base of of graphs loaded via FROM NAMED as graph names. Could be confusing as hell in some situations, or just whay you want in others.

This wouldn’t violate the spec, and would be very much in line with the thinking that an RDF graph has a name (the original data source), but may be served from somewhere else (cache, converter).

By: Dave Beckett

Dave Beckett — Fri, 24 Mar 2006 16:40:49 +0000

As I recall in earlier DAWG discussions, we proposed FROM (NAMED )* but eventually ended up with the other 2 forms.

As with ARQ, my Rasqal code can still do this and it’s available if constructing queries via the API.

By: Lee Feigenbaum

Lee Feigenbaum — Fri, 24 Mar 2006 14:55:47 +0000

How can you do it? Dirty tricks, Elias, dirty tricks.

(But you knew that already

By: Elias

Elias — Fri, 24 Mar 2006 13:05:16 +0000

k. I’m persuaded that this shouldn’t be in the language and that it’s perfect place is in the software (as Jena ‘s Locator mappings). But how can I do so externally to the SPARQL engine, i.e. a web 2.0 application talking to http://sparql.org/ and the authors don’t know Andy Seaborne’s email address?

By: Andy Seaborne

Andy Seaborne — Fri, 24 Mar 2006 10:59:18 +0000

In Jena/ARQ, you can do that – it’s not part of the query – it’s part of the environment. There’s a mapping from name use din FROM/FROM NAMED to the real file/URL to use. Used a lot for ontology imports. It’s called a location-mapping.

By: Michael

Michael — Fri, 24 Mar 2006 10:19:43 +0000

Nevermind, I wrote that a few minutes after getting up, sorry

Sounds like application logic to me though, getting all that done by SPARQL itself would turn out rather messy I believe.