Re: [RESOLVED] reminder: ack needed Re: Problem with Hash based Linked Data URIs

It's a pitty, given the huge amount of time the discussion on http-range-14
has taken up that this an issue of interaction with SPARQL would stand in the way
of thinking about this more clearly.


On 20 Nov 2013, at 17:25, Henry Story <henry.story@bblfish.net> wrote:

> 
> On 18 Nov 2013, at 23:19, Eric Prud'hommeaux <eric@w3.org> wrote:
> 
>> On Nov 2, I sent the attached message as a formal working group
>> response to a comment you sent to the RDF comments WG. Please review
>> the attached messgae and reply with the Subject prefixed with
>> "[RESOLVED]" if it addresses your comment.
>> 
>> -- 
>> -ericP
>> 
>> office: +1.617.599.3509
>> mobile: +33.6.80.80.35.59
>> 
>> (eric@w3.org)
>> Feel free to forward this message to any list for any purpose other than
>> email address distribution.
>> 
>> There are subtle nuances encoded in font variation and clever layout
>> which can only be seen by printing this message on high-clay paper.
>> From: Eric Prud'hommeaux <eric@w3.org>
>> Subject: Re: Problem with Hash based Linked Data URIs
>> Date: 2 November 2013 14:27:28 CET
>> To: Henry Story <henry.story@bblfish.net>
>> Cc: Mo McRoberts <Mo.McRoberts@bbc.co.uk>, Adrian Gschwend <ktk@netlabs.org>, "public-webid@w3.org Group" <public-webid@w3.org>, "public-rdf-comments@w3.org" <public-rdf-comments@w3.org>
>> 
>> 
>> * Henry Story <henry.story@bblfish.net> [2013-02-16 16:27+0100]
>>> 
>>> On 16 Feb 2013, at 16:04, Mo McRoberts <Mo.McRoberts@bbc.co.uk> wrote:
>>> 
>>>> As should be blindingly obvious to anybody who's worked with them, hash-based URIs are principally useful where a document describes a _single_ entity within its sphere of reference (though the nature of triples and many ontologies is that there may well be parts of descriptions of other things).
>>>> 
>>>> Ontologies/vocabs are a one solid case where it's really not a good idea to use them because it's hard to split them up into separately-served resources later.
>>> 
>>> I don' think that quite locates the problem at the right place.
>>> It would be completely feasible to have one #uri per vocabulary element, each at
>>> a different location. For example all of DBPedias resource URIs could just return
>>> the content inside so one could have 
>>> 
>>>   http://dbpedia.org/resource/Whiskey#x
>>> 
>>> defined by 
>>> 
>>>   http://dbpedia.org/resource/Whiskey
>>> 
>>> That would have the advantage of required half the requests on DBPedia to get 
>>> the information. The only problem I see with that is a syntactic one. I sent 
>>> this to the WebArch and RDF-Comments group as a mail and RDF group in November, 
>>> but got no  answer there yet
>>> 
>>> http://lists.w3.org/Archives/Public/public-rdf-comments/2012Nov/0009.html
>>> 
>>> I suppose one would need to propose a solution to the problem.
>>> Something allong the lines of requesting a new @prefix in Turtle 
>>> so that one could write:
>>> 
>>> @pre db: ("http://dbpedia.org/resource/" _ "#x")
>>> 
>>> This would allow one then to have
>>> 
>>> :j :likes db:Whiskey .
>>> 
>>> which would be equivalent to
>>> 
>>> :j :likes <http://dbpedia.org/resource/Whiskey#x> .
>> 
>> 
>> The RDF Working Group has considered the utility of your proposal
>> against the added complexity stemming from the new directive. We feel
>> it is better to stay compatible with SPARQL and let users take
>> advantage of the new PN_LOCAL_ESC¹ feature permitting one to embed '#'
>> in a localhost name after an escape character, e.g.  db.Whiskey\#x .
>> (You referred to this feature in your followup message.)
>> 
>> If you are satisfied with this response, please reply with a Subject:
>> starting with "[RESOLVED]".
>> 
>> 
>>>> (Ironically, as a redirecting service, if the PURL for GR had been http://purl.org/goodrelations/v1/ instead of http://purl.org/goodrelations/v1#, it could have redirected to either a hash-based or a hash-less URI — there's no benefit to hash-based URIs if you're always inserting a redirect _anyway_).
>>> 
>>> My guess is that you don't need these redirects in fact. But anyway, as far as WebID 
>>> goes the point is pretty moot, since as you point out below:
>>> 
>>>> 
>>>> On the other hand in the case of "this is the document which describes me" or "this is the document which describes this book", it makes a lot of sense to use hash-based URIs because that document has a notion of a primary topic while anything else described is a supporting adjunct. Even if it's aggregated into a dataset, the subject used in that dataset would be a URI which resolves to that one-thing document URI.
>>>> 
>>>> M.
>>>> 
>>>> On Sat 2013-Feb-16, at 14:33, Adrian Gschwend <ktk@netlabs.org>
>>>> wrote:
>>>> 
>>>>> On 16.02.13 12:10, Melvin Carvalho wrote:
>>>>> 
>>>>>> Hi Kingsley, just trying to understand the problem better.  When I
>>>>>> click, http://purl.org/goodrelations/v1#BusinessEntity it takes me to
>>>>>> the section of the GR vocab that is related to BusinessEntity (via html
>>>>>> anchors).  What should it be doing?
>>>>> 
>>>>> That's only because you requested it from a web browser, if you get that
>>>>> as RDF (via rapper for example) it will make a request to
>>>>> http://purl.org/goodrelations/v1 and instead of giving you the answer to
>>>>> what you really want to know  (#BusinessEntity) it downloads the whole
>>>>> ontology which according to rapper is 1834 triples. Everything after the
>>>>> # is handled client side and does not even get through the webserver.
>>>>> 
>>>>> This is not handy at all when you start to write code, you get way more
>>>>> than you wanted to know and it gets harder to implement local caching
>>>>> for example. Did that done that, really no fun to implement properly
>>>>> with hash based URIs.
>>>>> 
>>>>> So I'm really no fan of hash based URIs either, especially on bigger
>>>>> ontologies/datasets.
>>>>> 
>>>>> cu
>>>>> 
>>>>> Adrian
>>>>> --
>>>>> Adrian Gschwend
>>>>> @ netlabs.org
>>>>> 
>>>>> ktk [a t] netlabs.org
>>>>> -------
>>>>> Open Source Project
>>>>> http://www.netlabs.org
>>>>> 
>>>> 
>>>> --
>>>> Mo McRoberts - Technical Lead - The Space
>>>> 0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
>>>> Zone 1.08, BBC Scotland, Pacific Quay, Glasgow, G51 1DA
>>>> Project Office: Room 7083, BBC Television Centre, London W12 7RJ
>>> 
>>> Social Web Architect
>>> http://bblfish.net/
>>> 
>> 
>> 
>> 
>> -- 
>> -ericP
>> 
>> office: +1.617.599.3509
>> mobile: +33.6.80.80.35.59
>> 
>> (eric@w3.org)
>> Feel free to forward this message to any list for any purpose other than
>> email address distribution.
>> 
>> There are subtle nuances encoded in font variation and clever layout
>> which can only be seen by printing this message on high-clay paper.
>> 
>> 
> 
> Social Web Architect
> http://bblfish.net/
> 

Social Web Architect
http://bblfish.net/