Re: DESCRIBE ENDPOINT

On Wed, Jul 1, 2009 at 11:47 AM, Steve Harris<steve.harris@garlik.com> wrote:
> 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.

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.
 :-)


> 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.

> 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.

> 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.

Regards,
Paul Gearon

Received on Wednesday, 1 July 2009 18:40:21 UTC