Re: DESCRIBE ENDPOINT

On 1 Jul 2009, at 19:39, Paul Gearon wrote:

...
> I do want to make it clear that I think an HTTP solution is mandatory.
> Frankly, I don't care about SOAP, and I noted Andy's comment (was it
> tongue-in-cheek?) that no one mentioned it in the last meeting either.
> :-)

Yeah, I'm not a big SOAP user either...

>> As the Jena protocol (for eg.) is a custom protocol, with it's own
>> documentation and libraries, it can defines it's own way to  
>> retrieve the
>> relevant data from the server/endpoint/whatever.
>
> OK, but the same can be said of most of the language features,
> particularly SPARQL/Update (and I notice that it *was* said). The
> thing is that there is a lot of call to interact with a server via a
> language, particularly for interactive interfaces. Yes, each server
> can implement its own approach, but that's the very scenario that got
> the working group started in the first place. I really don't want to
> see SPARQL leave such a large gap, like SQL has.
>
> Once the user/developer/application gets back metadata about the
> server, then at that point I'm happy to cut them loose on whatever
> implementation specifics that server has, but I think it's important
> to get them that far first.

Agreed.

>> I'm reticent about having a "magic graph" or similar in the store  
>> which
>> holds this information, it limits what you can legitimately write  
>> into the
>> store without confusing things or causing errors, and may be hard/ 
>> impossible
>> for certain specialised SPARQL services to implement.
>
> 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.

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

- Steve

Received on Wednesday, 1 July 2009 19:26:23 UTC