Service description spec - service name

Hi,
Our company is implementing a SPARQL federator.  We are planning on using
the Service Description<http://www.w3.org/TR/2010/WD-sparql11-service-description-20101014/>specification
to describe all services, including the services exposed 'out
the top' by our federator ('federation services'), and the external services
that are federated together by any given federation service ('federated
services').  The latter are the services that can be referenced by the
SERVICE clause in a SPARQL query.

There's a few issues we've found with respect to a service's name (IRI):


   - It appears to us that the Service Description spec assumes all services
   are 'directly accessible', that is, that they all have a URL (the 'url'
   property).  Federated services will not (necessarily) be directly accessible
   by URL.


   - In addition, it does not seem like the spec accommodates describing
   services that are the references of the SERVICE clause in SPARQL, such as
   federated services.  Per the federation
spec<http://www.w3.org/TR/2010/WD-sparql11-federated-query-20100601/#defn_service>,
   the SERVICE graph pattern contains an IRI which is the 'service name', not a
   URL; though it is not stated explicitly, one might infer from the
   description of GRAPH graph pattern IRIs (in the query spec) that the service
   IRI is meant to be 'interpreted by the query service' (in this case, our
   federator) to resolve the service (that is, it's not a directly-resolvable
   URL).


   - Lastly, the implication that a service is identified by URL (as opposed
   to IRI) seems to tightly couple a service to a particular URL.  This does
   not allow for 'relocating' a (logically named) service, such as moving it to
   a new machine, or migrating it through a development-testing-production
   staging process, both typical of operations performed in enterprise
   environments.


We would like to suggest that the spec be modified to allow the 'sd:name'
property to be optionally used with Services (domain sd:Service, range IRI,
cardinality 0..1, or maybe mandatory?).  This would uniquely identify a
service (similar to and consistent with graph naming/identification); would
define exactly the IRI required for the SERVICE graph pattern in federated
queries; and would decouple the service's identity from its served-up
location (URL).  In addition, the sd:url property should be optional (it's
not clear in the spec what its cardinality is), so that for federated
services it could be excluded.

Thanks,
Bob Scanlon
Revelytix <http://www.revelytix.com/>