Re: [urn] PWID URN namespace registration with latest draft version 12

[Peter Saint-Andre <[e-mail]>]

This namespace is now registered:

https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

On 11/15/22 2:08 PM, Peter Saint-Andre wrote:
> After much discussion, the expert review team has asked IANA to register 
> the `pwid` URN namespace. Multiple revisions have resulted in a 
> registration that conforms to RFC 8141. Because it is not the expert 
> review team's role to determine the usefulness of URN namespaces (as 
> would be done in a standardization venue such as an IETF Working Group), 
> we have found no basis for denying the registration of this namespace. 
> Therefore, despite our own personal doubts about some aspects of the 
> namespace, we have decided to allow its registration.
> 
> Peter
> (on behalf of the expert review team)
> 
> On 4/22/21 4:07 AM, Eld Zierau wrote:
>> Dear all
>> I hope you are all still well in spite of the pandemic.
>> I have not asked to the progress for some time, due to different 
>> reasons related to this difficult time.
>>
>> As two of you have already approved this PWID URN, I would be happy if 
>> we can find a way for it.
>>
>> It is very important for us to have the PWID URN. In Denmark, PWID is 
>> the recommended way to reference web archive material. We use it in 
>> scientific papers, as well as for specification of elements in 
>> collections of web material. As example collections, we have just 
>> produced collection of PWIDs for the "Probing a Nation's Web Domain" 
>> project 
>> (http://www.netlab.dk/research/projects/probing-a-nations-web-domain-the-historical-development-of-the-danish-web/).
>>
>> I have answered all comments and questions, which have been raised, 
>> either by explanation or by slimming the suggested PWID e.g. only 
>> leaving page and part in the precision specification.
>> The only "weak" point I see in the current version is the reference to 
>> the web archive. It would be best if there existed a registry, but 
>> this is not the case. However, I am convinced that the suggested way 
>> is absolutely workable, until a registry is in place - and I will of 
>> course work hard to get such a registry established as soon as the 
>> PWID is accepted - e.g. in cooperation with the International Internet 
>> Preservation Consortium (IIPC) https://netpreserve.org/.
>>
>> The current web archive identification is workable, since it is 
>> findable as long as the domain exists. In case of change, it will be 
>> possible to track the change through archived harvests of the web 
>> archives domain. We actually have the example in Denmark where the 
>> merge of the two libraries (who jointly had the Danish web archive) 
>> has resulted in https://netarkivet.dk being moved to 
>> https://www.kb.dk/find-materiale/samlinger/netarkivet, where 
>> netarkivet.dk redirects to the new place. There are several examples 
>> of web archives changing domains or paths to their web archive 
>> material. However, it has so far been possible to track the change, 
>> usually, because the old URL is redirected to new one.  These 
>> redirects will probably be there for some years, but at some stage 
>> they are also likely to be removed. No matter whether it is redirects 
>> or announcements, it will be information that will be harvested and 
>> kept in web archives. That means it will be traceable by looking in 
>> web archives that have harvested this data. So workable for now, but 
>> of course best placed in a coming registry, which is likely to be in 
>> place before this become an issue.
>>
>> In my involvement in WARCnet (https://cc.au.dk/en/warcnet/), it is my 
>> experience that there is also a need for the PWID internationally, 
>> especially when web archives changes domains or paths to data. There 
>> are examples for references with archived URLs in research datasets, 
>> which overnight have become almost useless for this reason. I am 
>> bringing in the PWID here, as a way to solve this as part of the 
>> research data management work related to web archives.
>>
>> At the International Internet Preservation Consortium (IIPC) 2021 
>> conference, I will present the work we have done with representation 
>> of PWIDs collections (as mentioned above). The collections from the 
>> "Probing a Nation's Web Domain" project contains elements harvested in 
>> a specific year, where each web element only appears once (although 
>> the web element was harvested many times during the year). The 
>> collections were originally produced by an extraction program, which 
>> ran on the Danish web archive (Netarkivet). The collections are now 
>> migrated to collections of PWIDs, which are much more sustainable as 
>> target for preservation, enabling future check of results and enabling 
>> establishment of comparable results. One non-sustainable alternative 
>> would be to save the extraction program. However here, the problem 
>> will be, that we cannot be sure that the extraction program will be 
>> functioning in the future, and even so whether it will produce the 
>> same result (archive can have been enriched with new data). Another 
>> alternative would be to preserve the outcome of the extraction 
>> program. However, this is not a standardized format, and it refers 
>> metadata (crawl-logs) rather than registered archive metadata, - thus 
>> even with thorough documentation, it will be hard to re-track and 
>> understand this output even in a 10 years' time horizon. Therefore, 
>> the PWID collections are in a more sustainable format as well.
>>
>> Please consider final approval of the PWID URN or tell me what is 
>> needed for it to be approved and published as a URN namespace.
>>
>> Best regards, Eld
>>
>> PS: I have attached the latest draft which followed with the mail 
>> included below
>>
>> -----
>> Eld Zierau
>> Digital Preservation Specialist PhD
>> The Royal Danish Library
>> Digital Cultural Heritage
>> P.O. Box 2149, 1016 Copenhagen K
>> Ph. [phone]
>> Email: [e-mail]
>>
>> -----Original Message-----
>> From: Eld Zierau
>> Sent: Tuesday, May 26, 2020 10:01 AM
>> To: 'Dale R. Worley' <[e-mail]>; [e-mail]
>> Subject: RE: PWID URN namespace registration version 10
>>
>> Thank you Dale
>>
>> My comments is given below, and updated version is attached with 
>> following corrections:
>> - added draft information in filename/header
>> - description of archive-domain
>> - syntax for utc-time
>> - date of document
>> Best regards, Eld
>>
>> ---------------------------------------------------------------------------------------
>>
>> My apologies for not giving this attention sooner.
>>
>> I've read version 10, and I think we should approve it.  I have the 
>> following observations, which include one editorial suggestion.
>>
>>
>> I assume that the attachment to message
>> https://mailarchive.ietf.org/arch/msg/urn/x_JVtfKpANKZz6Qr8iOqpsXJ8SU/
>> "PWID URN (shortened title)" is draft verson 10, despite that neither 
>> the attachment's name or contents states that.
>>> Eld: At some stage, I was told that it is version 1, maybe I
>>> misunderstood, but I thought the document date then indicated the 
>>> version.
>>> It was actually draft version 11. In the attached draft version 12, I
>>> have put in the information about it being draft version 12
>>
>>
>> I particularly support the PWID proposal for the reasons I described 
>> in "PWID as citation"
>> https://mailarchive.ietf.org/arch/msg/urn/s-CM7hcWtUeAz7ZVBF94rCHMtsQ/
>> -- namely that what a PWID references is transparent enough that one 
>> could algorithmically transform a PWID pointing to one archive into a 
>> query into another archive.  This is a genuinely new capability for 
>> URNs (as far as I know) and only by deploying it in practice can we 
>> see what benefits might be obtained.
>>> Eld: Agree
>>
>> I still dislike that there's no well-defined way to catalog allowed 
>> values of archive-dimain.  But the number of values that are used will 
>> likely remain small and there are unlikely to be "ownership conflicts"
>> about them, so this is unlikely to be a problem in practice.
>>> Eld: I agree, and I will certainly work on other fronts to make it 
>>> possible to make more
>>> precise reference, but this is what exists at the moment.
>>
>> A minor editorial point:
>>        *  'archive-domain' is defined as in (section 3.5) [RFC1034].
>> "archive-domain" is not defined in RFC 1034.  You need to say
>>        * 'archive-dimain' is <subdomain> as defined in (section 3.5) 
>> [RFC1034].
>> (Oddly, you do want to use <subdomain> rather than <domain> defined in 
>> that section.)
>>> Eld: You are right - it is subdomain because <domain> ::= <subdomain> 
>>> | " " and we want to avoid the " " possibility.
>>> I have corrected in the attached  draft version 12
>>
>>
>> I see that if utc-time is part of archival-time, then it must contain 
>> both utc-hour and utc-minute, whereas utc-second and secfrac can be 
>> added independently.  This is a bit of an inconsistency, but I assume 
>> you intend it.
>>> Eld: That is actually an error, - I have corrected it, so it is 
>>> possible just to specify the hour without minutes
>>
>> Given that precision-spec is currently limited to one of two values, 
>> later extensions can be indicated by additional values defined for 
>> this field.
>>> Eld: Agree
>>
>> Dale
>>
>> -----
>> Eld Zierau
>> Digital Preservation Specialist PhD
>> The Royal Danish Library
>> Digital Cultural Heritage
>> P.O. Box 2149, 1016 Copenhagen K
>> Ph. [phone]
>> Email: [e-mail]
>>
>> -----Original Message-----
>> From: Dale R. Worley <[e-mail]>
>> Sent: Sunday, May 24, 2020 5:19 AM
>> To: Eld Zierau <[e-mail]>; [e-mail]
>> Subject: Re: PWID URN namespace registration version 10
>>
>> My apologies for not giving this attention sooner.
>>
>> I've read version 10, and I think we should approve it.  I have the 
>> following observations, which include one editorial suggestion.
>>
>> I assume that the attachment to message
>> https://mailarchive.ietf.org/arch/msg/urn/x_JVtfKpANKZz6Qr8iOqpsXJ8SU/
>> "PWID URN (shortened title)" is draft verson 10, despite that neither 
>> the attachment's name or contents states that.
>>
>> I particularly support the PWID proposal for the reasons I described 
>> in "PWID as citation"
>> https://mailarchive.ietf.org/arch/msg/urn/s-CM7hcWtUeAz7ZVBF94rCHMtsQ/
>> -- namely that what a PWID references is transparent enough that one 
>> could algorithmically transform a PWID pointing to one archive into a 
>> query into another archive.  This is a genuinely new capability for 
>> URNs (as far as I know) and only by deploying it in practice can we 
>> see what benefits might be obtained.
>>
>> I still dislike that there's no well-defined way to catalog allowed 
>> values of archive-dimain.  But the number of values that are used will 
>> likely remain small and there are unlikely to be "ownership conflicts"
>> about them, so this is unlikely to be a problem in practice.
>>
>> A minor editorial point:
>>        *  'archive-domain' is defined as in (section 3.5) [RFC1034].
>> "archive-domain" is not defined in RFC 1034.  You need to say
>>        * 'archive-dimain' is <subdomain> as defined in (section 3.5) 
>> [RFC1034].
>> (Oddly, you do want to use <subdomain> rather than <domain> defined in 
>> that section.)
>>
>> I see that if utc-time is part of archival-time, then it must contain 
>> both utc-hour and utc-minute, whereas utc-second and secfrac can be 
>> added independently.  This is a bit of an inconsistency, but I assume 
>> you intend it.
>>
>> Given that precision-spec is currently limited to one of two values, 
>> later extensions can be indicated by additional values defined for 
>> this field.
>>
>> Dale
>>
>>
>> _______________________________________________
>> urn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/urn
>