Re: DESCRIBE ENDPOINT

On Wed, Jul 1, 2009 at 3:51 AM, Steve Harris<steve.harris@garlik.com> wrote:
> On 30 Jun 2009, at 23:39, Paul Gearon wrote:
>
>> On Tue, Jun 30, 2009 at 3:58 PM, Steve Harris<steve.harris@garlik.com>
>> wrote:
>>>
>>> On 30 Jun 2009, at 18:23, Axel Polleres wrote:
>>
>> <snip/>
>>>>>
>>>>> On a slightly separate note, the "DESCRIBE <endpoint-URI>" form may be
>>>>> capable of referring to descriptions on other endpoints. May that's
>>>>> something we want to consider (or to exclude).
>>>>
>>>> yeah, that makes it look appealing somehow.
>>>
>>> On the downside, you have to know that the endpoint speaks SPARQL before
>>> you
>>> can ask that query with any expectation of getting a sensible response.
>>
>> That presumes you are only making calls to the server through HTTP.
>> While this is certainly very common, there are numerous cases of
>> communication through an API as well (eg. Jena sans Joseki). In that
>> case you know you have SPARQL, but you may not know what the
>> capabilities are.
>
> Well, in that case you're using some non-standard protocol, so you'd expect
> to know what you're talking to, no?
> We also have a non-HTTP protocol that we can use (for persistent
> connections), but it's not as if someone could just discover it out in the
> wild and wonder what capabilities it had in any useful was, as they'd have
> no idea how to speak to it in the first place.
>
> In any case, as it's non-standard the protocol can provide some way to get
> an RDF document describing the capabilities out.

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.

Regards,
Paul Gearon

Received on Wednesday, 1 July 2009 15:26:34 UTC