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

On 22 December 2012 18:10, Andy Seaborne <andy.seaborne@epimorphics.com>wrote:

>
>
> On 22/12/12 16:25, Melvin Carvalho wrote:
>
>>
>>
>> On 22 December 2012 15:41, David Wood <david@3roundstones.com
>> <mailto:david@3roundstones.com**>> wrote:
>>
>> On Dec 22, 2012, at 08:57, Melvin Carvalho <melvincarvalho@gmail.com
>> <mailto:melvincarvalho@gmail.**com <melvincarvalho@gmail.com>>> wrote:
>>
>>  May I propose that we register the well known address
>>>
>>> /.well-known/sparql
>>>
>>> with IANA.
>>>
>>> This could be a sparql endpoint for the domain queried,
>>>
>>
> Domains don't necessarily have one SPARQL endpoint.


Good point.  In the case where a site has more than one endpoint,
implementers will have to decide which graphs they expose.


>
>
>  and a helpful shortcut for both web based discovery, and also write
>> operations via sparql update.
>>
>
> Please do not conflate query and update.  It is one choice to put them
> at the same URI but, for integration in security architectures based on
> URI, not always a good choice.  SPARQL Query and SPARQL Update are
> different.  Registering as if they are the same, even if voluntary
> usage, seems to be encouraging a somewhat dubious choice.
>

That's true, though they both have sparql in common.  The original aim of
the web was for it to be a read / write collaborative space.  For example
HTTP has GET, but also PUT/POST/PATCH.  Indeed there are security
considerations here, but the same is true of http.


>
>
>>
>> +1.  Now, who is "we"?
>>
>>
>> Some comments from michael hausenblas:
>>
>> [[ Very simple, though not exactly quick ;)
>>
>> Just send to wellknown-uri-review@ietf.org
>> <mailto:wellknown-uri-review@**ietf.org <wellknown-uri-review@ietf.org>>
>> following [1].
>>
>>
>> However, note that the SPARQL WG pushed back when I suggested it:
>> http://lists.w3.org/Archives/**Public/public-rdf-dawg-**
>> comments/2010Jun/0000.html<http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2010Jun/0000.html>
>>
>>  Cheers, Michael
>>
>> [1] http://tools.ietf.org/html/**rfc5785#section-5.1.1<http://tools.ietf.org/html/rfc5785#section-5.1.1>]]
>>
>> 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.
>>
>
> Actually, that thread also asked some questions which still seem valid.
>
> That conversation didn't propose what information to put there.
>
> RFC 5785 suggests:
>
> [[
> 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 surely it should be some kind of domain map at /.well-known/sparql
> (the collection of all service descriptions of endpoints available maybe?)
>  Or just a list of endpoints (co0ncise) - you can pull the service
> descriptions from the endpoints themselves - that suggests using sitemaps
> to me.
>
> A response to the question about discovery by indexing service
> descriptions would also be good.  Generally, I worry about building
> architecture (a fixed name is architecture); it's tempting but is it
> necessary?
>
> A question I'd add is about suitability of / root URIs.  It's not always
> possible to put content there (e.g. hosting; integration into a larger
> application).  The sitemap protocol addresses this.
>

We already have "void" [1] as part of .well-known, so perhaps that would
suit some needs.  I've been trying to get people to use "void" for years,
but it's challenging to pitch and it's also an extra round trip.  This can
be a big deal to large deployments.

Trying to persuade large firms such as microsoft or google to deploy void,
is really hard.  Even explaining what sparql is can be a challenge.  They
will deploy webfinger though.  Which is very similar to a specific sparql
query.  It could be nice if those big firms that deployed webfinger found
they could upgrade sparql in the same way.

I really do sympathize with the points you make, and I am not a fan of
.well-known hard coding at all, and certainly we dont want to open the
floodgates to this kind of thing.  But as a tactical move, to get sparql
more deployed, to try and help the web reach it's full potential, it may be
practical.

[1] http://www.w3.org/TR/void/


>
>         Andy
>
>
>
>>
>> Regards, Dave -- http://about.me/david_wood
>>
>>
>>
>>
>