Re: genid example from RDF1.1 is bad

Hi Henry,

On 09/23/2014 02:59 AM, 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
> <mailto:pierre-antoine.champin@liris.cnrs.fr>> wrote:
>
>> Hi Henry,
>>
>> On Mon, Sep 22, 2014 at 4:06 PM, henry.story@bblfish.net
>> <mailto:henry.story@bblfish.net> <henry.story@bblfish.net
>> <mailto: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

I assume you are referring to the principle of URI opacity: that one 
should not make unlicensed assumptions about the nature of a 
URI-identified resource based on the syntax of the URI.  But RDF genids 
are based on .wellknown path prefix in conformance with RFC 5785
http://tools.ietf.org/html/rfc5785
so this use of ./wellknown/genid as a path prefix to indicate skolemized 
blank node URI *is* licensed and does *not* violate the principle of URI 
opacity.

>>
>>     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.

Agreed.

> 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.

I assume the example you mean at
http://www.w3.org/TR/rdf11-concepts/#h3_section-skolemization
is the URI
http://example.com/.well-known/genid/d26a2d0e98334696f4ad70a677abc1f6

Are you objecting to that URI because it uses example.com instead of an 
actual domain name, and therefore it is not dereferenceable?   Avoiding 
example.com for that reason would seem to me to defeat its purpose.  Or 
are you objecting to it because it is an http: URI, and you are assuming 
that skolemized URIs will not be dereferenceable?   Servers can be set 
up to make them dereferenceable, but probably not with as much value as 
normal URIs in Linked Data.

>
> 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

That might be better for skolem URIs that are not intended to be 
dereferenceable.  But what if a decision is made later to make them 
dereferenceable?  It would be bad to have to change them all.  It seems 
to me that a better balance would be to make them http: URIs, but 
configure servers to return a generic message each time any 
.well-known/genid/ URI is dereferenced, pointing to the above section of 
the RDF specs.  OTOH, a client seeing an http: .well-known/genid URI 
could also have different expectations about whether such URIs are 
likely to be dereferenceable.

David

Received on Tuesday, 23 September 2014 19:47:20 UTC