CommentResponse:RV-6

Rob Vesse wrote:

I just noticed this part of the specification in Section 5 on
Conformance: 

The returned RDF content MUST contain one and only one
triple of the form:

  <service-URL> rdf:type sd:Service . 

This seems to be a somewhat
heavy handed thing to mandate IMO. 

If I want to have a system that
provides multiple endpoints for Update/Query etc why can't I define all the
services of that system in a single service description? This allows me to
both have a dedicated URI in my system for returning the service
description in addition to returning it when an appropriate GET/OPTIONS
request is received at the various service URIs 

This seems to
unnecessarily make service discovery (which surely is part of the point of
having service descriptions) harder than it needs to be. 

Provided each
service has a different  consuming clients can easily find the services
they actually want even if multiple services are defined in the description
so why mandate only 1 instance of sd:Service per Service Description
document? 

The intention of that requirement wasn't to restrict a SD document to only describing one service, but merely that if the SD document was retrieved from some URI, U, then U must be described as a sd:Service in the SD. That being said, the old text was poorly worded and didn't effectively communicate the intention. The latest working draft of the Service Description document has changes that are meant to clarify this point. The new conformance requirement is that the SD RDF returned from an endpoint must contain at least one triple matching that pattern { ?service sd:endpoint <service-endpoint-URL> } (where <service-endpoint-URL> is the URL from which the service description document was retrieved). This should allow you to describe both multiple services in a SD document as well as having multiple endpoint URLs for a single service.

We would be grateful if you would acknowledge that your comments have been answered by sending a reply to this mailing list.

Regards, Gregory Williams, on behalf of the SPARQL WG.