- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 1 Jul 2009 20:25:47 +0100
- To: Paul Gearon <gearon@ieee.org>
- Cc: RDF Data Access Working Group <public-rdf-dawg@w3.org>
On 1 Jul 2009, at 19:39, Paul Gearon wrote: ... > I do want to make it clear that I think an HTTP solution is mandatory. > Frankly, I don't care about SOAP, and I noted Andy's comment (was it > tongue-in-cheek?) that no one mentioned it in the last meeting either. > :-) Yeah, I'm not a big SOAP user either... >> 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. > > OK, but the same can be said of most of the language features, > particularly SPARQL/Update (and I notice that it *was* said). The > thing is that there is a lot of call to interact with a server via a > language, particularly for interactive interfaces. Yes, each server > can implement its own approach, but that's the very scenario that got > the working group started in the first place. I really don't want to > see SPARQL leave such a large gap, like SQL has. > > Once the user/developer/application gets back metadata about the > server, then at that point I'm happy to cut them loose on whatever > implementation specifics that server has, but I think it's important > to get them that far first. Agreed. >> 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. > > I'm having difficulty seeing how this is a problem. Can you provide an > example where this limits what you can write please? > > In the simplest case, such a graph could be read-only and only > accessible via the DESCRIBE (or whatever) keyword, or from the > appropriate HTTP method. So there'd be no conflict with what can be > written to the store, since there'd be no way to write to that graph. > Other implementations may want to do something different (for > instance, writing to this graph could enable/disable features), but > that would be non-standard and up to the implementer to worry about. Well, you just gave an example yourself. There's now one or more arbitrary graphs that I can't write to. >> 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. > > This would be useful, and could follow the same vocabulary as how > stores describe themselves, but as you point out, this is a different > issue. Sure, but what would the graph URIs be? :) - Steve
Received on Wednesday, 1 July 2009 19:26:23 UTC