Re: DESCRIBE ENDPOINT

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