Re: DESCRIBE ENDPOINT

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?

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

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.

- 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 07:57:51 UTC