VIAF does conform to httpRange-14. 

IMO, the URIs identify what the RDF describes. Conformance boils down to use cases. If you don't care about use cases for the "extra" URI (or don't realize you do yet), that's OK. Life is full of regrets.



Sent from my iPad

On May 8, 2013, at 5:41 PM, "Tim Cole" <[log in to unmask]> wrote:



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 community (  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 pageemail address 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 course.»