This page collects ideas and proposals for describing SPARQL endpoints. There are a growing number of SPARQL endpoints and tools that access their data. Endpoint descriptions can be used to announce endpoint capabilities and contents, support discovery through service directories, supply browsing and federation hints.

Retrieving endpoint self-descriptions

The simplest way to obain an RDF/XML file which includes all meta-data about the "endpointurl". RDF Forms (or something like it) would be a possible format.

This is a proposed method for retrieving a self-description from a SPARQL endpoint. To retrieve an RDF graph describing the endpoint, this SPARQL query is submitted to the endpoint:

DESCRIBE <servicename>

where `<servicename>` is a URI representing the service. In the resulting RDF graph, `<servicename>` represents the endpoint. Clients must be aware that the result triples may or may not be part of the regular dataset that is queried by `SELECT`, `CONSTRUCT` and `ASK` queries.

The service name URI should be the service endpoint URL. In situations where this is not feasible (e.g. the endpoint is accessed locally through a Java API and therefore doesn't have an obvious service URL), we need a SPARQL extension:

SELECT SERVICENAME

The result is a SPARQL result with one binding of one variable:

?servicename
-------------
<servicename>

where `<servicename>` is the URI representing the service. Clients can use this extension to retrieve the service name and then submit a `DESCRIBE` query with this URI as an argument.

@@@ Issue: Capitalization of query and variable?

Pro

can be implemented on all existing SPARQL servers that support `DESCRIBE` (except the `SELECT SERVICENAME` part, which is not necessary in the common case)

clients may expect that the description graph's triples are accessible over `SELECT` as well

`DESCRIBE` is icky, in part because it doesn't follow the TAG's recommendations on when to use GET; "Use GET if [...] The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup)"

Design alternatives

extend SPARQL protocol: <endpoint_url?meta> (but what about non-HTTP bindings and can't be faked on existing servers)

HTTP `MGET` on endpoint URL (extending HTTP is heavyweight, and what about non-HTTP bindings? --RC)

`DESCRIBE SERVICE` (nice, but not much nicer than DESCRIBE <url>, and requires extension of QL --RC)