W3C home > Mailing lists > Public > public-lod@w3.org > March 2009

Re: Finding SPAQL endpoints?

From: Giovanni Tummarello <g.tummarello@gmail.com>
Date: Sat, 7 Mar 2009 12:30:24 +0000
Message-ID: <210271540903070430r7c0e2ef8sd7136b5a4d59eca4@mail.gmail.com>
To: Daniel Schwabe <dschwabe@inf.puc-rio.br>
Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-lod@w3.org

> I could query the site for its sitemap extension (would it always be <home
> url>/sitemap.xml? doesn't seem so...), as Giovanni suggests, and see if I
> get a result; in the affirmative case, I have to parse it and look for the
> <sc:sparqlEndpointLocation> element.

Sitemaps are either at /sitemap.xml or have to be linked from robot.txt.
These are the original google specs, the proposal was just extending that.
Void then connects to the semantic sitemaps providing more stats, if one
knows what to do with them.

> Hence my suggestion - I am looking for a simple way to enable
> autodiscovery. If all sites would agree to make the sitemap.xml available at
> <home url>/sitemap.xml, that would work as well. I just think that a simple
> naming convention such as <home url>/sparql would be even easier to
> implement, and it may become one of those "de facto" standards if the main
> datasets follow the convention... (as I said, many already do...)

While its appealing simple, you'd be missing the case where you have
multiple datasets published. by the same host and wanted to provide multiple
endpoints (ok if they were triples, you would use named graphs in fact.. so
it would still be ok, but if they were quadruples). Similarly you want to
offer dumps (which they are even more useful for search engines and people
wanting to do heavy data processing) dumps arelikely to be in multiple files
(the case often) so you need a way to say where these are.

so i'll back the sitemap specs becouse they're a few lines of txt (not even
RDF) and address all this :-) (and provide the hook for void descriptions)


> Cheers
> D
Received on Saturday, 7 March 2009 12:30:59 UTC

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