Subject: [urn] f-component

From: "Svensson, Lars" <[email-masked]>
Date: Wed, 21 Dec 2016 12:01:59 +0000

All,

in version-18, the penultimate paragraph of §2.3.3 says the following about the semantics of the f-component:

[[
The f-component is primarily intended to distinguish the constituent parts of resources named by URNs. Thus, for URNs that resolve to URLs of the named resources, the semantics of an f-component are defined by the media type of those resources, not by the URN namespace.
]]

This leaves out what the semantics of the f-component is if the URN resolver doesn't resolve to a URL but returns the resource (e. g. a document) directly, without redirecting the agent to another location. I propose the following minor edit:

[[
The f-component is primarily intended to distinguish the constituent parts of resources named by URNs. Thus, for URNs that resolve to URLs of the named resources or where the URN resolver returns the resource directly, the semantics of an f-component are defined by the media type of those resources, not by the URN namespace.
]]

Best,

Lars

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationsinfrastruktur
Adickesallee 1
60322 Frankfurt am Main
Telefon: +49 69 1525-1752
Telefax: +49 69 1525-1799
mailto:[email-masked] 
http://www.dnb.de

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 22 Dec 2016 12:17:43 -0700

On 12/21/16 5:01 AM, Svensson, Lars wrote:
> [[ The f-component is primarily intended to distinguish the
> constituent parts of resources named by URNs. Thus, for URNs that
> resolve to URLs of the named resources, the semantics of an
> f-component are defined by the media type of those resources, not by
> the URN namespace. ]]
>
> This leaves out what the semantics of the f-component is if the URN
> resolver doesn't resolve to a URL but returns the resource (e. g. a
> document) directly, without redirecting the agent to another
> location. I propose the following minor edit:
>
> [[ The f-component is primarily intended to distinguish the
> constituent parts of resources named by URNs. Thus, for URNs that
> resolve to URLs of the named resources or where the URN resolver
> returns the resource directly, the semantics of an f-component are
> defined by the media type of those resources, not by the URN
> namespace. ]]

I would like to think about this some more. In particular, I am not sure 
it's right to say that a URN resolver might "return a resource", because 
I believe that it would return (via dereferencing) either a 
representation of the resource or metadata about the resource, and I 
further believe the f-component applies only to representations and not 
to metadata (but I might be wrong about that).

Thus perhaps this is more correct:

    The f-component is primarily intended to distinguish the constituent
    parts of a resource named by a URN.  For a URN that resolves to one
    or more locators which can be dereferenced to a representation, or
    where the URN resolver directly returns a representation of the
    resource, the semantics of an f-component are defined by the media
    type of the representation, not by the URN namespace.

Peter

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 22 Dec 2016 21:51:49 +0000

>    type of the representation, not by the URN namespace.

I haven't compared that to the existing, but it looks true to me.

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]

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 23 Dec 2016 07:01:17 +0000

Hello, 

Comments inline. 

> -----Original Message-----
> From: urn [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
> Sent: 22. joulukuuta 2016 21:18
> To: Svensson, Lars <[email-masked]>; [email-masked]
> Subject: Re: [urn] f-component
> 
> > document) directly, without redirecting the agent to another location.
> > I propose the following minor edit:
> >
> I would like to think about this some more. In particular, I am not sure it's
> right to say that a URN resolver might "return a resource", because I believe
> that it would return (via dereferencing) either a representation of the
> resource or metadata about the resource, and I further believe the f-
> component applies only to representations and not to metadata (but I might
> be wrong about that).

F-component can be applied to the identified resource only, not to metadata about the resource or any other surrogate the resolution process may come up with, such as a list of URLs from which the user may find alternative versions of the resource in different file formats, or one of these alternatives. 

Resolver is not aware of the f-component, so if the resolution process has been set up in such a way that the client may also get a surrogate  instead of the real thing, the client may receive an information resource the f-component cannot be applied to. If so, the client application will behave as usual (leaves the user to the beginning of the resource instead of the desired location). I am not sure if we need to mention this. 

F-components can only be used in those namespaces in which the URNs persistently identify individual information resources such as electronic books, if and when at least some of these resources have applicable media types. So f-component can be used in urn:isbn when the resource is an electronic book in appropriate file format, but it is not applicable in urn:issn. But if the user gets an HTML version of a book instead of PDF, f-component does not work.  
>     type of the representation, not by the URN namespace.

This is fine with me otherwise, but we might want to drop "not by the URN namespace".  

Juha

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 27 Dec 2016 19:49:09 -0500

--On Friday, December 23, 2016 7:01 AM +0000 "Hakala, Juha E"
<[email-masked]> wrote:

>> From: urn [mailto:[email-masked]] On Behalf Of Peter
>> Saint-Andre Sent: 22. joulukuuta 2016 21:18
>> > in version-18, the penultimate paragraph of §2.3.3 says
>> > the following about the semantics of the f-component:
>> > 
>> > constituent parts of resources named by URNs. Thus, for
>> > URNs that resolve to URLs of the named resources, the
>> > semantics of an f-component are defined by the media type
>> > of those resources, not by the URN namespace. ]]
>> > 
>> > This leaves out what the semantics of the f-component is if
>> > the URN resolver doesn't resolve to a URL but returns the
>> > resource (e. g. a document) directly, without redirecting
>> > the agent to another location. I propose the following
>> > minor edit:
>> > 
>> > constituent parts of resources named by URNs. Thus, for
>> > URNs that resolve to URLs of the named resources or where
>> > the URN resolver returns the resource directly, the
>> > semantics of an f-component are defined by the media type
>> > of those resources, not by the URN namespace. ]]
>> 
>> I would like to think about this some more. In particular, I
>> am not sure it's right to say that a URN resolver might
>> "return a resource", because I believe that it would return
>> (via dereferencing) either a representation of the resource
>> or metadata about the resource, and I further believe the f-
>> component applies only to representations and not to metadata
>> (but I might be wrong about that).
> 
> F-component can be applied to the identified resource only,
> not to metadata about the resource or any other surrogate the
> resolution process may come up with, such as a list of URLs
> from which the user may find alternative versions of the
> resource in different file formats, or one of these
> alternatives. 
> 
> Resolver is not aware of the f-component, so if the resolution
> process has been set up in such a way that the client may also
> get a surrogate  instead of the real thing, the client may
> receive an information resource the f-component cannot be
> applied to. If so, the client application will behave as usual
> (leaves the user to the beginning of the resource instead of
> the desired location). I am not sure if we need to mention
> this. 
> 
> F-components can only be used in those namespaces in which the
> URNs persistently identify individual information resources
> such as electronic books, if and when at least some of these
> resources have applicable media types. So f-component can be
> used in urn:isbn when the resource is an electronic book in
> appropriate file format, but it is not applicable in urn:issn.
> But if the user gets an HTML version of a book instead of PDF,
> f-component does not work.  
>> 
>>     The f-component is primarily intended to distinguish the
>>     constituent parts of a resource named by a URN.  For a
>>     URN that resolves to one or more locators which can be
>>     dereferenced to a representation, or where the URN
>>     resolver directly returns a representation of the
>>     resource, the semantics of an f-component are defined by
>>     the media type of the representation, not by the URN
>>     namespace.
> 

Dropped.  3986 is very clear that it is bound to the media type
of the representation and nothing else.  Anything more we say
here risks another argument about 3986 and scope.

BTW, the first sentence of that paragraph is almost identical
(but not quite) and certainly redundant with the first paragraph
of 2.3.3    Suggestions welcome (the default is to just leave
the redundancy).

   john

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 28 Dec 2016 18:33:43 -0700

> here risks another argument about 3986 and scope.

+1

> of 2.3.3    Suggestions welcome (the default is to just leave

I think you and I can work that out as an editorial matter before we 
publish version -19 (I think it would be best to move the above-quoted 
paragraph to the start of Section 2.3.3 and harmonize the first sentences).

Peter