Re: Service description spec - service name

On Mar 27, 2011, at 8:29 PM, Robert Scanlon wrote:

> Hi,
> Our company is implementing a SPARQL federator.  We are planning on using the Service Description 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.

The Service Description spec is specifically about describing implementations of the SPARQL protocol. As such, all services must have an endpoint URL. If you have services that are not implementations of the protocol, there is likely still much of the service description vocabulary that would be applicable, but such use would fall outside the scope of the spec.

>  Per the federation spec, 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 terminology between the service description and federation documents currently confuses this issue. The federation document defines evaluation as dealing with the results returned by a "SPARQL protocol execution." The "service name" in that document is the same as the "service URL" discussed in the service description document. The group will look into aligning the terminology in these documents before publishing the next drafts.

> 	• 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.

The service description allows independent identification of the service and the URL by which the service is accessed. In the service description vocabulary, these two resources are connected with the sd:url property:

<service> sd:url <service-URL> .

In your relocation example, the <service> IRI would presumably stay the same as the <service-URL> changed. sd:url is defined as being an owl:InverseFunctionalProperty, and so allows different URLs to map to the same service, but prevents a single URL from mapping to multiple services.

> 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?).

The sd:name property describes named graphs (domain of sd:NamedGraph), not services. It's not clear that this change would provide any benefit that using an IRI for the service currently does not provide.


>  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).

As stated above, the IRI required for a SERVICE graph pattern is the URL that provides access to a SPARQL Protocol implementation. It is not the IRI that identifies the underlying service.

>  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.

The current editor's draft of the service description document adds a conformance section which includes this requirement for SPARQL services conformant with the service description spec:

"The RDF content returned from dereferencing a service endpoint URL <service-endpoint-URL> MUST include at least one triple matching: ?service sd:endpoint <service-endpoint-URL> ."

Parts of the service description vocabulary may prove useful to you in situations involving services that are not actual Protocol implementations. That being said, the service description document concerns itself specifically with Protocol implementations, and so those situations involving services which are not Protocol implementations are outside the scope of this work.


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

Gregory Williams (on behalf of the SPARQL Working Group)

Received on Tuesday, 10 May 2011 14:35:34 UTC