Re: DESCRIBE ENDPOINT

On 2 Jul 2009, at 21:23, Paul Gearon wrote:
...
>>>>> 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?"

I think we're talking at cross purposes. I was considering the  
situation where you have a SPARQL endpoint which contains modified  
descriptions from both itself and other stores.

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

We can't use #metadata because that's not sent to the server.

FWIW, I don't really like schemes that require applying string  
operations to URIs. If there was a compelling reason to do that, eg.  
if a significant number of servers didn't have control over their HTTP  
headers, then it would be OK, but it seems like a kludge.

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

Yes, agreed.

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


Right, it doesn't seem like a great idea to me either.

- Steve

-- 
Steve Harris
Garlik Limited, 2 Sheen Road, Richmond, TW9 1AE, UK
+44(0)20 8973 2465  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10  
9AD

Received on Thursday, 2 July 2009 20:49:43 UTC