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?
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:48This seems very similar to the problem POWDER was/is facing:
http://www.w3.org/TR/powder-dr/#assoc-linking
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:01FYI, we start to collect issues, here: http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenDataGoodPractice
Cheers,
Michael
Posted by woddiscovery | 2009-03-10, 12:31WKL (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