W3C home > Mailing lists > Public > public-lod@w3.org > December 2012

Re: Proposal: register /.well-known/sparql with IANA

From: Hugh Glaser <hg@ecs.soton.ac.uk>
Date: Mon, 24 Dec 2012 19:26:13 +0000
To: Andy Seaborne <andy.seaborne@epimorphics.com>
CC: "<public-lod@w3.org>" <public-lod@w3.org>
Message-ID: <387E72E216DF1247A2F8ED4819C93BA71E3EB94D@UOS-MSG00041-SI.soton.ac.uk>
+1

I wouldn't really be fussed at having more than one way, but the more ways of publicising things the more things I (publisher) have to do, and the more likely that someone hasn't done the one I (consumer) am expecting.
And this doesn't cover all Linked Data - only those sites that offer SPARQL endpoints.

But digging deeper, what are you proposing?
That /.well-known/sparql is the SPARQL endpoint?
Or that it tells me where the SPARQL endpoint(s) is/are?

So I went an read the manual (I know, but it's Christmas!)
http://tools.ietf.org/html/rfc5785
"As such, the well-known URI space was created with the expectation
   that it will be used to make site-wide policy information and other
   metadata available directly (if sufficiently concise), or provide
   references to other URIs that provide such metadata."

So I read that as it should tell me where the endpoints are.
Which is what sitemap.xml does.
So if the proposal was for /.well-known/semantic-sitemap.xml or something like that, then maybe.
But sitemap.xml as it stands doesn't have to be at the root of the domain, whereas .well-known does (I think).

So I think this would just be a distraction - it is much better that people actually generate the data for their sitemaps than spend time defining another way of doing something that many people won't bother providing or looking for.

To put it bluntly:
If you have already done a sitemap on your existing data or your consuming software looks at others' sitemaps then you are allowed to support this, otherwise go away and implement the existing de facto standard and come back when you have.

Oh, and Merry Christmas and a Happy New Year to you all!
Hugh

On 24 Dec 2012, at 16:18, Andy Seaborne <andy.seaborne@epimorphics.com>
 wrote:

> 
> 
> On 24/12/12 14:38, Kingsley Idehen wrote:
>> On 12/23/12 8:48 PM, David Wood wrote:
>>> On Dec 22, 2012, at 17:23, Kingsley Idehen <kidehen@openlinksw.com>
>>> wrote:
>>> 
>>>> On 12/22/12 11:25 AM, Melvin Carvalho wrote:
>>>>> 
>>>>> So I think anyone register this, if there's interest, it would
>>>>> probably just need to reopen the conversation with the sparql wg
>>>>> mail list, I think.
>>>> I suggest, you just do it :-)
>>> 
>>> Normally, I'd agree, but in this case I think the SPARQL WG thread is
>>> worth reading; they have a good point.
>> 
>> Help me with a link to the specific point. I've taken a quick look and
>> haven't found anything that changes my position re. "just do it".
>> 
>> Discoverability remains something that's received too little attention
>> re. Linked Data, SPARQL, and RDF. It isn't something best handled (a as
>> prescription) by the W3C (IMHO). When best practices have been
>> established, the W3C can come in and formalize etc..
> 
> void descriptions and service descriptions provide searchable documents?
> 
> At least they provide an answer to what to put at a well-known URI.
> 
>> We need to bootstrap first, and the formalize standardization later. The
>> alternative route never works, as you can see from the age of the
>> initial suggestion re. this matter :-)
> 
> A good argument ... for using sitemapsˇ
> 
> 	Andy
> 
>> 
>> 
>> Happy Holidays to you and everyone else on the list !
>> 
>>> 
>>> Regards,
>>> Dave
>>> 
>>> 
>>>> --
>>>> 
>>>> Regards,
>>>> 
>>>> Kingsley Idehen
>>>> Founder & CEO
>>>> OpenLink Software
>>>> Company Web: http://www.openlinksw.com
>>>> Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>>>> Twitter/Identi.ca handle: @kidehen
>>>> Google+ Profile: https://plus.google.com/112399767740508618350/about
>>>> LinkedIn Profile: http://www.linkedin.com/in/kidehen
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>> 
>> 
> 
Received on Monday, 24 December 2012 19:26:49 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:30:02 UTC