- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Mon, 14 Feb 2011 21:04:46 +0000
- To: Gregory Williams <greg@evilfunhouse.com>
- CC: Axel Polleres <axel.polleres@deri.org>, SPARQL Working Group <public-rdf-dawg@w3.org>
On 14/02/11 16:49, Gregory Williams wrote: > I'm strongly opposed to having service URLs in both the subject and > object of an sd:url triple. Agreed - I think its confusing a service (abstract concept - sd:Service) and a service endpoint (service instance). > 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. The service is replicated (to spread load, better latency by being close, etc) - relying on rotating DNS would mean the path at all points would need to be the same. Think of it more like download mirroring. This means there is <myService> a sd:Service ; sd:url </sparql2> , </sparql2> :sd:url has domain service and range endpoint. maybe: """ 3.2.1 sd:url The service URL of an sd:Service supporting the SparqlQuery interface. The object of the sd:url property is a URI reference """ ==> """ The service URL of an sd:Service supporting the SparqlQuery interface. The object of the sd:url property is a URL for a service endpoint. """ Andy
Received on Monday, 14 February 2011 21:05:28 UTC