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

["Henry S. Thompson" <[e-mail]>]

[resending with a elision of more original text which I didn't directly
respond to -- please ignore the preceding version]

Eld Zierau <[e-mail]> writes:

> Please see my comments below

>> -----Original Message-----
>> From: Henry S. Thompson <[e-mail]> 

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

Yes.

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

The relevant RFCs (3986, 7231, 8141) all use "representation" for the
actual result of a successful retrieval, that is, a message consisting
of a media type and an encoded character sequence interpretable with
respect to that media type.  That's precisely what you are talking about
in defining what you mean by 'part'.

> ...

>>  2) a (Content-type conformant?) rendering of that representation
>>     (with all other digital objects implicated in that rendering
>>     ...

> Eld: I guess you mean 'page' here, which in the specification is described as:
> "* 'page'

Yes.

> ...

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

Precisely.  So it's a matter of rendering, or presentation, as
implemented by a browser, or any application appropriate to interpreting
the retrieved representation.

But, and again according to the relevant specifications, what you _do_
with a representation of a resource is a matter for the recipient of
that resource, which will be different for different users/uses at
different times.  The URI itself has nothing to say about that.

So now I can express more succinctly what I was confused about: the
*precision-spec* doesn't make sense, it's trying to pre-judge what
someone may want to do with a URI.

Insofar as one can state what a PWID identifies, it identifies

   the archival record maintained by the *archive-domain* for the
   representation retrieved at the *archival-time* of the state of the
   resource identified by the *archived-uri*.

So, if we construct a PWID with

   *archive-domain* web.archive.org
   *archived-uri*   https://link.springer.com/article/10.1007/JHEP12(2018)098
   *archival-time*  2019-11-18T06:00:21

it identifies such an archival record at the Internet Archive, whose
current representation can be retrieved via an HTTP GET request for

   https://web.archive.org/web/20191118060021/https://link.springer.com/article/10.1007/JHEP12(2018)098

If that GET request is performed using, say, the curl or wget
command-line tools, you will get what you call the 'part' as a file on
your local 'disk'.

If that GET request is performed using, say, Chrome or Safari, you will
see a presentation of what you call the 'page' on your screen.

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

URIs are not just for browsers!  Surely you don't want to restrict PWIDs
to URIs "that are supposed to be rendered by browsers".  All the talk in
your drafts about browsers and "View Source" is at best misleading, and
at worst suggests that PWIDs are only applicable to a very narrow view
of what archives may contain.

Consider PWIDs constructed from

   *archive-domain* web.archive.org
   *archived-uri*   https://media.springernature.com/w306/springer-static/cover/journal/13130/2018/12.jpg
   *archival-time*  2019-11-18T05:35:49

and

   *archive-domain* web.archive.org
   *archived-uri*   https://link.springer.com/content/pdf/10.1007%2FJHEP12%282018%29098.pdf
   *archival-time*  2019-11-18T06:00:05

which identify other archival records at the Internet Archive, whose
current representations can be retrieved via an HTTP GET request for

   https://web.archive.org/web/20191118053549im_/https://media.springernature.com/w306/springer-static/cover/journal/13130/2018/12.jpg

and

   https://web.archive.org/web/20191118060005/https://link.springer.com/content/pdf/10.1007%2FJHEP12%282018%29098.pdf

Perfectly useful, but the 'page'/'part' distinction doesn't make any
sense here, and 'View Source' is literally unusable.

Your spec would be much shorter, simpler and easier to understand, and
its potential utility much greater, if you removed the *precision-spec*
altogether, and made more use of the descriptive terminology and its
underlying semantics as found in the relevant RFCs mentioned above.

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.