- From: Giovanni Tummarello <g.tummarello@gmail.com>
- Date: Sat, 7 Mar 2009 12:30:24 +0000
- To: Daniel Schwabe <dschwabe@inf.puc-rio.br>
- Cc: Kingsley Idehen <kidehen@openlinksw.com>, public-lod@w3.org
- Message-ID: <210271540903070430r7c0e2ef8sd7136b5a4d59eca4@mail.gmail.com>
Hi > 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 Giovanni > > Cheers > D > > >
Received on Saturday, 7 March 2009 12:30:59 UTC