- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 1 Jul 2009 17:47:52 +0100
- To: Paul Gearon <gearon@ieee.org>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 1 Jul 2009, at 16:25, Paul Gearon wrote: ... > Actually, while the Jena API is not a W3C standard, it is still a > "standard" protocol that a lot of people use. I know of several cases > of people pulling out one store and putting in another because it > implements the Jena standard. Less often, but still applicable is the > Sesame API. In both cases a system could be talking to various > different implementations, and it could all be dependent on an XML > configuration file. > > Even when talking to the one store, different versions or > configurations may have different capabilities. For instance, like > most of its modules, Mulgara's rule parsers are all pluggable. Older > versions don't include SWRL, and it's conceivable that some > configurations would remove it. > > In each case, the only consistent way to talk to the datastore is via > a query language. If HTTP is present and being used, then a HEAD (or > GET) request is certainly the way to determine capabilities, so we > need that feature. But for the remaining cases, a language feature is > just as important. Well, there's a big leap from "Protocol X does not use HTTP" to "it should be a feature of the language". SOAP and HTTP are sanctioned by http://www.w3.org/TR/rdf-sparql-protocol/ , so we should (IMHO) at least do something that works well with them. If it can be extended to 3rd party protocols then that's also good. As the Jena protocol (for eg.) is a custom protocol, with it's own documentation and libraries, it can defines it's own way to retrieve the relevant data from the server/endpoint/whatever. I'm reticent about having a "magic graph" or similar in the store which holds this information, it limits what you can legitimately write into the store without confusing things or causing errors, and may be hard/impossible for certain specialised SPARQL services to implement. There's always the consideration of what a SPARQL store full of descriptions of other SPARQL stores would look like. This is a perfectly reasonable requirement. - Steve
Received on Wednesday, 1 July 2009 16:48:30 UTC