Re: SPARLQ endpoint discovery

With the Sitemap extension called Semantic Web Sitemap we did indeed
give a very simple alternative.
It was also partially adopted

but what breaks it for that protocol is the part about explaining (to
a machine) how to go from a dump  to "linked data publishing" which is
a very fuzzy concent as fuzzy as "describe"

the chances of someone getting that file actually right were slim to
begin with (we had to correct several times those who tried) and as
far as my reports go the chances of getting void right
(which is in RDF therefore much less intuitive for human editing than
a simple XML like sitemaps) cant get much better.

i personally think a single line in the sitemap.xml file is really
what'sneeded so wrt this this part of the extention really does its
job. however until there is someone seriously consuming this there
wont be a need to standardize.


On Sun, Apr 3, 2011 at 11:06 AM, Francisco Javier López Pellicer
<> wrote:
>> A related question is SPARQL endpoint fingerprinting... Which
>> is not necessarily straightforward as often people put them
>> behind HTTP reverse proxies that stomp on identifiable
>> headers... In principle it would be interesting to do a
>> survey to see the relative prevalence of different SPARQL
>> implementations.
> Agree.
> SPARQL endpoint discovery and SPARQL endpoints fingerprinting could be two
> research lines related with the architecture of SemWeb:
> - Indexing SPARQL enpoint (with/without the help of vocabularies such as
> void) -> A hint for knowing the effective size of the SemWeb initiatives
> - SPARQL endpoint fingerprint identification -> "Market share" analysis of
> SPARQL technology pervalence
> -- fjlopez

Received on Sunday, 3 April 2011 12:46:42 UTC