- From: David Booth <david@dbooth.org>
- Date: Tue, 09 Oct 2012 13:08:58 -0400
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: Jeni Tennison <jeni@jenitennison.com>, www-tag <www-tag@w3.org>
Hi Noah, On Tue, 2012-10-09 at 03:15 -0400, Noah Mendelsohn wrote: > . . . Speaking for myself, not the TAG as a whole: > it never occurred to me that the usage primer would be taken to discourage > the "minting" separate URIs for landing page and subject. I assume everyone > involved thinks thats architecturally preferable when practicle. > > I read the primer as providing useful advice for the many situations in > which, for good or bad reasons, such separate URIs are not created. I think it's important to distinguish between different roles in the URI lifecycle: - For an RDF *author* -- i.e., someone/something writing and publishing RDF -- the author has the choice of making the distinction between the landing page and its subject. If he/she chooses to make this distinction, then he/she can further choose how to do so, and two of the options would be: (a) to mint separate URIs for them; or (b) to use the punning properties technique described in http://www.w3.org/2001/tag/doc/uri-usage-primer-2012-10-03/ - For an RDF *consumer* -- i.e., someone/something that reads RDF -- the consumer has no choice about whether the RDF that was received makes the landing-page-versus-its-subject distinction: it either does or it doesn't. So AFAICT, the punning properties technique is not intended for this case. In this case what's needed is an after-the-fact way of "splitting" the resource identity, as described (sketchily) here: http://dbooth.org/2007/splitting/ So it seems to me that the situation in which the punning-properties approach would be applicable -- the RDF authoring situation -- is a situation in which the author probably would have the choice of using that approach or minting separate URIs. -- David Booth, Ph.D. http://dbooth.org/ Opinions expressed herein are those of the author and do not necessarily reflect those of his employer.
Received on Tuesday, 9 October 2012 17:09:34 UTC