Subject: Re: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)

From: "Hakala, Juha E" <[email-masked]>
Date: Thu, 14 Nov 2019 12:54:58 +0000

Hello Eld, 

sorry for delay with reviewing this PWID draft. 

I say what Dale has said earlier: this version answers the concerns I've had earlier. I have no new issues, so I approve this namespace registration request. 

Section "Additional information" provides interesting information about how the specification may be extended in the future. I have another suggestion for future extensions of this specification: if the identified resource is a file, a checksum could be added in the end of the PWID. Then it would be possible to indicate that two different PWIDs identify the same content (two copies of the  resource harvested from two Web archives) or the content has changed over time; then PWIDs will  be otherwise identical but archival-time and checksum will differ.    

Best regards, 

Juha 

-----Alkuperäinen viesti-----
Lähettäjä: Eld Zierau <[email-masked]> 
Lähetetty: torstai 31. lokakuuta 2019 12.56
Vastaanottaja: 'Dale R. Worley' <[email-masked]>
Kopio: Hakala, Juha E <[email-masked]>; [email-masked]; [email-masked]
Aihe: RE: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)

Thank you Dale

I have generated and attached a text version of the pdf file from the previous mail: 
    draft-pwid-urn-specification-10.txt

I realized that I had generated it with European sized pages which are longer than US sized pages. I have therefore also generated and attached a version with pages fitting to the shorter pages: 
   draft-pwid-urn-specification-10-short-pages.txt

The only difference between the two documents are: the date (in order to distinguish them) and the page numbering in the table of contents

If there are any other issues, please let me know.

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]

-----Original Message-----
From: Dale R. Worley <[email-masked]> 
Sent: Wednesday, October 23, 2019 3:43 AM
To: Eld Zierau <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)

Eld Zierau <[email-masked]> writes:
> It is in a PDF, - please say if you want another format.

Please remember that IETF processes generally work with text documents.
Certainly if they need detailed comment, it's much easier to interline comments with a text original.

Though I don't have any comments on version 10.  I think it answers all of the concerns I had with previous versions.

Dale

---

From: Eld Zierau <[email-masked]>
Date: Thu, 14 Nov 2019 15:54:50 +0000

Thank you so much!

I have attached a version 1 with the following smaller changes:
 - file name in header corrected to: pwid-urn-specification-1
 - date in template set to 14th of November
 - adding the checksum suggestion in section "Additional information" under explanation of how the specification may be extended in the future

Best regards, Eld

-----
Eld Zierau

-----Original Message-----
From: Hakala, Juha E <[email-masked]> 
Sent: Thursday, November 14, 2019 1:55 PM
To: Eld Zierau <[email-masked]>; 'Dale R. Worley' <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: VS: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)

Hello Eld, 

Best regards, 

Juha 

-----Alkuperäinen viesti-----
Lähettäjä: Eld Zierau <[email-masked]> 
Lähetetty: torstai 31. lokakuuta 2019 12.56
Vastaanottaja: 'Dale R. Worley' <[email-masked]>
Kopio: Hakala, Juha E <[email-masked]>; [email-masked]; [email-masked]
Aihe: RE: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)

Thank you Dale

Best regards, Eld

-----
Eld Zierau

-----Original Message-----
From: Dale R. Worley <[email-masked]> 
Sent: Wednesday, October 23, 2019 3:43 AM
To: Eld Zierau <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)

Dale

---

From: "Henry S. Thompson" <[email-masked]>
Date: Mon, 25 Nov 2019 22:28:45 +0000

I continue to be confused by various aspects of this proposal.

First confusion (more to follow):

The fourth constituent of a PWID, the *precision-spec*, now has only two
possible values, 'part' and 'page', which appear to be attempting to
distinguish between, respectively,

 1) the representation that is/was retrievable for the archived-uri as
    at the archival-time;

 2) a (Content-type conformant?) rendering of that representation
    (with all other digital objects implicated in that rendering
    (e.g. scripts, stylesheets, icons, graphics, fonts, ..., to say
    nothing of advertisements) being also retrieved from the same
    archive?  As it the same archival-time?).  Let's just say I can't
    imagine any creator of a PWID having any idea of when they are
    supposed to use which, or any consumer of one to have any idea of
    what they are meant to do as a consequence of which is present.

Or is 'page' to be understood as meaning that the PWID as a whole is
meant by its minter to denote the same resource (in the RFC 3986 sense
of the word) that the archived URI denoted at the time of archiving?

The discussion of the use of 'page' in the worked example in the
*Resolution* section seems to support either interpretation.

It would help if a more detailed description of what the successful
resolution of the example PWID, that is

  urn:pwid:archive.org:2016-01-22T10:08:23Z:page:https://www.dr.dk

would look like.  Per RFC3986, this should be a representation of the
resource identified by the example PWID.

And, how would that be different if the example PWID had been

  urn:pwid:archive.org:2016-01-22T10:08:23Z:part:https://www.dr.dk

?

How does this distinction survive a change of media type?  To image/png,
or application/pdf, or audio/ogg?

ht
-- 
       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]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

---

From: Eld Zierau <[email-masked]>
Date: Thu, 28 Nov 2019 14:50:24 +0000

Please see my comments below
Best regards, Eld

PS: I have attached new version with the few changes that I have suggested below 
(and a small correction from "Archived URI or identifier" to "Archived URI" which missed my eye in the last version)

-----Original Message-----
From: Henry S. Thompson <[email-masked]> 
Sent: Monday, November 25, 2019 11:29 PM
To: Eld Zierau <[email-masked]>
Cc: 'Hakala, Juha E' <[email-masked]>; Peter Saint-Andre <[email-masked]>; [email-masked]
Subject: Re: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)

The fourth constituent of a PWID, the *precision-spec*, now has only two possible values, 'part' and 'page', which appear to be attempting to distinguish between, respectively,

> Eld: I guess you mean 'part' here, which in the specification is described as:
> "*  'part'
>          Meaning the single archived file/web part harvested as from the
>          specified URI.  For references to web pages with html code
>          (i.e. pages where there is an option to "View page source"),
>          this will mean the actual file with the html code.  It is
>          relevant to refer to web pages this way, in case it is part of
>          a collection specification or in case it is the html that is of
>          interest (e.g. java scripts or hidden links that are not
>          visible when rendering the web page).
>          For all other types of files, the URI will be for single files
>          to be interpreted a file."
> And I must admit that I do not see anything that can be interpreted as representation in this description, so I cannot follow you point here.
>
> Please also note that introduction say that
>    "The purpose of the PWID URN is also to express a web archive
>    reference as simple as possible and at the same time meet the
>    requirements for sustainability, usability and scope.  Therefore, the
>    PWID URN is focused on having only the minimum required information
>    to make a precise identification of a resource in an arbitrary web
>    archive.  Recent research have shown that this can be obtained by the
>    following information [ResawRef]:
>
>    o  Identification of web archive
>
>    o  Identification of source:
>       *  Archived URI
>       *  Archival timestamp
>
>    o  Intended precision (page, part/file)"
>
> I could of course make it sharper by saying that 
>       *  Archival timestamp (the archives timestamp for when the URI was archived)
> But I must admit that I do not see it add value, and it is described several places throughout the specification
> (and therefore not included in attached version).

> Eld: I guess you mean 'page' here, which in the specification is described as:
>
> "* 'page'
>            Meaning that an application like Wayback calculates a resulting
>            web page based on calculated referenced web parts (display
>            templates, images etc.).  For example, an html page displaying
>            an image will need both the html and the referred image."
>
> The PWID is not concerned with Content-type, - it is only concerned with information created when the resource was archived. 
> It is explained in the assignment section how you can determine whether the precision-spec should be part or page:
>
> "o  precision-spec (part or page):
>       The precision specification specifies how the referred item should
>       be regarded.  A typical PWID URN reference in a paper would be
>       'page', where a tool will be needed to render the web page.
>       Alternatively, the precision-spec can be 'part', which is the most
>       precise reference since it reference a specific file where no
>       additional calculations are needed (e.g. as part of a collection,
>       a specific html file with hidden links or to indicate that a
>       single image is referenced).  In order to see whether a viewed
>       browser page is a computed web page or a single file, browsers
>       have a function "View page source" which is not activated if for
>       single files)."
>
> So it is up to browser software to tell whether it is something that is interpreted as a page. 
>
> And yes a page is "with all other digital objects implicated in that rendering  (e.g. scripts, stylesheets, icons, graphics, fonts ...)", 
> where I have used terms that are less technical "parts (display templates, images etc.)"
>
> And no - not necessarily the same archival time, since each digital object will be harvested individually and therefore usually have different archival times.
> That is why there are calculation involved when a Wayback machine renders a page, since it takes the elements (in the archive) it can
> find with time closest to the archival time for the archived file with the page code.
>
> I can make it more clear by extending the description:
>
>" 'page'
>           Meaning that an application like Wayback calculates a resulting
>           web page based on calculated referenced web parts (display
>           templates, images etc.), which the Wayback machine can find in the 
>           archive.  For example, an html page displaying an image will need 
>           both the archived html file for the page and the archived file with 
>           the referred image. Since the two files are archived individually
>           they will normally have different archival times. In cases where the 
>           archive have several versions of the image (harvested at different times), 
>           it is the Wayback machine that calculates which archived file of the 
>           image that is relevant (the one with archival time closest to the 
>           archived html file)."

Or is 'page' to be understood as meaning that the PWID as a whole is meant by its minter to denote the same resource (in the RFC 3986 sense of the word) that the archived URI denoted at the time of archiving?

> Eld: see above

It would help if a more detailed description of what the successful resolution of the example PWID, that is

would look like.  Per RFC3986, this should be a representation of the resource identified by the example PWID.

?

> Eld: Unfortunately I cannot insert images in the specification, - and it is already described in the resolution section in the paragraph:
>  
>    "The 'page' information is used in verification that the right
>    precision level is reached.  In case the precision-spec had been
>    'part', it would require an extra step selecting "View page source"
>    on the resulting page."
>
> but I can of course make it an example and repeat it under the description of the alternative resolution at:
>
>    "Alternative resolution (automatically or manually) of this URN PWID
>    can be deduced based on the current (2019) knowledge of Internet
>    Archive's open Wayback access web interface, which has the pattern:
>
>       https://web.archive.org/web/<time>/<uri>
>
>    Using this pattern (where only digits from the timestamp is
>    included), it is possible to deduce the online https URI:
>
>       https://web.archive.org/web/20160122100823/https://www.dr.dk"
>
> by adding the following text
>
>   "Following this URL to Internet Archive's Wayback tool will result in the harvested web page including 
>   elements  like images etc. which the Wayback machine calculates based on the referred elements and the 
>   contents  of the archive (usually the elements with closest archival time to the archival time of the web 
>   page). This page corresponds to the PWID with precision specification 'page':
>   If the PWID had specified 'part' instead of 'page' i.e.
>   then the referred element (in this case the page code) will be 
>   found by clicking "View page source", which will show the page code in text form."

How does this distinction survive a change of media type?  To image/png, or application/pdf, or audio/ogg?

> Eld: The PWID is for referencing purposes, it is not concerned with types. The PWID is a reference to something
> that has been harvested from the internet and is supposed to be rendered by a browser, - so this is a concern of 
> the original publisher of the element and the browser software.

ht
-- 
       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]

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.