Re: DESCRIBE ENDPOINT

On Thu, Jul 2, 2009 at 2:57 AM, Steve Harris<steve.harris@garlik.com> wrote:
> On 2 Jul 2009, at 02:00, Paul Gearon wrote:
>>
>> 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.
>
> Well... I think that's imposing more semantics on the RDF graph than it
> really has. What if it's a KB of features that you'd like your SPARQL stores
> to have in 12 months time?

Well that's going to apply to ANY capabilities document.

If that's the case, do you think it would be better to describe
capabilities with another format? XML or maybe JSON? RDF made more
sense to me, but I'm not going to be particular here. What I need is a
way to ask a server "What can you do right now?"

>>>>> 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)
>
> That particular approach wouldn't work ofcourse. Having a 303 seems like a
> less generic equivalent of the HTTP Header idea. It's certainly not a bad
> idea, but would assume that you're never going to want the endpoint URI with
> no arguments to do anything else.

I think we can safely assume that this working group is entitled to
describe what the endpoint URI is supposed to represent. After all, it
was the first DAWG that defined the endpoint, and the queries that can
be sent to it.

My concern is not dictating what form that endpoint URI should have.
Otherwise I'd say something like "just append /metadata to the URI to
find the capabilities URI" or #metadata, or something like that.

The endpoint is defined to accept parameterized queries, so that's an
option, but I'm reluctant to do this for two reasons. The first is how
it might interact with other parameters (maybe that's not a big deal),
and the second is that it's not really playing nicely with REST URIs.

> You might like to be able to do a TriX type backup/restore by GET/PUTing the
> endpoint URI, though I have to say I don't know if anyone's done that.

Doing a GET on the endpoint means that you want to GET the endpoint,
which is nonsensical (by the same argument used for a person's URI in
FOAF). Similarly, doing a PUT means that you want to create that
resource, but it's already there. This was why I suggested 303. The
other alternative is a path extension or a fragment, but I'm pretty
sure that this will conflict with some URI structures out there.

Regards,
Paul Gearon

Received on Thursday, 2 July 2009 20:24:34 UTC