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

[Eld Zierau <[e-mail]>]

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 <[e-mail]> 
Sent: Monday, November 25, 2019 11:29 PM
To: Eld Zierau <[e-mail]>
Cc: 'Hakala, Juha E' <[e-mail]>; Peter Saint-Andre <[e-mail]>; [e-mail]
Subject: Re: [urn] new draft 10 - new form (RE: new draft 9 - RE: new urn PWID draft (7) with corrections)

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;

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

 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.

> 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

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

?

> 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':
>        urn:pwid:archive.org:2016-01-22T10:08:23Z:page:https://www.dr.dk
>   If the PWID had specified 'part' instead of 'page' i.e.
>        urn:pwid:archive.org:2016-01-22T10:08:23Z:part:https://www.dr.dk
>   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: [phone], e-mail: [e-mail]
                       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.