Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3

"Hakala, Juha E" <> Fri, 27 July 2018 11:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0497D130F1E for <>; Fri, 27 Jul 2018 04:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MARnUc9-lxcO for <>; Fri, 27 Jul 2018 04:18:57 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:fe02::728]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A18C12872C for <>; Fri, 27 Jul 2018 04:18:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-helsinki-fi; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xBoncUnsku++jMX7UDEBfzAxMhqs2hx9FrGVnMHlgtM=; b=rlx6E+C2UKEhL/U3A3eRv0MzLLr2GhNzGRhiKa1GU0sUS5uvTYx0zXv17ixuW1KER9VTCtfCQo1DFINxMAIv0BgAF/SELw050QE22PJ/4+kWkJB8ezebeMrqs9tgYmuWVFJfCeyvE5TL2ySrGK5VrBa8NnwOYAR+37ket2gHdug=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.7; Fri, 27 Jul 2018 11:18:51 +0000
Received: from ([fe80::30c2:9bcd:73cc:27e2]) by ([fe80::30c2:9bcd:73cc:27e2%2]) with mapi id 15.20.0995.019; Fri, 27 Jul 2018 11:18:50 +0000
From: "Hakala, Juha E" <>
To: "Henry S. Thompson" <>, Eld Zierau <>
CC: "" <>
Thread-Topic: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3
Thread-Index: AdQc3DGKkm3uj4RtRcGB26kVRboqjAIq80gfAAI7PJA=
Date: Fri, 27 Jul 2018 11:18:50 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: fi-FI, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; HE1PR07MB3323; 6:K93wMR7zHnY90ZUv1IZiyHHuXnEPWgGAC5NMnbmPhvCuM1imstdcVNlFI9pgeSNbJ0D0r5ubcLlzsKaeVQM6e7n1JZcLRHwfWldi4pV89tw/QXLgOav4ttydlwQRQoQmxTOP+McLp+yGP11nuHy8Om1/UsWl1v5hI5UITmvVqc9s5Of0F3RLOhddqbsop0OV2QS+PEBIIe7njeA/dex15FBO+ofb5YCMc8U/5EPjqSiXkSD/InUuOR+uqfR/8iDcKIgQb1vhJKqioHhgzq88oCm48ec8yN9/kc6n62gG47tZ/vBBEXc323rBi22tMNoMVzLZefrnp6BCKEmpOFk5rELyF6JvUxqVV5Eb2fccl8Qmj4+ReIwlhiFxo3KzloxDOlGWvFa4W2L+PDFucuJv2iMId7sCjdQDV1btD/EMCVHFrilX5tDIC4jCAR71VQps3CMMJczNWAaUns1/GBujXw==; 5:SHQV/mptHwcAtcP7epb9WRWPyUDrDdIeJ4nhguVNdWp6tROG6GRWTsu7QLKFf9HcE6gy1vAw0EL3ro0uWXzXIOMSWn72Opxk1rls5sBoVIOVfRGiZkWeYnRKitDFFwMyfiO1eDLrJYRDdpjbAFpmlzNAJNr8l4g9vHKOVmqm2gQ=; 7:4P7s38bJv/XWVRpc0/s37wFZGbsSUsmZqemGmG/x31j65UGSGUdEqBjzmUi1o3U5WsbfvNKYAn19mSOwNO+IQ+DVZxHH92NlaUeUs5MLuLX0NIWlXH4z2RQ/RuFfp6d5/WBdJWCoAqOHku37hFunUrsY8JlXrZmUxMDl8WrHA58zxp2xsPb7dUSXSveF34LTrF5jAHy7wErwwOonOlUbo0LFl0V3k8B2LEpNWuwcamFMOO3hlSUgqV0dc25/tCId
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 19c01784-01c3-409e-8d34-08d5f3b2bb00
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600074)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3323;
x-ms-traffictypediagnostic: HE1PR07MB3323:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(165104125076784)(233993556339841)(130608784459683)(235534655456582)(181193635805523)(223725956011154);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231311)(11241501184)(806099)(944501410)(52105095)(10201501046)(149027)(150027)(6041310)(201703131423095)(201703031522075)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:HE1PR07MB3323; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3323;
x-forefront-prvs: 07467C4D33
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(396003)(346002)(376002)(39860400002)(189003)(199004)(252514010)(13464003)(99286004)(76176011)(6506007)(6116002)(186003)(3846002)(33656002)(2906002)(561944003)(5660300001)(7696005)(26005)(102836004)(74316002)(478600001)(6306002)(7736002)(305945005)(14444005)(256004)(14454004)(2900100001)(1720100001)(966005)(81166006)(81156014)(105586002)(8676002)(106356001)(8936002)(68736007)(296002)(786003)(110136005)(6436002)(74482002)(66066001)(97736004)(316002)(5250100002)(217873002)(9686003)(53366004)(25786009)(476003)(53376002)(55016002)(53936002)(6246003)(4326008)(11346002)(86362001)(446003)(486006)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB3323;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-microsoft-antispam-message-info: atOq5zzB4T3RanrBSbaZSo60ey74WcYpZ0mKYCr7dNVbDQBrSKxhhBbkqzqFiysL1/+32uAOqY+7NTf4S8a2LnKty07trNEw1Um8FASbkU1KCKutJ9ywOJFi1+lT7OUBk3fzVc4ENdMvX4kqvRdOdBzrpLv4da6RQ8IJf4HHC9eo+xsKPNV51QlBKesMh4Ab9ZqfAXYNrYv3IQ2WZ0pqyDm2ddG0zPDmeUAorekIOMLtPQe6yBpF6Fr/263flu5hQm/kJrovO2PjSFH0WOx6da7MNF/LrAXJbD1gdF1x/cf07OmnUKDwvvlArULGHLTC56PxNQVThMZ1yGs6rAVgvz4et09fQ5X08EpWErsPlIL5wPNQ8PpfPuuxmyi4KOwZedZ/t0HbJ3/sZYoEKqpz+A==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 19c01784-01c3-409e-8d34-08d5f3b2bb00
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2018 11:18:50.8195 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 98ae7559-10dc-4288-8e2e-4593e62fe3ee
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3323
Archived-At: <>
Subject: Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 27 Jul 2018 11:19:03 -0000


a few comments below. 

-----Original Message-----
From: urn <> On Behalf Of Henry S. Thompson
Sent: perjantai 27. heinäkuuta 2018 11.58
To: Eld Zierau <>
Subject: Re: [urn] Suggested PWID URN for Persistent Web IDentifiers - version 3

The only parts of the argument that follows that I can make sense of, as to why the proposed scheme is needed, consist of two mistaken and/or unsupported high-level claims:

 1) Citations of web-hosted resources should refer to archives, not to
    the resources themselves;

 2) Citation of archived material needs help to be sufficiently 'precise'.

The first is at best contentious as a general claim, and even in cases where an archive reference is preferred, why packaging it in a PWID urn will add value is not explained.  After all, if I know that what I want to cite is available in some archive, it's because I've found it there, in which case I already _know_ the URI I can use to retrieve it.  More on this when below when we come to the question of uniqueness.

Juha: ISO TC 46/SC 9 is currently revising ISO 690 (Guidelines for bibliographic references and citations to information resources). One of the challenges is how to deal with reference rot, which consists of link rot (404) and content drift (retrieved documents change). A large percentage of all Internet resources suffer from these problems. 

Eld has been most helpful in writing the Annex that discusses the usage of Web archives in detail, and the current version is based on what she has written, with two important exceptions: 

- I don't think that referring just to a copy of the cited resource in a Web archive is always the best solution. Archive reference only must be used when the resource is dynamic (say, and a specific version is cited.  But when the page is supposed to be persistent (e.g. the added value provided by the archive link may be modest, because the archived copy may not always be exactly the same, and web archives themselves may not last forever. The current draft of ISO 690 (which is still only a working draft) does promote the use of web archives, but not as the only solution. And if web archives are used, utilization of Memento is something that should be considered since it provides some level of protection to disappearance of web archives.  

- the current ISO 690 draft does not mention PWID. There are three reasons for this. First, and most importantly, PWID does not (yet) have a registered URN namespace. An ISO standard cannot refer to PWIDs as long as namespace registration has not been completed. And IMO it is not obvious that it will be completed. Second, every persistent identifier that will be included in the examples or elsewhere in the standard must be actionable (expressed, for the time being, as HTTP URI). So all DOIs that were in the form doi:<DOI string> have been converted into<DOI string>. This will not possible with PWIDs, since only the Danish web archive is planning to implement PWIDs, in an archive which has strict access limitations. 

When you consider what to do with PWID, keep in mind that as a national library the Royal Danish Library can always use the NBN namespace for items in the web archive. For instance, something like urn:nbn:pwid:<pwid> can be constructed, as long as the <pwid> string conforms to the syntactical requirements of the NBN namespace.    

Henry: The second surely applies to any kind of citation at all, and seems to depend on a confusion between web identity, media type and the ontology of citable things and loci associated with them -- all of FRBR lurks just around the corner here.

Just because some representation is hosted on the Web does not make it easier (or harder) than it ever was to make clear in a citation what part/aspect/property of what you _name_ in a citation is what you actual are _referring to_.  More on this below when we come to the 'coverage-spec'.

Juha:  trying to express in PWID coverage-spec which part of the of the resource has been cited may be more difficult that providing this information elsewhere in the citation. ISO 690 draft specifies such an alternative approach.  And even if PWID really has to be used for this purpose, usage of f-, r- and q-components may also be considered as an alternative. 

As Henry says below, coverage-spec would need a lot more alternatives to be truly useful. Coverage-spec "other" does not add much value, and it would be necessary to use it for every image, video, etc. And if there are several images on the page, how to indicate the right one (except with f-component)? 



One more specific issue with this section

  "The precision regards both regards precise reference where there
   can be no doubt about that you have the correct web material as
   well as precision about what is actually referred by the reference
   (e.g. is it the page or the whole website)"

There's nothing in the proposal which follows to back up the "you have the correct web material" claim, and the subsequent inventory of 8 'type[s] of archived item[s]' is clearly not sufficient to unambiguously determine "what is actually referred [to] by the reference".


I see no problems in the ABNF.
The definitions of the 'coverage-spec' values are hopelessly underspecified, and heterogenous.  The 'part'/'page' distinction is particularly unclear/non-obvious/ambiguous/medai-type dependent.


The initial claim here and its subsequent gloss taken together don't hold up:

 "The PWID URNs does not have to be assigned by an authority, as they
  are based on the information created at the time of archiving:"

 "In other words: the PWID URNs are created independently, but
  following an algorithm that itself guarantees uniqueness."

On a strict reading of "uniqueness" (i.e. a one-to-one relation between items and PWIDs), this amounts to a claim that _any_ 3rd party considering _any_ item in _any_ archive will always construct the _same_ PWID.  This reading is obviously false: the presence of the the two "+( unreserved )" expansions in the ABNF amount to a _guarantee_ that there will be multiple distinct PWIDs for the same item.

RFC8141 does not require one-to-one relations between URNs, even URNs within the same namespace.  But it does require, in the case of "URNs .. . . created independently" that they be created "following an algorithm that itself guarantees uniqueness".  The underspecification of the 'coverage-spec' already alluded to above makes independent _and_ inconsistently understood coinages of identical PWIDs not just possible but likely.  Consider for example

One person might coin this to mean the text/html character sequence which was served from (my homepage at the University of Edinburgh) at the beginning of 2018, whereas someone else might coin it to mean the text/html character sequence you get from the Web Archive today if you do an http GET on,
which are different in important ways.

In general, it seems that knowing whether to use 'part' or 'page' would depend on a detailed understanding of the media type of the retrieved representation, which the average creator of a citation is unlikely to have.
Some of this is corrigible, but only at the expense of a vast increase in detail and clarity.  Others not-so-much, insofar as so much is _necessarily_ left underspecified, to allow for _anything_ to be considered as an archive ('archive-id' value), with the consequent requirement to allow for arbitrarily idiosyncratic internal naming mechanisms ('archived-item' value).

I'm curious in this connection to wonder if we actually have any URN namespaces where assignment is done "independently but following an algorithm that itself guarantees uniqueness"?  Ah, there are registrations for urn:uuid:, which qualifies, and urn:oid:, which sort of does.  OK, is there such a namespace in active use?  Which provides for resolution, at least in principle?

A crucial point here is that in the OID case a urn:oid:... carries a chain of responsibility with it.  If you run across one, you know how to find out who takes responsibility for every level in the tree that's involved in interpreting it.  In the UUID case, a urn:uuid: doesn't travel well/at all, so the question doesn't arise.  But for PWIDs, if I find one I have _no way_ to figure out who's responsible, or whom I can ask for clarification, or whom to blame if it doesn't appear to 'work'.
I don't see what the intended value of the discussion of the "SOLR-Wayback tool" is for the spec.


The above comments about ambiguity/lack of identity apply here too: if different implementors interpret e.g. a coverage-spec of 'subsite'
differently, their resolvers will not interoperate.


None of this is very much to the point.  In particular, it completely ignores the precedents set by, and
( exemplifies the first and its content discusses the second and third). 


In conclusion, I think a useful way to think about this proposal is as a misguided attempt to define a urn type which _is_ a citation.  This makes sense of PWID's 3rd party nature, and clarifies that the archive-id and -time, the embedded URI and the coverage spec are just a pretty arbitrary, certainly impoverished, subset of what you would expect to find in a _real_ citation.  Trying to pack a citation into a URN just doesn't make sense to me. Neither does trying to determine exactly the _right_ subset of citations of web-hosted resources to pack up in order to be both useful and unambiguous.

(There is work underway in various venues (see e.g. [1]) to _objectify_ citations and give PIDs to _those_, which might address at least some of the goals of this work.)


       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail:
                       URL:  [mail from me _always_ has a .sig like this -- mail without it is forged spam]

urn mailing list