Re: Service or graph store naming.

On Feb 14, 2011, at 6:49 AM, Axel Polleres wrote:

> On 11 Feb 2011, at 16:32, Gregory Williams wrote:
> 
>> On Feb 8, 2011, at 6:27 PM, Steve Harris wrote:
>> 
>>> Yes, I'd rather see only one way of providing the URI, I don't really care which one.
>> 
>> My recollection on why the SD was designed this way:
> 
> Are you talking about this thread
> 
> http://lists.w3.org/Archives/Public/public-rdf-dawg/2009JulSep/0193.html
> 
>> [] a sd:Service ; sd:url </sparql>
> 
> the old thread I am quoting had <>, not [] at some point.

That thread occurred before we had agreed that a service description was retrieved from the service url, though, so it wasn't at all clear what the absolute URI identifying the service in:

<> a sd:Service

was. I think based on the discussion at that point, it was likely that <> wasn't the same as the service URL.

>> was based on use cases from Steve. This seems to have been a mistake, and unless anyone objects, I intend to drop the sd:url property entirely, changing the design to have the service resource be the endpoint url. That would mean:
>> 
>> </sparql> a sd:Service .
>> 
>> Does anyone have any comments before I make this change?
> 
> Without having caught up fully on the old thread, I am, frankly, still not quite clear whether any of the concerns 
> back in the 2009 discussion still would be affected by that decision... 
> I had understood that sd:url was meant to point to a "standard" url where the "real" service was accessible, e.g. if the service description was retrieved via proxy... what you're saying is that this is not an issue and would also work with simply  the url in the subject, right?
> Wouldn't something like sd:url still be useful to point to a "standard" URL for an endpoint that is accessible via different URLs?

I'm strongly opposed to having service URLs in both the subject and object of an sd:url triple. I'm willing to discuss the use case of having multiple URLs for an endpoint (for which sd:url would be one solution), but Steve's use cases which helped inform my design of that predicate seems to be moot at this point. Does anyone else have specific use cases for needing to know that several services (available at different URLs) are in fact the same underlying service (with the same "features" such as query/update support, functions, datasets, etc.) without resorting to the use of owl:sameAs? Dropping sd:url would make that difficult, but I'm not sure anybody is claiming to need that ability.

.greg

Received on Monday, 14 February 2011 16:49:56 UTC