W3C home > Mailing lists > Public > public-rdf-comments@w3.org > September 2014

Re: genid example from RDF1.1 is bad

From: <henry.story@bblfish.net>
Date: Thu, 25 Sep 2014 10:52:22 +0200
Message-Id: <E5B49FD5-746D-4DB8-AF40-EC9E1F6358BD@bblfish.net>
To: public-rdf-comments <public-rdf-comments@w3.org>
To avoid cross posting this discussion was continued on the semantic-web mailing list.
At present here are the relevant posts:

David Booths reply: http://lists.w3.org/Archives/Public/semantic-web/2014Sep/0098.html
My response:           http://lists.w3.org/Archives/Public/semantic-web/2014Sep/0099.html
David Booth replies - highlight ( he notices the point of the bnode URN proposal )
                                http://lists.w3.org/Archives/Public/semantic-web/2014Sep/0104.html
My reply:                 http://lists.w3.org/Archives/Public/semantic-web/2014Sep/0105.html

And then some further initial discussion about the bnode proposal .

Henry

On 23 Sep 2014, at 08:59, henry.story@bblfish.net wrote:

> I just noticed the section on using ".well-known" URIs for skolemisation in the RDF1.1 spec.
> This lead to the following exactract of a conversation on the Linked Data Protocol mailing list.
> I am 100% against that and believe it should be removed for the next version of the RDF spec.
> I also propose a path to an improvement for it.
> 
> On 23 Sep 2014, at 00:40, Pierre-Antoine Champin <pierre-antoine.champin@liris.cnrs.fr> wrote:
> 
>> Hi Henry,
>> 
>> On Mon, Sep 22, 2014 at 4:06 PM, henry.story@bblfish.net <henry.story@bblfish.net> wrote:
>> 
>> I find genids pretty hackish part of the rdf1.1 spec frankly. Genids are recognised apparently by analysing the schema 
>> of the URI, which is pretty much against web architecture. 
>> http://www.w3.org/TR/rdf11-concepts/#section-skolemization
>> 
>> So now every RDF linked data client would need to look at each URI to see if it contains a ".wellknown/genid" string to know if it should follow it
>> or not. That's pretty un linked-data-ish. Frankly I am quite surprised it made its way through to the spec. The people supporting it
>> must have made a lot of noise.
>> 
>> Not everything is about your particular use case, Henry ;-)
> 
> The arguments I am relying upon, which I will make explicit to you below, go way beyond my particular use case,
> and don't just take into account one spec, but the whole ecosystem of the web.
> 
>> 
>> RDF does not equate linked data. It does not mandate URIs to be derefenceable. In that regard, genid URIs are no special case, so they do not need the special treatment that you suggest above. If you try to dereference them, you will get a 404, that's all. It's not ideal in a Linked Data perspective (though not lethal either), but it is perfectly acceptable from the point of view of RDF.
> 
> RDF 1.1 is part of a series of specification, where each specification does its job. is specified at the logical layer, so all it requires 
> is the concept an IRI. That is the concept of a name with a referent. It's not  part of the mandate of RDF to specify how IRIs are meant to work.
> 
> But the IRI specs on the other had do have something to say on the issues, and so does the overriding habit of use on the web. That is 
> that an http, https, ftp, ftps uris refer without #uris refer to resources on the web which can be accessed by making an HTTP GET on that
> resource. Minting http URIs with the aim that they would return a 404 is just extreemly bad practice. A bit like a web site that had links that
> lead nowhere. Your web site would very soon be placed on the list of abandoned web sites, your ranking would fall dramatically in 
> search engines, your user experience would be lousy, etc... ( And note that the RDF1.1 spec says nothing about this type of user experience 
> either, but that does not mean it does not exist ).
> 
> So I don't of course have anything against skolemisation, which makes perfect sense, but the example of a skolemisation URI
> used in RDF1.1 is absolutely repulsive, and SHOULD be removed as soon as possible.
> 
> Instead they should choose a URN that does this or create a bnode URN type such as
>   bnode:{domain}:{path}:{etag}:{identifier} 
> 
> where it is explicit that  this URN cannot be dereferenced
> 
> Henry Story
> http://bblfish.net/
> 
> 
> 
> 

Social Web Architect
http://bblfish.net/


Received on Thursday, 25 September 2014 08:52:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:46 UTC