Re: Problem with Hash based Linked Data URIs

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

Received on Saturday, 2 November 2013 13:28:00 UTC