Subject: Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

From: [email-masked]
Date: Fri, 02 May 2014 18:06:42 +0300

Hello,

Quoting John C Klensin <[email-masked]>:

> Hi.
> <snip> ... one very quick observation in response to part of
> Larry's note...
>
> --On Tuesday, 15 April, 2014 16:25 +0000 Larry Masinter
> <[email-masked]> wrote:
>
>> The only thing that makes something a name 'persistsent' is
>> the existence of a name resolution service or method which
>> persists. The syntax or namespace is irrelevant.  'persistent'
>> isn't binary, it's just "how long". Everything has a life-time.
>>
>> http://masinter.blogspot.com/2010/03/ozymandias-uri.html
>
> I think the above largely misses the point and that, in a sense,
> your blog posting illustrates the point although not in the way
> you probably intend.   "Persistent identifier" entered the IETF
> vocabulary a long time ago but may not be very look terminology.
>
> Some objects -- like stone statues if one doesn't care whether
> they remain intact and standing-- have very long life
> expectancies.  Others, like people, have shorter ones.

The library point of view to this is that Shelley's Ozymandias has an  
extremely long life expectancy as a work. It will exist at least as  
long as there is at least one copy left of it, in some physical  
(printed or digital) form. In principle the work itself may survive  
even longer, if 1-n people have memorized it before the last copy  
vanishes (which will inevitably happen).

Persistence of works, their manifestations and identifiers assigned to  
them is primarily an organizational issue. For instance, publications  
will survive a long time because national libraries look after them.  
Some of us are also busy harvesting web pages, using the same  
technologies as the Internet Archive. Likewise archives and museums  
will keep some materials for hundreds of years. This is the community  
which needs persistent identifiers and is already actively using them  
(and understands pretty well how to do it).

Now, in order to identify Ozymandias, the following steps are needed:

1. Give an identifier to the (immaterial) work, and provide metadata  
about the poem.

2. Give identifier to a manifestation of the work. The identifier  
system used can be an ISBN, if Ozymandias is published in a collection  
of Shelley's poems. Once the identifier has been assigned, provide  
metadata about the book. If the resource is not a book, use other  
identifier system such as NBN.

3. If the resource is digital, provide a link (using the existing  
identifier) from the metadata record to the resource. Traditional  
identifiers can be made actionable in the Internet as URNs, but other  
PID systems such as DOI, Handle, ARK et cetera can also be used. As an  
aside, new features which URNbis has built are not in conflict with  
other PIDs; on the contrary, they can use them as well. The only  
slightly problematic case is ARK since it has its own established  
practice for using query.

The essential difference between this PID-driven approach and that of  
some people on this list is that for me, URLs like this

http://www.poemhunter.com/poem/ozymandias/

or even this

http://ozymandias.perm

are not identifiers, first and foremost because their assignment  
process is not managed.

One may argue that sometimes there are no proper identifier system to  
use but this is not true; Handles, DOIs and URNs can be applied to  
anything out there). Second, there is a problem that URLs are not  
persistent, since they are technology dependent. Even if they had the  
same organizational support than the URN-based link supported by the  
national library (which is very unlikely) it may become very difficult  
to support these URLs long before reading the resources requires  
digital archaeology.

Some people on this list have argued that  
http://urn.fi/URN:ISBN:978-952-10-9658-7 or other PID with embedded  
resolver address is no different from e.g. http://ozymandias.perm. But  
in this case the syntactical similarity is deceptive; URN and other  
PIDs must be resolved before the current URL (URLs) of the resource is  
found, so all kinds of interesting stuff can be done in the resolution  
process before the result is passed to HTTP. And once Resolver  
Discovery Service is in place, it will be possible to drop the  
resolver URL from the URN string, and make the difference between URLs  
and URNs more clear.

But URIs
> (with or within including URNs) aren't objects, they are object
> reference that, like most good references, involve some degree
> of abstraction.  Now, "Ozymandias" is a very long-persistent
> reference.  It isn't the object.  It is a somewhat ambiguous
> reference because it can refer to the statue, the poem, your
> blog posting, and probably several other things, but has a long
> duration, perhaps one that is long enough to survive the objects
> it references (just like titles of long-lost books).   But, as a
> reference, it is that persistent because it is not bound to a
> retrieval mechanism that has its own persistence properties.

References to immaterial objects (works and expressions, the latter  
meaning for instance translations of works) are persistent, but they  
do require metadata since otherwise they may be ambiguous. For  
instance, we are talking about Shelley's poem, first published in The  
Examiner, 11 January 1818, along with Hymn to intellectual beauty.  
There is also book by Thomas Monteleone which has the same name.

>
> Whatever its other properties,
> http://masinter.blogspot.com/2010/03/ozymandias-uri.html
> is lousy as a persistent identifier.

URLs really should not be called identifiers. There is a fundamental  
difference between assigning a persistent identifier using a managed  
process (which includes creation of descriptive metadata about the  
resource) and getting a URL to a web page.

One problem I and others have with the concept of URI is that it blurs  
what should be a clear difference between locations and proper  
identifiers. Anyone should be allowed to give the former, but  
identifier assignment for resources that are to be kept for centuries  
is not something anyone is allowed do. Of course even people assigning  
proper identifiers such as ISBNs and ISSNs make mistakes, and there  
are pressures to use these systems in less than optimal manner, but  
that is not the key issue here. What is important is that any digital  
resource that will be preserved for future generations will require a  
persistent identifier. Millions and millions of them - Handles, DOIs,  
URNs, ARKs) have been assigned already by libraries, publishers,  
universities, archives and museums. In order to optimize the tools  
used for generating and resolving URNs and other PIDs, we need some  
new functionalities such as the possibility of using fragments and  
queries.

It depends on the
> availability of "http" (or something called that) as a retrieval
> mechanism.  It depends on there being a DNS, on there being a
> TLD named "com" an SLD named "blogspot", and both of them having
> certain properties of which HTTP can take advantage.

It seems that the extent to which URLs are dependent on underlying  
technologies and the impact this will have on URLs in the long run  
(after, say, a few decades) is not properly understood yet even by  
those communities which must preserve things for extended periods. It  
might be useful to explain where the problems are, and make a  
guesstimate of when each of these issues might emerge.

> "Ozymandias", and even the potential URN
> urn:poems:Shelley/Ozymandias are more persistent because they
> represent a higher level of abstraction and are not tied to
> either a location or a retrieval/access method.  Use of a
> hypothetical ISPN (International Standard Poem Identifier) in
> the form urn:ispn:NNNN-NNNNNN-NNNNNNNNNNNNNNNNNNNN might or
> might not be more persistent: it would be an exact identifier of
> something and makes equivalence comparison more feasible and
> less ambiguous, but it is probably tied to a database to
> actually identify an object and such databases may be more or
> less available and persistent than access methods and/or the DNS
> (which is, after all, just another database).

In practice there will be ISTC (International Standard Text Code)  
assigned to the poem. ISTC can be expressed as URN  
(urn:istc:xxxx-xxxx-xxxx-xxxx). Library databases all over the world  
will have work metadata about the poem (once one library has  
catalogued it, it can be copied to the OPAC of every other library in  
the world). From the work record there will be persistent links to  
manifestation records, which in turn will contain the locations of the  
manifestations - physical shelf locations for printed stuff, and links  
using persistent identifiers to electronic resources. When thousands  
of library OPACs have the same metadata record, it is important to  
have just persistent identifier -based links in them; resolving these  
URNs / Handles / etc. to URLs must be centralized. Then it is not  
necessary to modify every OPAC when URLs change.

Naming / identification has at times been discussed on this list in a  
very abstract level. For most resources that will be preserved for  
long term, things are not that complex. There are guidebooks for using  
ISTCs, ISBNs, ISSNs, NBNs and so on. In those namespaces at least it  
is not necessary to be familiar with Heidegger in order to be able to  
assign identifiers for things. On the other hand, it is these existing  
practices which are in conflict with some of the principles expressed  
in RFC 3986. If fragment were to identify something (instead of just  
pinpointing a location within the identified resource) the new URN  
syntax would not be OK of most identifiers used in libraries and  
publishing sector. The same applies for query.

Juha

>
> Regardless of what one calls them, I suggest that
> access-method-dependent identifiers (http:...,
> NineTrackTape:??42.3744°?N,?71.1169°?W?123456 (where "?"
> represents one or more carefully-chosen delimiters that may not
> have RFC 3986 semantics), ...) are different kinds of creatures
> than either the objects to which they refer or names of those
> objects that are not, in the sense of the above, method or
> location-model dependent.
>
> More soon.
>
>     john
>
>
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 May 2014 13:16:19 -0400

(apps-discuss list dropped)

Juha,

I found this (both the part quoted below and the rest of your
note) very helpful.  Thanks.  One question below...

--On Friday, May 02, 2014 18:06 +0300 [email-masked]
wrote:

>...
> The library point of view to this is that Shelley's Ozymandias
> has an extremely long life expectancy as a work. It will exist
> at least as long as there is at least one copy left of it, in
> some physical (printed or digital) form. In principle the work
> itself may survive even longer, if 1-n people have memorized
> it before the last copy vanishes (which will inevitably
> happen).
>...
> 1. Give an identifier to the (immaterial) work, and provide
> metadata about the poem.
> 
> 2. Give identifier to a manifestation of the work. The
> identifier system used can be an ISBN, if Ozymandias is
> published in a collection of Shelley's poems. Once the
> identifier has been assigned, provide metadata about the book.

I would assume that, if the poem is published as part of a
collection, the collection appears in a book, and the book is
identified with an ISBN, the mechanism for finding the poem
within the book becomes part of a specification about the book
and its identifier.  That is an instruction about the component
of the book, not what I think would normally be considered
"metadata about the book".  And depending on other conventions
or protocols (in the traditional, not computer sense), that
mechanism might be shown as "page 57ff", "Chapter 5", or
something else.   Some introducing (or surrounding) syntax would
be needed for that sort of mechanism description and one would
probably want it to be different from the mechanisms used to
query, or extract information from, the "metadata about the
book".  

While the distinctions are real, the details may be a matter of
convention.  For example, if the book's table of contents were
considered metadata about the book, the poem might also be found
within the book by asking a question of that metadata and then
using the result.

Is that just about right?  If not, where am I confused?

thanks,
    john

---

From: Juha Hakala <[email-masked]>
Date: Fri, 02 May 2014 22:56:23 +0300

Hello,

On 2.5.2014 20:16, John C Klensin wrote:
> and its identifier.
Sort of. I left out some details from my description, but add them here 
because similar techniques are being put into use not only in libraries 
but in other organizations as well.

In our slang, there is a host record describing the book, and component 
part records describing the poem, article, image or any other thing in 
the book. There is a bidirectional link between host and component part 
records. Similar linking techniques are in use when libraries describe 
for instance serials and serial articles and CDs & tracks in them. The 
work level record of a poem, track, article or any other component part 
will be linked directly to the the component part record. Persistent 
identifiers are required in all levels, and there can be several of them 
- for instance, a periodical articles often have embedded images.

These component parts are sometimes components only in logical sense. 
Each track or article may be available as a separate file. But if a file 
contains many component resources, the file syntax may reveal this 
internal structure. For instance, when the National Library of Finland 
digitizes serials we often create structured METS/ALTO XML files where 
encoding shows the logical structure of the issue.
> That is an instruction about the component

METS/ALTO encoding commonly used for digitized textual resources can do 
a lot. Not only can we encode articles, but also chapters, pages, 
paragraphs etc.; it is also possible to describe the font and size of 
each OCR'd character - and provide the probability of the correctness of 
the OCR result for each character.
> within the book by asking a question of that metadata and then
Table of contents (and abstract) is often provided as metadata for 
non-fiction books. So it is possible to find for instance an article 
within a book even if there is no separate metadata record for it. 
Whether it is possible to provide a direct link to such article depends 
on the encoding of the (text) file. Rich encoding takes time, but serves 
the users well.

> Is that just about right?  If not, where am I confused?

I don't think you are  ;-).

  Juha

---

From: "Svensson, Lars" <[email-masked]>
Date: Mon, 5 May 2014 09:57:58 +0000

All,

This discussion has been very helpful to me since it has forced me to reflect on my own views on persistent identification, managed processes, resolution services and other features of urn:s (the lower-case rfc 2141 ones). I have tried to follow the discussion closely as I work for a memory organisation offering urn services, but I cannot deny that I often have had the impression that any attempt to find consensus would be futile and that I often felt that I had completely lost track of in what direction this WG is going. Many thanks to John and Juha for getting the discussion more focused on what features we expect from urn:s. This mail was triggered by the discussion from Friday, May 2nd, 2014 and I use it both to comment and to check if I have understood the arguments correctly.

On May 2nd, 9:56 PM, Juha Hakala wrote:

> records.

Yes, that is the model we envision, although it will take some time before we reach that stage. Traditionally, libraries have only catalogued the physical item at hand, so that there usually would be metadata available about the book (e. g. an anthology of poems by different authors) but not about the individual parts (i. e. individual poems or illustrations). So it might be more correct to rewrite the above statement as (emphasis added):

[[
In our slang, there is a host record describing the book, and there *might be* component part records describing the poem, article, image or any other thing in the book. *In that case*, there is a bidirectional link between host and component part records.
]]

We must keep in mind that cataloguing in libraries is extremely heterogeneous and that often only very coarse data is available. We're getting better, though.

> Similar linking techniques are in use when libraries describe

Yes. And we must be careful when and how we use that as a basis for creating (persistent) identifiers. Do you suggest that we specify in some RFC that we use specific syntaxes (in this case METS/ALTO) to describe the (internal) structure of resource? If yes, I must say that I consider it a mistake a to depend on a certain technology to represent things considering that that technology might be obsolete in 500 years... 

[...]
> on the encoding of the (text) file. Rich encoding takes time, but serves

Perhaps one of the most important questions is how we handle resources that have not reached their ideal state yet...

> Quoting John C Klensin <[email-masked]>:
[skipping Ozymandias]

> resource) and getting a URL to a web page.
[...]
> publishing sector. The same applies for query.

Thanks Juha for mentioning the managed process again. If we require that urn:s (identifers) be assigned according to a formal process, that implies that *all parts* of the string are created according to that process. So if we decide to allow queries and fragment *identifiers* in urn:s, any institution assigning identifiers need to document according to what rules those are created. Is this correct?

And if we say that fragment identifiers are not identifiers (in the above sense), then we should not allow them. This just as a further argument why RFC 3986 FIs are a problem in URNs...

On April 29th, 10:46 PM, John C. Klensin wrote:

> For an http-style URL, the query is addressed to
> the store in which the object is located and may be used to
> select the object, to select within it, etc.  In a two (or more)
> fork environment, queries can, in principle, be addressed to
> information about the object (aka "metadata"), to the selection
> of the object or subsets of it, and so on.  They may specify if
> retrieval is actually wanted and, if so, in which fork.  For
> some types of objects (types presumably identified by NID) there
> may be one fork, two forks, or more forks and actual retrieval
> may be meaningful (or not) for each other them.  In principle,
> one could have an NID (or NID NSS pair) that did not identify an
> object at all but was a pure string for comparison purposes
> (that is allowed by 2141 as I read it).
>
> Because of those combinations, it is desirable to be able to
> identify where a query is intended to be processed and/or what
> sort of query it is on a basis that applies to all urn-method
> URNs and maybe to have abstractions about what happens when
> queries cannot be satisfied that goes somewhat beyond what 3986
> specifies (or allows other things to specify).  Because the
> query model of 3986 is, at least IMO, pretty closely tied to the
> interpretation of queries in http-style URLs, it is hard to make
> those distinctions except, perhaps, by kludge.
> 
> And, if we are really trying to construct identifiers that will
> be useful (or at least accurately interpretable) for centuries,
> even if the presumed associated retrieval methods go away,
> kludges that can be avoided are probably an extra-bad idea.

Until now I had been pretty certain that queries only make sense in the context of resolution services and thus argued that we should disallow them in the urn: syntax and defer them to RFC 2483bis, but the above comment together with Juha's hint that we might in future have urn:- based resolving (without relying on http:) has made me think about that again. One way to stay within the narrow query syntax of 3986 could be to specify a list of keywords (or perhaps better a prefix like "urnrs-" (urn resolution service)) that -- when used in queries -- are *only* to be interpreted by resolvers and MUST be ignored by other processors. Since creating the query part of the urn: is part of the managed process, that should be feasible. (I think Juha has mentioned similar thoughts earlier on this list, but I cannot find the reference right now).

Please let me know if I'm totally off on this.

Best,

Lars

*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationstechnologie
Telefon: +49-69-1525-1752
mailto:[email-masked] 
http://www.dnb.de

---

From: SM <[email-masked]>
Date: Mon, 05 May 2014 15:24:28 -0700

Hi Juha,

[apps-discuss@ removed from the Cc]

>(and understands pretty well how to do it).

[snip]

>resolver URL from the URN string, and make the difference between URLs

There seems to be different groups interested in URNs.  The national 
library group, for example, consider persistence as a matter of 
decades or more.  I don't know whether the other groups (excluding 
people who usually participate in the IETF) share the same view.  I 
agree that the similarity of the syntax is deceptive.

>necessary to modify every OPAC when URLs change.

If I understood correctly the above point is about not being 
dependent upon the technical infrastructure.  I am skipping the 
explanation about "technical infrastructure" as it would take some 
time to discuss about that in this quiet group. :-)

Thanks for the explanations you have provided.  I found them highly 
informative.

Regards,
-sm

---

From: [email-masked]
Date: Tue, 06 May 2014 01:47:01 +0300

Hello Lars,

Some comments below.

Quoting "Svensson, Lars" <[email-masked]>:

> Yes, that is the model we envision, although it will take some time  
> before we reach that stage. Traditionally, libraries have only  
> catalogued the physical item at hand, so that there usually would be  
> metadata available about the book (e. g. an anthology of poems by  
> different authors) but not about the individual parts (i. e.  
> individual poems or illustrations).

For digital resources this policy must change. No manifestation of a  
digital resource (such as PDF version of a doctoral dissertation) will  
ever be persistent in the national library sense of the word. What we  
need is description of the work (which will never change) and linked  
to it, successive versions (manifestations) of the resource, with  
preservation metadata which describes the differences between these  
versions.

So it might be more correct to
> rewrite the above statement as (emphasis added):
>
> [[
> In our slang, there is a host record describing the book, and there  
> *might be* component part records describing the poem, article,  
> image or any other thing in the book. *In that case*, there is a  
> bidirectional link between host and component part records.
> ]]
>
> We must keep in mind that cataloguing in libraries is extremely  
> heterogeneous and that often only very coarse data is available.  
> We're getting better, though.

Yes - we can't manage digital content properly without getting better.  
Of course, most libraries do not have the burden of preserving digital  
resources for long term, but for those libraries that do, there is no  
alternative. And any organization which intends to preserve digital  
resources for long term must have a fairly sophisticated data model to  
support that activity. Persistent identifiers are just a small, but  
essential, part of this.

> Yes. And we must be careful when and how we use that as a basis for  
> creating (persistent) identifiers. Do you suggest that we specify in  
> some RFC that we use specific syntaxes (in this case METS/ALTO) to  
> describe the (internal) structure of resource? If yes, I must say  
> that I consider it a mistake a to depend on a certain technology to  
> represent things considering that that technology might be obsolete  
> in 500 years...

In this particular case I am talking about internal structure of a  
single version / manifestation of the resource and the identifiers  
needed for that. The next manifestation may have the same logical  
components but different encoding and identifiers (only the identifier  
of the work itself never changes). When migration is applied as the  
preservation policy the aim is usually to preserve the intellectual  
content. Trying to preserve the original look and feel is not likely  
to succeed.

> Thanks Juha for mentioning the managed process again. If we require  
> that urn:s (identifers) be assigned according to a formal process,  
> that implies that *all parts* of the string are created according to  
> that process. So if we decide to allow queries and fragment  
> *identifiers* in urn:s, any institution assigning identifiers need  
> to document according to what rules those are created. Is this  
> correct?

According to the current URN syntax I-D specification, fragment and  
query are not part of the namespace specific string and therefore do  
not identify anything. If we change our minds, we would need to decide  
what they actually identify, and try to convince the people who  
maintain traditional identifier systems that extending the scope of  
their identifiers with fragment identification and whatever queries  
can be applied to is OK. I don't believe that that would be easy.

>
> And if we say that fragment identifiers are not identifiers (in the  
> above sense), then we should not allow them. This just as a further  
> argument why RFC 3986 FIs are a problem in URNs...

Well, we do allow the use of URI fragments but for us they just  
indicate a location within the document identified by the namespace  
specific string.

Juha

> Until now I had been pretty certain that queries only make sense in  
> the context of resolution services and thus argued that we should  
> disallow them in the urn: syntax and defer them to RFC 2483bis, but  
> the above comment together with Juha's hint that we might in future  
> have urn:- based resolving (without relying on http:) has made me  
> think about that again. One way to stay within the narrow query  
> syntax of 3986 could be to specify a list of keywords (or perhaps  
> better a prefix like "urnrs-" (urn resolution service)) that -- when  
> used in queries -- are *only* to be interpreted by resolvers and  
> MUST be ignored by other processors. Since creating the query part  
> of the urn: is part of the managed process, that should be feasible.  
> (I think Juha has mentioned similar thoughts earlier on this list,  
> but I cannot find the reference right now).
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 06 May 2014 07:09:44 -0400

--On Monday, 05 May, 2014 15:24 -0700 SM <[email-masked]> wrote:

> There seems to be different groups interested in URNs.  The
> national library group, for example, consider persistence as a
> matter of decades or more.

More like centuries or more.   See below, but I don't think that
is particularly important to category-forming, i.e., not a
useful starting point for a discussion.

>  I don't know whether the other
> groups (excluding people who usually participate in the IETF)
> share the same view.  I agree that the similarity of the
> syntax is deceptive.

I think it is obvious that different groups have different
perceived requirements.  For better or worse and despite a sense
that more education and listening would be helpful, I think the
"my perspective is right and you are wrong" tone of many of the
recent discussions are not leading us toward progress.  

Perhaps a more useful way to look at this is to try to
understand the needs of real communities [1] and then figure out
what we need to have in a URN standard to meet those needs.  My
working hypothesis is that, after trying to do with within the
constraints of 3986 and the compromises people are willing to
make is that it is not possible.  I hope we can do better than
   urn:nid:<stuff>
but maybe, if all we can do is to push NIS and tail syntax to
NID definitions and registrations, that is better than permanent
(sic) paralysis.

  best,
   john

[1] It has been 14 years since RFC 2141 was published.  There
are millions of URNs and many different NIDs out there.  I
suggest that is long enough for us to be able to tell the
difference between real communities with real user populations
and needs and philosophical speculation and that it is time to
start paying more attention to the former as less to the latter.
A lot more.

---

From: SM <[email-masked]>
Date: Tue, 06 May 2014 11:23:41 -0700

Hi John,
>recent discussions are not leading us toward progress.

I agree that the recent discussions are not leading towards progress.

>NID definitions and registrations, that is better than permanent

Factual information would help in understanding the needs of the 
various communities.  I am not sure whether that would lead towards 
progress.  The probability of "we can do better" is very low.

Regards,
-sm

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 8 May 2014 22:45:57 -0400

> From: John C Klensin <[email-masked]>

> Because the query model of 3986 is, at least IMO, pretty closely
> tied to the interpretation of queries in http-style URLs, it is hard
> to make those distinctions except, perhaps, by kludge.

This is one a I don't understand.  As far as I can tell, the
constraint on the semantics of the query-part in RFC 3986 is:

   3.4.  Query

   The query component contains non-hierarchical data that, along with
   data in the path component (Section 3.3), serves to identify a
   resource within the scope of the URI's scheme and naming authority
   (if any).

In regard to the urn-scheme, in which URNs do not have naming
authorities, this seems to establish essentially no limitations.  It
says "identify a resource", but a "resource" could be *anything*.
That is, the meaning of the query-part is entirely up to the NID
registration.  In particular, a particular query-part value can be
defined to mean "fetch the metadata", because the metadata of a
resource can itself be considered a "resource", which is designated by
a URN containing a specific query-part value.  Similar definitions can
be established regarding other "forks" of a resource, and modifiers of
how the query/resolution process is to be executed.

Given that no NID defined the use of query-part, we could write a
single standard for query-parts in the urn-scheme that would apply to
all NIDs.

> It can be accommodated using use "?" syntax of 3986, but only by the
> use of some reserved keywords or other instances of horrible kludges.
> One or two such kludges were proposed to the WG.  I think it is
> accurate to report that they got no traction.

I'm not able to visualize how one could denote the "it" in this
sentence (whose meaning I do not clearly understand) by character
strings in a way in which the syntax of 3986 proves to be excessively
restrictive.  The 3986 syntax is a string from this character set:

   ALPHA / DIGIT
   / "-" / "." / "_" / "~" / "/" / "?" / ":" / "@"
   "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
   and %-escapes

I can't visualize a syntax for identifiers that is significantly more
accommodating -- with the large exception of changing to Unicode as
the underlying character set.  Although Unicode can be represented by
%-escapes, so we can cover even Unicode by having the user interface
translate to/from %-escapes.

Perhaps you know of a proposed modifier syntax (e.g., a way of
specifying a "fork" or specifying modification of the query/resolution
dynamics) that illustrates features that are difficult to implement
within the current syntax of query-part.

Of course, none of this deals with the fact that 2141 does not admit
query-part on urn-scheme URNs.  But solution of any of these problems
will almost certainly require some extension of 2141.

Dale

---

From: [email-masked] (Henry S. Thompson)
Date: Thu, 29 May 2014 18:59:54 +0100

I have a long-standing interest in Web Architecture, having served on
the W3C TAG for 9 years, and have a sort of informal liaison role even
though I left the TAG a few months ago.  I've been following the
thread you started here with interest, and have spent some time
reading the backtrail, and your draft [1].

I find some things that I recognise, and some that I sympathise with,
but a lot that I just don't understand.  This is, I hope, the first of
a number of posts I hope to make asking for help to be sure I
understand both your requirements and your explanations for how having
URNs governed _inter alia_ by 3986 frustrates those requirements.
-------
3986 says some things which seem very much in sympathy with URNBIS:

  1.2.2.  Separating Identification from Interaction [2]

   . . .

   A common misunderstanding of URIs is that they are only used to
   refer to accessible resources.  The URI itself only provides
   identification; access to the resource is neither guaranteed nor
   implied by the presence of a URI.  Instead, any operation
   associated with a URI reference is defined by the protocol element,
   data format attribute, or natural language text in which it
   appears.

   Given a URI, a system may attempt to perform a variety of
   operations on the resource, as might be characterized by words such
   as "access", "update", "replace", or "find attributes".  Such
   operations are defined by the protocols that make use of URIs, not
   by this specification.

  . . .

   Although many URI schemes are named after protocols, this does not
   imply that use of these URIs will result in access to the resource
   via the named protocol.  URIs are often used simply for the sake of
   identification.  Even when a URI is used to retrieve a
   representation of a resource, that access might be through
   gateways, proxies, caches, and name resolution services that are
   independent of the protocol associated with the scheme name.

 3.5 Fragment

   . . .

   As with any URI, use of a fragment identifier component does not
   imply that a retrieval action will take place.  A URI with a
   fragment identifier may be used to refer to the secondary resource
   without any implication that the primary resource is accessible or
   will ever be accessed.

Nonetheless fragment( and query) seem to be at the heart of the
perceived problems of URIs expressed in URNBIS [1]:

  8.  The role URI fragment and query could or should have in
       identification is unclear and the statements in RFC 3986 are
       definitely problematic from the points of view of existing
       identifier systems and management of naming.

   Does fragment identify a location or a certain section of a resource?
   In the evolving set of URN Internet standards, fragment will not be a
   part of the Namespace Specific String.  Then fragment only indicates
   a place / segment within the identified resource, but does not
   identify it.  If fragment had a role in identification, fragments
   would extend the scope of existing standard identifiers to component
   parts of resources.  For instance, anyone could use URN based on ISBN
   + fragment to identify chapters of electronic books.

There is certainly a fundamental tension with pretty fundamental IETF
principles (beyond just what we find in 3986) implied here, if I
understand it correctly.  Media types play a central role in the IETF
architectural vision: given a character string and a media type, I
know how to find out what I can do with the characters.  It doesn't
matter how I got them and their type: from my local disk, via HTTP, in
an email, or by carrier pigeon.  And it doesn't matter what name or
names may have been involved in helping me get access to them.  One of
the things I can do is use whatever fragment identifier syntax and
semantics is provided by the definition of the media type in question
to . . . identify 'fragments'.  And, crucially, those 'fragments'
_need not_ be any locations or sections of the character string or its
interpretation per the media type:

   The identified secondary resource may be some portion or subset of
   the primary resource, some view on representations of the primary
   resource, or _some other resource defined or described by those
   representations_. [emphasis added] [3]

To make this absolute concrete, given a text/html representation and a
fragment identifier "foo", the secondary resource in question is
e.g. a paragraph in the document resource represented by that html, in
particular the paragraph corresponding to the markup including "<a
name='foo'>" in the representation.  Or, given a text/turtle
representation and a fragment "tbl", the secondary resource in
question is e.g. the resource _described_ by the RDF node
corresponding to a line consisting of "<#tbl>" in the representation.
All of that follows straightforwardly from 3986 and the two respective
media type registrations.

3986 is clear that those secondary resources are _identified_ by those
fragment identifiers.  You appear to be proposing that per URNBIS and
2141bis e.g. urn:example:w3cstaff#tbl would _identify_ the same
resource as urn:example:w3cstaff (although it might be defined to
'indicate' something different. . .).

It seems pretty clear to me that this is a divisive and confusing
thing to do.  Let's take the e-book example (I'm using a DOI, because
I happen to remember where to find the resolver for them, but the
point would be the same for any URN->http:URI resolver today):  The
following _both_ identify the main body of an editorial in the journal
_Nature_ of 28 May 2014:

  doi:10.1038/509534a#article
  http://dx.doi.org/10.1038/509534a#article

Am I right that your proposal would change this (assuming a URN
instead of a DOI)?  I.e., that those two things would no longer
identify the same secondary resource, despite both, minus the
'#article', being usable to retrieve the same text/html representation
of the same resource?

Have I misread your document?  If not, could you expand what I guess
must lie behind your desire to move in this apparently divisive
direction, namely

  "If fragment had a role in identification, fragments would extend
   the scope of existing standard identifiers to component parts of
   resources.  For instance, anyone could use URN based on ISBN
   + fragment to identify chapters of electronic books."

I _think_ this is intended to describe a _bad_ outcome from the
perspective of CiMo [4], one which is however understood to be
required by some combination of 3986 and 2141 as they stand, and thus
to amount to an argument why 3986+2141 won't meet your requirements.

Since it looks to me like a _good_ outcome, I'd be very grateful if
you could help me understand why it's bad from the CiMo perspective.

Thanks,

ht

[1] http://tools.ietf.org/html/draft-ietf-urnbis-urns-are-not-uris-00
[2] http://tools.ietf.org/html/rfc3986#section-1.2.2
[3] http://tools.ietf.org/html/rfc3986#section-3.5
[4] http://www.ietf.org/mail-archive/web/urn/current/msg02249.html
-- 
       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]