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

From: Eld Zierau <[email-masked]>
Date: Mon, 16 Jul 2018 08:08:36 +0000

Please note that I have updated the suggested PWID URN for Persistent Web Identifiers with the following changes:

Prototypes for resolving a PWID and getting PWIDs for a web page has been added and explained. Furthermore, it has been made more clear where the PWID URN makes a difference and "closed archives" have to "archives with restricted access".

It is available as version 3 from https://datatracker.ietf.org/doc/draft-pwid-urn-specification/, and it is attached to this email as a pdf.

Best regards, Eld

-----
Eld Zierau
Digital Preservation Specialist PhD
The Royal Danish Library
Digital Cultural Heritage
P.O. Box 2149, 1016 Copenhagen K
Ph. +45 9132 4690
Email: [email-masked]<mailto:[email-masked]>

From: Eld Zierau
Sent: Monday, June 11, 2018 5:40 PM
To: [email-masked]
Subject: Sv: Suggested PWID URN for Persistent Web IDentifiers

Please note that I have updated the suggested PWID URN for Persistent Web IDentifiers in order to make it more clear where it makes a difference.  It can still be found via https://datatracker.ietf.org/doc/draft-pwid-urn-specification/ (also attached as pdf)

Best regards, Eld
Eld Zierau
IT-konsulent | Digital Preservation Specialist

Det Kgl. Bibliotek | Royal Danish Library
Digital kulturarv | Digital Cultural Heritage
P.O. Box 2149 | DK-1016 København K
tel +45 3347 4690 | Fax +45 3393 2218 | [email-masked]<mailto:[email-masked]> | www.kb.dk<http://www.kb.dk/>

Besøgsadresse | Visiting address | Søren Kierkegaards Plads 1

________________________________
Fra: Eld Zierau
Sendt: 8. december 2017 16:41
Til: [email-masked]<mailto:[email-masked]>
Emne: Suggested PWID URN for Persistent Web IDentifiers

Please find attached document with specification of the Suggested PWID URN for Persistent Web IDentifiers, which I have uploaded as an Internet-Draft (https://datatracker.ietf.org/doc/draft-pwid-urn-specification/)
draft-pwid-urn-specification-02 - A Persistent Web IDentifier (PWID) URN Namespace<https://datatracker.ietf.org/doc/draft-pwid-urn-specification/>
datatracker.ietf.org
A Persistent Web IDentifier (PWID) URN Namespace (Internet-Draft, 2018)

And please let me know if I have understood the procedures right about mailing this email and whether I have included all the information needed.

Best regards, Eld

Eld Zierau
IT-konsulent
Digital Preservation Specialist

Afdelingen for Digital Pligtaflevering og Bevaring

Digital Legal Deposit and Preservation

+4591324690

[email-masked]<mailto:[email-masked]>

Det Kgl. Bibliotek

Royal Danish Library

Søren Kierkegaards Plads 1

DK-1221 København K

+45 3347 4747

CVR 2898 8842

EAN 5798 000 795297

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 20 Jul 2018 23:11:57 -0400

Comments on this draft:

I am by no means an archivist, so my comments will be largely technical.

The draft seems to me to be prolix, giving a lot of discussion of
details that are not reflected in the URN proposal itself.  A careful
editing will probably fix this.

A major component of pwid-urn is archive-id.  My assumption is that the
archive-id is the top-level component and defines what abstract
"archive" the URN is a reference into.  And that the "archive" defines
the exact interpretation of archival-tine, coverage-spec, and
archived-item.  However, in order for PWID URNs to be unambiguous, it
must be unambiguous what "archive" a given archive-id refers to.  The
draft suggests "it is recommended to use the web domain as the identifier
for the web archive".

What if an institution decides to create PWID URNs that use an
archive-id which is a domain name that the institution does not own?  As
written, the draft does not forbid *me* from creating PWID URNs with
archive-id "netarkivet.dk".

In regard to archival-time, the draft states "The 'archival-time' [...]
can therefore be specified at any of the levels of granularity as
described in [W3CDTF]."  However, W3CDTF gives a number of formats for
time designations, and calls those formats "granularities", whereas this
draft allows only one format.  I suspect that a more careful description
of the meaning of the quoted sentence would fix this problem.

The syntax assumes that knowing archive-id, archival-time,
coverage-spec, and archived-item (the archived URI) will always be
sufficient to specify exactly the resource in question.  However, it
seems likely that special situations will arise when two distinct
resources will have attributes that are similar enough that the
distinction between them is not easily expressed in terms of archive-id,
archival-time, coverage-spec, or archived URI.  In this case, additional
information is needed to create an exact reference, and the URN syntax
needs to have an expansion facility to allow this.

archived-item can be a URI, and a URI can contain the characters '?',
'#', '[', and ']', among others.  However, those 4 characters may not
appear in the NSS part of a URN.  Note that the first 2 of these
characters are used in URIs only to introduce the "query" and "fragment"
parts, but as the draft is written, the archived-item URI is not
restricted to not having a query or fragment part.

Dale

---

From: [email-masked] (Henry S. Thompson)
Date: Fri, 27 Jul 2018 09:57:33 +0100

Eld Zierau writes:

> Please note that I have updated the suggested PWID URN for Persistent
> Web Identifiers with the following changes:
>
> ...
>
> It is available as version 3 from
> https://datatracker.ietf.org/doc/draft-pwid-urn-specification/, and it
> is attached to this email as a pdf.

[Before my comments, please note that I don't believe it's best practice
to attach drafts in mail to this list -- your original was classified as
spam as a result of the attachment, and I only found out about it as a
result of Juha's mail.]

Much of what follows is a critique of the requirements analysis and the
presumed use cases, rather than the specifics of the namespace itself,
and the overall conclusion is negative.

This is a bit unusual, in that I wouldn't normally bother with an
extended critique whose TL;DR would be "It doesn't seem likely to me
that this will solve anyone's problems".  After all, if it doesn't solve
anyone's problems, no-one will use it, let the 'market' decide, right?

This might be so, for a narrowly focussed namespace targetting a
specialist community.  But this proposal has _very_ large-scale use in
view.

_And_, the legitimacy of discourse around various aspects of
'persistent' reference has been so compromised by flawed analyses and
failed solutions that there is actually real reputational risk for the
urn infrastructure itself from yet another example, which I'm afraid I
think this is, particularly given its very high aims.

So, I'm sorry but for these reasons, and the many specific problems
discussed below, I don't personally see a future for this document.

============

Specific comments, by section

*Purpose*

As noted above, the goal stated in the open paragraph is very ambitious.

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.

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'.
------------
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".

*Syntax*

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.

*Assignment*

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

urn:pwid:web.archive.org:2018-01-01T17:03:53Z:part:http://www.ltg.ed.ac.uk/~ht/

One person might coin this to mean the text/html character sequence
which was served from http://www.ltg.ed.ac.uk/~ht/ (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
https://web.archive.org/web/20180101170353/http://www.ltg.ed.ac.uk/~ht/,
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.

*Interoperability*

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.

*Resolution*

None of this is very much to the point.  In particular, it completely
ignores the precedents set by doi.org, identifiers.org and n2t.net
(https://doi.org/10.1038/sdata.2018.95 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.)

ht

[1] http://sched.co/DJ3P
-- 
       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: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 27 Jul 2018 11:18:50 +0000

Hello, 

a few comments below. 

-----Original Message-----
From: urn <[email-masked]> On Behalf Of Henry S. Thompson
Sent: perjantai 27. heinäkuuta 2018 11.58
To: Eld Zierau <[email-masked]>
Cc: [email-masked]
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:

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, https://www.ed.ac.uk/) and a specific version is cited.  But when the page is supposed to be persistent (e.g. https://www.w3.org/Provider/Style/URI) 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 https://doi.org/<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)? 

Best, 

Juha

------------

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

*Syntax*

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.

*Assignment*

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

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 http://www.ltg.ed.ac.uk/~ht/ (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 https://web.archive.org/web/20180101170353/http://www.ltg.ed.ac.uk/~ht/,
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.

*Interoperability*

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.

*Resolution*

None of this is very much to the point.  In particular, it completely ignores the precedents set by doi.org, identifiers.org and n2t.net
(https://doi.org/10.1038/sdata.2018.95 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.)

ht

[1] http://sched.co/DJ3P
-- 
       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: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/  [mail from me _always_ has a .sig like this -- mail without it is forged spam]

_______________________________________________
urn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/urn