Re: Problem with Hash based Linked Data URIs

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



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