you're reading...
Linked Data, Proposal, voiD

SPARQL endpoint discovery with /sparql

Daniel Schwabe recently kicked-off a discussion regarding Finding SPAQL endpoints? over at the public-lod@w3.org mailing list.

Basically, Daniel asked if it was not possible for every linked data publisher to follow a simple convention, that is to have the SPARQL endpoint available at common location such as /sparql – as Daniel found out, this is the case with most LOD datasets anyway these days.

Though the proposed good practice currently would be to publish a robots.txt that points to a semantic sitemap which in turn is the entry point for a voiD description, Daniel’s proposal is appealing. Simple and effective.

Additionally, it somehow reminds me on the /host proposal by Mark Nottingham and Eran Hammer-Lahav.

Thoughts, anyone?


About woddiscovery

Web of Data researcher and practitioner


5 thoughts on “SPARQL endpoint discovery with /sparql

  1. I recall in the past there being TAG opposition to reserved URI paths in general.

    Could a response to an OPTIONS * request say anything about SPARQL?

    Posted by Dorian Taylor | 2009-03-10, 07:48
  2. This seems very similar to the problem POWDER was/is facing:

    I like the HTTP Link header solution (HTML link element solution is no go, since not every document is a HTML document)

    Anyway I don’t see why you consider location of a sparql endpoint a problem, when you know a location of VoiD description pointing to it. (For a data with no VoiD description I would understand)

    There are many ways how to link from a resource to resources describing the resource, and I think some consensus should be reached to simplify the implementation of the discovery mechanisms. My opinion is, that only what matters is to find out a location of sparql endpoint – the rest of info should be available by it.

    Posted by Jiri Prochazka | 2009-03-10, 09:01
  3. WKL (Well Known Location) is practical but a bad practice usually because it clutters the information space with magic values with sometimes nasty side effects.

    Think for example about favicon.ico which creates plenty of 404 requests if you do not have one.

    Imagine also that someone had historically a section on his/her web site dedicated to sparql documentation called /sparql
    Suddenly this not usable anymore for an Endpoint.

    There is no useful syntax in robots.txt to achieve it too.

    Maybe one possibility would be to use an HTTP header to advertise it.

    X-SPARQL: http:///www.example.org/somewhere/mysparql

    Posted by karl | 2009-03-13, 04:36


  1. Pingback: SPARQL endpoint discovery with /sparql « Web of bData/b | Software Downloads - 2009-03-12

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: