W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Discovering service descriptions

From: Lee Feigenbaum <lee@thefigtrees.net>
Date: Thu, 06 Aug 2009 06:38:10 -0400
Message-ID: <4A7AB292.9050504@thefigtrees.net>
To: SPARQL Working Group <public-rdf-dawg@w3.org>
(This is somewhat related to 
http://www.w3.org/2009/sparql/track/issues/31 .)

We have a significant open question of how people/software can find 
SPARQL endpoint service descriptions.

On our June 30 teleconference, we discussed 6 options for discovering 
service descriptions - 

Since, there's also been some discussion on our mailing list around 
- and also more recently some discussion on our -comments list: 
and subsequent.

This mail is an attempt to summarize the options I've seen put forth & 
to characterize them a bit. I'm hoping people will reply with strong 
support or strong opposition to options, to inform discussion at next 
week's teleconference.

I'm going to give the options both names & numbers :)

Option 1 - HTTP-Header

Any GET or HEAD request on an endpoint would use an HTTP response header 
to provide a URL at which a service description for that endpoint can be 


Return a service description in response to an HTTP request on the 
endpoint that uses the HTTP OPTIONS verb.

Option 3 - Well-known location

A service description can be downloaded from a well-known URL relative 
either to the SPARQL endpoint URL.

Option 4 - DESCRIBE <sparql.endpoint.url>

A service description is returned in response to a DESCRIBE query issued 
for the URI of the endpoint itself. DESCRIBE <> is closely related to this.

Option 5 - Query

Recommend that SPARQL endpoints SHOULD answer regular SPARQL queries 
about the endpoint URI using the service description vocabulary/ies.


Add a new SPARQL query type specifically to return service descriptions. 
suggests two new query types - DESCRIBE_SERVICE and DESCRIBE_DATASET.

Option 7 - Conneg

An HTTP GET request on a SPARQL endpoint without any query parameters 
and specifying an RDF serialization in the Accept: header would return a 
service description for the endpoint. (Suggested in 

 From what I've heard in conversations so far, I think that 2 - HTTP 
OPTIONS, 3 - Well-known location, and 5 - Query all lack strong support 
from anyone. Please correct me if I'm wrong.

Of the remaining options, 1 - HTTP Header and 7 - Conneg both are 
"protocol-level" operations. They each seem to be somewhat specific to 
HTTP, though I'm guessing there'd be a moral equivalent for things like 
SOAP. They definitely lend themselves easily enough to equivalents via 
an API (myEngine.getServiceDescription() ? :-) ).

The other options, DESCRIBE <endpoint> and DESCRIBE_ENDPOINT, are 
"query-level" operations. Some people have expressed concerns that 
DESCRIBE <endpoint> (or its cousin, DESCRIBE <>) constrains what 
information the store can actually contain, and it also seems to me that 
it requires that the endpoint actually have a URI in the first place, 
and that the caller know that URI (not necessarily the case in an API 
environment, though there are non-standard ways to get at service 
descriptions in those cases, as above, I guess).

Any thoughts / opinions?

Received on Thursday, 6 August 2009 10:38:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:00:57 UTC