Re: DESCRIBE ENDPOINT

On Wed, Jul 1, 2009 at 2:25 PM, Steve Harris<steve.harris@garlik.com> wrote:
> On 1 Jul 2009, at 19:39, Paul Gearon wrote:
<snip/>
>> 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.

Which example were you referring to? The read-only version, or the
write-to-configure-the-server version. The latter would be
non-standard, and I don't care. The former (which I *think* you meant)
is read only, and this is a desirable thing. You refer to an arbitrary
graph that you can't write to, but I see that as a good thing. We
shouldn't allow anyone to write new statements that say a server can
do OWL entailment queries if it really can't.

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

Well, I wasn't talking about naming the graph, but rather I was
considering how you'd get the data from the graph. Since it's metadata
about the server, then I was thinking that HEAD against the server URI
would be enough.

OTOH, I do see your point about naming the graph. Maybe that can be
implementation dependent, but we standardize the way to get that URI.
e.g. If you do a GET against the server URI, then you get a 303 (see
also) with a Location of the URI for the server's metadata. The
location might be something as simple as the server's URI with
#metadata on the end, but that can be left up to the implementer.
(That's not a proposal, just a suggestion)

Regards,
Paul Gearon

Received on Thursday, 2 July 2009 01:01:08 UTC