Re: Service description spec - service name

Hi,
Any thoughts on this?  I modified the original text slightly below (from
what I'd sent earlier).
Bob


On Sun, Mar 27, 2011 at 7:29 PM, Robert Scanlon <rscanlon@revelytix.com>wrote:

> 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) and
> endpoint URL:
>
>
>    - It appears to us that the Service Description spec assumes all
>    services are 'directly accessible', that is, that they all have a URL (the
>    'endpoint' property, formerly 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).
>
>
>    - 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.
>
>
   -  Currently a service MUST have a URL (sd:endpoint property), per
   'Conformance' section.  This does not allow for the used of a Service
   Description to describe a federated service, which is accessible through a
   federation query service (via SERVICE clause) but may not necessarily be
   directly accessible on its own (so will not have a URL).  A URL is also
   unnecessary for services accessed through an embedded component (as opposed
   to a remote-accessible endpoint).


>
>
> 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, so
> that for federated services, or for services exposed by an embedded
> component, it could be excluded.
>
> Thanks,
> Bob Scanlon
> Revelytix <http://www.revelytix.com/>
>
>
>