Yes, thanks for this.  the examples that Hayes comes up with are always to
the point and a good read as well. But of course his argument is a bit
undercut (at least today) because to get to the HTML (PatHayesAbout.html)
from you do get redirected (albeit
a 302 response rather than a 303 response), so there is no HTML resource
with the same identifier, avoiding the issue of 1 identifier for two
different entities, the HTML page and the Person. The status 302 instead of
status 303 is inconsistent with the TAG 2005 compromise 'decision' on this
issue ( -
which granted may have come out after Hayes initially set up this page
(perhaps it prompted the redirect?).


Not to go too far down this rabbit hole, but those who haven't already had
their fill of TAG issue HTTPRange-14 might find of interest - the page was last
touched earlier this year, though the issue as such was finally declared
dead for TAG just over a year ago, pending of course updates to RDF that
keep getting talked about. Ten years of discussion about this basic issue!
The notes by Tim Berners-Lee (
and are worth a read as is which I
think speaks a bit as to why the TAG decision on this has not been a
complete success, i.e., why follows the TAG decision but why
ORCID and VIAF do not.  See also 


Though closed (more or less) for TAG, the issue still remains an issue for
the LOD community - see  re the
Internet-Draft RFC "HTTP/1.1 Semantics and Content" which came out for
comments in February and is currently open for review. The interpretation
(of page 15) is that one could avoid need for 303 by using the response
Content-Location header. (Not that this is being done either by ORCID at the
moment.) Personally, I'm not sure how I feel about this. It trades off
performance saving on one-side (fewer redirects) by making identification
slightly more cumbersome (you now have to check for a Content-Location
header before you know what's what). See also an earlier proposal from LOD
(  The
hash ID  approach of course still has proponents as well


Personally I think got it right. Go with status 303 redirect for
now and await further developments. 


Tim Cole

University of Illinois at UC




From: Simon Spero [mailto:[log in to unmask]] 
Sent: Wednesday, May 08, 2013 1:45 PM
To: [log in to unmask]
Cc: [log in to unmask]
Subject: Re: [BIBFRAME] bibframe properties with isomorphic URLs


On Wed, May 8, 2013 at 1:33 PM, Tim Cole <[log in to unmask]> wrote:

Perhaps it's overly pedantic for BIBFRAME purposes or explicitly excluded by
BIBFRAME use cases, but in RDF generically the use of as the identifier for Stuart Yates the
individual creates the potential for ambiguity since this same identifier is
also the identifier of an HTML Web page 


 Or as Pat Hayes puts it (


<Be it known to all agents that the purpose of this document is to determine
the referent of the URI

This document hereby declares, establishes and records the fact that the URI is owned by Pat Hayes and is
intended by Pat Hayes to rigidly denote himself, Patrick John Hayes,
commonly known as Pat Hayes, US resident alien and UK citizen, born in the
town of Newent, Gloucestershire, UK, on 21 August 1944, the only son of
Alexander and Betty Hayes and brother of Mary Ellen Hayes, of Canton,
Cardiff: the legal person and living breathing human being whose US social
security number is the decimal rendering of the hexadecimal 21D930EA and
whose facial features can be inspected in Brobdingnagian detail by clicking
here <> .

Any interpretation under which the URI denotes anything other than Pat
Hayes as described in this document is hereby declared to be an incorrect
and false interpretation. In particular, the URI does not denote the HTML document
that is related to that URI by the HTTP GET protocol, the rendering of said
HTML document that you are now reading, Pat Hayes' web page
<> , email address <mailto:[log in to unmask]>
or indeed anything that can be encoded in bytes and sent over a network.

Machine-readable information which may help fix the denotation of the URI will be added to this page in due