Subject: [urn] Re-examining p-components (and "/", hierarchy, and relative references)

From: John C Klensin <[email-masked]>
Date: Fri, 03 Apr 2015 15:49:47 -0400

ABSTRACT /SUMMARY for this rather long note:

p-components seem to a focus of controversy, possibly blocking
other work and general progress in the WG.  This note tries to
summarize and analyze the controversy, asks if p-components are
important enough that we need to resolve that controversy, and
proposes an alternative if they are not.

Other other circumstances, I might just have written this note
and proposal as an I-D, but it is really just an exploration,
not a proposal.

</ABSTRACT>

Hi.

Several comments in the last couple of weeks have raised issues
with what are called p-components in 2141bis.  Most, but not
all, of those notes have focused particularly on interactions
with hierarchy and relative resolution.

In the interest of getting done, I want to see if the WG can
reexamine p-components rather than trying to dissect 3986 and
its implications in this area.  This note will do some
examination of 3986 interactions, but please bear with me.

Assumption: I am taking the applicability of 3986 syntax but
not semantics (as discussed in Andy's consensus call and
draft-ietf-urnbis-semantics-clarif, although that document is
still open to textual improvements) and the need to expand
allowable URN syntax beyond those of RFC 2141 (and 3046) as
given.  If there is anyone following the URN list who sees the
discussions about hierarchy, relative resolution, or
applicability of their interpretation of 3986 rules (with or
without draft-ietf-appsawg-uri-scheme-reg) as a way to kill
either 2141bis or URNs generally by a death of a thousand cuts,
this note will probably not be helpful to them.

THE ISSUES: 

Those who have spoken up about issues involving p-components
(or the use of "/" in URNs) should check this to be sure I
haven't mischaracterized their positions (and correct me if I
have), but I believe the main concerns, as presented by others
and with which I generally do not agree, are:

(Issue 1): Despite the "no 3986 semantics" rule, we really
cannot have a path or any use of a "/" in any URI, URNs
included, without making that URI hierarchical.  From that
perspective, we can't say "URNs are not hierarchical", which
2141bis-11 does say [1], and allow "/".  Other than relative
resolution issues, it is not clear whether this issue has any
practical impact or is [just] an argument that the "not
hierarchical" paragraph is self-contradictory and should be
rewritten somehow.

(Issue 2): The generic URI parsers [2] will apply relative
resolution processing if a "/" is seen, or perhaps even if it
is not.  So such processing is inevitable, cannot be opted out
of by URNs, and will cause serious damage to URNs if we try.

(Issue 3): Relative resolution is very important to some other
URIs, current and permanent or planned.  If URNs impose
restrictions on relative resolution operatons, even
restrictions that apply only to URNs, it will be damaging to
those other URIs.

(Issue 4): Because URNs are non-hierarchical and relative
resolution would cause problems or meaningless results, URNs
should not allow "/" unless the particular namespace actually
is hierarchical and relative resolution is appropriate.

(Issue 5): It is not possible to decide that a URI scheme does
not support relative resolution.  All URIs have to support such
resolution.  

(Issue 6): Because it is not possible for a scheme to disallow
relative resolution, URNs cannot make support for them a
per-namespace issue either.

PRELIMINARY ANALYSIS:

There are some contradictions in the list above that don't
make it easier to form a complete picture, much less figure out
which arguments are valid or not.  Issues 1, 5, 6, and probably
4 are really about semantics so, unless it really is impossible
to separate the actual syntax restrictions in 3986 from its
semantic ones [3], their relevancy is questionable.

The overall issue appears to be further complicated by an
apparent (but not explicitly written down anywhere that I've
found) principle for URIs, which is that meaningless
constructions are ok.  So, as discussed in earlier notes in the
context of fragments, if a URI is associated with a resource
and a fragment is specified that makes no sense for the
resource, whatever processor is dealing with the URI and/or the
resource is free to just discard it rather than letting it
interfere with other operations.  For the particular case of
"/" and despite the restriction in 2141, nothing prevents
someone from writing "urn:some-NID:some-NSS/garbage" today and
using it in some URI context.  It would presumably be
meaningless and different namespace-specific action routines
would deal with it in different ways, but AFAICT, no one has
shown evidence of horrible damage, whether to generic URI
parsers, the nature of URNs, or otherwise.  Similarly, 3986
makes it quite clear that false negatives are ok and so on.

At ;east for some people, that principle (and the absence of
general damage when it is applied) do not appear to apply where
URNs are involved.  When we tried to propose a note in 2141bis
that would have said, effectively, 

   "Relative resolution as described in RFC 3986 is likely to
   be meaningless for URNs.  Parsers and processors that are
   aware they are dealing with URIs with the
   'urn:' scheme SHOULD NOT attempt to process relative
   references.  However, if that processing is performed,
   perhaps by a generic system that is not aware of particular
   schemes, and results in meaningless results, the relevant
   system should be prepared to just move on."

For the particular case of the "urn:" scheme, we get
repetitions of one or more of the issues about.

I don't know what to do with the other issues, especially
because of the difficulties with claims about generic URI
parsers (see note [2] below).  So let's come back to the
issue.

WHY WOULD WE WANT A p-COMPONENT?

URNs are very much tied up with the principle of "persistence"
(or even "permanence".  Many of us believe we know,
intuititively, what persistence of an identifier means, but we
have been unsuccessful in proposing, much less agreeing on, a
definition that is sufficiently precise to discriminate among
boundary or edge cases [4].  For URNs (perhaps more so than
URIs generally) careful and accurate matching and being clear
about what compnents of the string are considered stable/
persistent has seemed to be especially important.  Neither
f-components (which those who want to think of them as 3986
fragments believe are inherently bound to target objects and
not the URI) and q-components (which, as Keith and others,
including myself, have pointed out, raise questions of
relationship between instructions to the URN processor and
instructions to/about targets) are problematic from both
persistence and comparison purposes.  2141bis has explicitly
excluded both from equality comparisons for just those reasons.

For those namespaces that need additional qualification (beyond
the traditional NSS) that still participates in equality
checking, that has so far left p-components as the only logical
option.  Perhaps there is some other syntax that would do the
job --a hypothetical X-component -- but, so far, no one has
proposed one and the logic of 3986 is such that I think we can
expect any such syntax proposal to produce cries of pain about
generic URI parsers and related topics.

If we have p-components anyway, there are also advantages to
actual or potential namespaces that use the "/" character in
their identifying strings.  Of course, we could simply declare
the separation of NSS from p-components to be an artifact of
3986 semantics and solve the identifying string problem by
allowing the "/" in the NSS, but doing so would not help with
either the "generic URI parser" or relative resolution issue,
nor would it help those who look at a "/" in something that
appears to be a URI and see "hierarchy" (probably in large
letters).

A ROTTEN, BUT POSSIBLY DESIRABLE, CHOICE

The theoretical argument for p-components is above.  I think we
also need to remember that opening 2141 (and at least
implicitly 3406) to allow additinoal syntax has been incredibly
painful and that, after 2141bis is complete and approved,
opening or revising it to allow yet more syntax is likely to be
even more painful.  That may be a good argument for adding
p-components now, even if doing so creates some pain, just to
have it over with.

However, the above theorizing aside, I have not seen any real
demand for p-components on the mailing list.  If there is such
demand, I hope that those who have current needs will come
forward and explain them.  But, if there is not and
p-components are likely to be a source of blocking
controversies, another option would be to modify 2141bis to
reserve the syntax but prohibit registration (and, to the
extent we have the power, use) of URNs containing them until
and unless future documents appear that address the issues.

Because I'm very concerned about the "death of a thousand cuts"
mentioned above, I would hope that the WG would insist that
anyone arguing for getting p-components out of the current
disucssion by pushing them into the future would assure us that
they would not turn around and raise other supposedly-blocking
issues, but I recognize that there is ultimately no way to
prevent that behavior other than by assurance of good faith.

Were we to decide to push p-components aside, the WG should
decide whether it would be desirable to have an informational
appendix or separate informational document that records what
we believe the issues are and why we reached the decisions we
did as a starting point for future work.  This note might be a
good starting point.  Had we had a supplmental document for
2141 that identified the issues and reasons additional syntax
was deferred, it might have saved us a year or three in the
current efforts (and/or had a restrictive impact on 3986).
But, if we translated the controversies about the implications
of p-components into difficulty getting consensus about such an
explanation, perhaps it would just be better to bequeath the
issues to the future.

best,
    john

             -------------------------

NOTES

[1] draft-ietf-urnbis-rfc2141bis-urn-11, Section 5, 
  paragraph 2.

(2] "Generic URI parsers" are problematic in another way that
  should be kept in mind.  They have been invoked frequently in
  these (URN) and other discussions about URIs, but it seems to
  me that, each time someone tries to pin down exactly what
  they do and how libraries compare, the answers are wildly
  different, with some systems that are considered to be such
  parsers by their authors or advocates doing little other than
  separate the scheme name from the rest of the URI, others
  trying very hard to interpret and implement every aspect of
  3986 including its deep semantics (because 3986 includes many
  options, two different good-faith implementations of that
  variety may not behave the same way), and still others
  essentially assuming that every URI behaves like an HTTP URL
  and that everything else is either invalid or deviant.  Some
  tests on web browsers appear to be consistent with the latter
  point of view and are being documented as normative by
  WHATWG.  To the extent to which the later is the actual
  working definition of "generic URI parser", they are never
  going to work well with URNs.

{3} I have heard a few people suggest that it actually is
  impossible, but I haven't seen such comments on the list or
  otherwise in public.  If it is not possible, it seems to me
  that two or three years of list discussion suggests that we
  are faced with a choice between abandoning all ideas of
  extending URNs beyond 2141 and going back to the "URNs are
  not URIs" model.

[4] There have also been some claims that the concept is
  meaningless or impossible in practice, but I'll leave that 
  discussion for other notes.

---

From: Keith Moore <[email-masked]>
Date: Fri, 03 Apr 2015 19:46:54 -0400

On 04/03/2015 03:49 PM, John C Klensin wrote:
> included, without making that URI hierarchical.
mostly concur.

IMO, for any URN whose NSS contains a '/'  that is
(a) assigned to a resource that will never contain any path-relative 
references, AND
(b) will never be used as a Base URI in any other resource named by that 
namespace that contains path-relative references,
it is reasonably safe to ignore the "hierarchy" in that URN.

>   From that

also concur.   (Though all of the hierarchy issues of which I'm aware 
have to do with relative references.)

> of by URNs, and will cause serious damage to URNs if we try.
mostly concur.

An alternative approach might be to construct rules that require things 
that resolve URNs to resources containing path-relative references, to 
do so via an intermediate URL, and/or specify a Base URL in the 
resource, so that all path-relative references are evaluated relative to 
that URL.   But I suspect that it is much more difficult for the 
namespace than to impose a discipline on how its URNs are resolved, than 
to impose a discipline on the resources to which the namespace assigns 
NSSs that contain '/'.

> restrictions that apply only to URNs, it will be damaging to

At the very least, it will result in various inconsistencies in how 
relative references contained within a resource are evaluated, depending 
on whether the resource was accessed via a URN or URL. And it's easy to 
imagine how that inconsistency could become a tussle.  Relative URI 
references are seen as valuable because they continue to work properly 
even when a collection of resources is moved, copied, gets a new domain 
name, etc.   Breaking relative URI references for the sake of not 
permitting hierarchy in URNs seems shortsighted.

> is hierarchical and relative resolution is appropriate.

I would add "...or is inconsequential for the resource so named"  or 
some such (and define what that means).

> not support relative resolution.  All URIs have to support such

concur.

> per-namespace issue either.

concur.   However namespaces MAY impose constraints on NSS assignment 
that make path-relative references a non-issue for them.

> repetitions of one or more of the issues about.

I don't think it's useful or desirable to break, or declare 
"meaningless", all use of path-relative references with all URNs. I 
think there will be a need to assign URNs to documents that contain 
path-relative references while still permitting those documents to be 
accessed via URLs, and those path-relative references need to work 
consistently no matter how the documents are accessed.

> excluded both from equality comparisons for just those reasons.

Aside: as I've implied earlier, I'm not sure that merely excluding those 
components from equivalence comparisons is sufficient to make it clear 
which parts of the URN are persistent and which are not.     But maybe 
that's an uncontroversial change to the text.

Also f- and q-components can also be affected by relative URIs. And 
though this might not impair the affected URNs' persistence, relative 
URIs affecting f- and/or q-components can still result in inconsistent 
behavior depending on how a resource was accessed, and that 
inconsistency can also harm URLs.

> and unless future documents appear that address the issues.

I would prefer it if we can agree on some limitations on namespaces that 
use '/' in NSSs that will render path-relative references either useful 
or "mostly harmless" (depending on the particular discipline chose by 
that namespace).   As I stated above, I think we're going to want to be 
able to use URNs to refer to resources that contain path-relative 
references without breaking those references.   We should certainly be 
able to use URNs to name HTML documents, for instance.

(And I don't want the community to have to wait another 20 years or so 
before trying once again to sort this out.)

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 15 Apr 2015 20:19:16 -0600

> On 04/03/2015 03:49 PM, John C Klensin wrote:

<snip/>

> able to use URNs to name HTML documents, for instance.

Keith, would you mind clarifying that last sentence?

Here's why I ask. To my mind, we should certainly be able to use URNs to 
name documents (if by document we mean a created work, not any 
particular copy of that created work). Such a work might be an 
electronic document that could be constructed using any of a number of 
particular technologies: SGML, XML, HTML, EPUB, MS Word, PDF, markdown, 
TeX, LaTeX, you name it. Although I agree that we should certainly be 
able to use URNs to name electronic documents, I don't see why HTML is 
special here (I'm not saying you think it's special, BTW). Would you 
also agree that we should certainly be able to use URNs to name PDF 
documents or MS Word documents or EPUB documents?

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Apr 2015 09:30:15 -0400

On 04/15/2015 10:19 PM, Peter Saint-Andre - &yet wrote:
> Here's why I ask. To my mind, we should certainly be able to use URNs 
> to name documents (if by document we mean a created work, not any 
> particular technologies: SGML, XML, HTML, EPUB, MS Word, PDF, 
> markdown, TeX, LaTeX, you name it. Although I agree that we should 
> certainly be able to use URNs to name electronic documents, I don't 
> see why HTML is special here (I'm not saying you think it's special, 
> BTW). Would you also agree that we should certainly be able to use 
> URNs to name PDF documents or MS Word documents or EPUB documents?

I absolutely agree that we should be able to use URNs to name any of the 
above kinds of resources.   The reason I cited HTML as an example above 
is because (a) it's presumably familiar to most list readers, and (b) 
HTML is a kind of resource that potentially uses path-relative references.

For example, if there are one or more URNs that refer to a document that 
contains a link to "../../foo", the behavior of that link when the 
document is accessed via any of those URNs should be reasonable, 
well-defined, and namespace-independent.  Ideally, the defined behavior 
of that link should be consistent with the behavior when the same 
document is referred to by a URL that contains a path.

(Though I realize that such links can behave inconsistently even with 
multiple URLs point to such a document   So I suppose the most that can 
be asked is that it be possible for path-relative links in documents to 
/be able to/ work as well when referred to by URNs as they can work when 
referred to by URLs.)

Keith

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 17 Apr 2015 06:10:20 +0000

Hello,

Library community has well established practices for how to use identifiers. URNBIS could use these practices as the starting point, extend them if needed and alter them only when there is a good reason to do so. As a result URNBIS should have a more unified understanding of what kind of functionality needs to be supported now, and what can be postponed for the time being.

There are already international standard identifiers for:

-          Works, which are immaterial entities (such as The Tragicall Historie of Hamlet, Prince of Denmarke)

-          Expressions, which are translations and other versions of these works (such as a Finnish translation of Hamlet or a cartoon version of the original English text)

-          Manifestations, which are physical embodiments of works & expressions. Physical may mean hand-held (printed) or electronic (PDF, EPUB3, etc.).

-          Public identities, which are not the same as persons;  George Orwell is a public identity but the person behind it was Eric Blair. Public identity can also belong to a legal entity (Rolling Stones or IETF) or a figment of author's imagination (such as Winnie the Pooh).

Item (or copy) identifiers are work in progress. ISO TC 46/SC 9 is currently developing International Standard Item Identifier, with which it will be possible to identify particular items, such as the copy of Diophantus' Arithmetica containing some interesting comments by Pierre de Fermat.

The underlying data model which binds all these bibliographic and other entities together is FRBR (http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records). While it is important that we can identify things uniquely and persistently, the real aim is more ambitious: to create linked data. Libraries will - via collective effort, and in cooperation with museums and archives - interconnect related works such as the original Hamlet and Laurence Olivier's 1948 movie (or to be more precise, metadata records describing these works in our catalogues), works and their expressions, works / expressions and their manifestations, and manifestations and their items.

This kind of functionality is not widely available in library systems yet, but there are some systems which provide already a glimpse of what the future will look like. OCLC's WorldCat is my favourite; see for instance the search results for Gone with the wind:

http://www.worldcat.org/search?q=gone+with+the+wind%2C+by+margaret+mitchell&qt=owc_search

In order to provide a solid basis for decentralized creation of linked data we need persistent identifiers from works to items (and metadata formats which enable us to specify the different roles these identifiers will have; in a work metadata record manifestation identifier acts as a link and vice versa). URN qualifiers will not be needed for identification, but it is necessary to use q-component for e.g. enabling the users to request metadata for a work with the q-component. They will then be able to see that there are related works and expressions (and take a closer look at them).  F-component will not be relevant for us, but users will be able to cite documents with them and manifestation identifiers. I can't see any need for the p-component for the time being.

Rich data models such as FRBR are a must in digital archives, since eventually they will contain several manifestations of most archived digital resources, if migration is the preferred preservation method. A user may initially find an outdated version of a document; in such situation it is important to find out that there are more modern versions available (and also that these versions will not have exactly the same look and feel than the original).

The scope of the URN system as a whole cannot be defined meaningfully since each new namespace (and changes in identifier systems which already have a namespace) alters the situation. At the moment URN does not specifically target e.g. public identities, but if a namespace is registered for International Standard Name Identifier, the problem is solved. As far as I am concerned, URNs can be used to identify resources (whatever they are), just like DOI is already being used to identify all sorts of objects (in DOI, it is the identifier itself which is digital, the identified object does not need to be).

Juha

From: urn [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: 16. huhtikuuta 2015 16:30
To: [email-masked]
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)

Here's why I ask. To my mind, we should certainly be able to use URNs to name documents (if by document we mean a created work, not any particular copy of that created work). Such a work might be an electronic document that could be constructed using any of a number of particular technologies: SGML, XML, HTML, EPUB, MS Word, PDF, markdown, TeX, LaTeX, you name it. Although I agree that we should certainly be able to use URNs to name electronic documents, I don't see why HTML is special here (I'm not saying you think it's special, BTW). Would you also agree that we should certainly be able to use URNs to name PDF documents or MS Word documents or EPUB documents?

I absolutely agree that we should be able to use URNs to name any of the above kinds of resources.   The reason I cited HTML as an example above is because (a) it's presumably familiar to most list readers, and (b) HTML is a kind of resource that potentially uses path-relative references.

For example, if there are one or more URNs that refer to a document that contains a link to "../../foo", the behavior of that link when the document is accessed via any of those URNs should be reasonable, well-defined, and namespace-independent.  Ideally, the defined behavior of that link should be consistent with the behavior when the same document is referred to by a URL that contains a path.

(Though I realize that such links can behave inconsistently even with multiple URLs point to such a document   So I suppose the most that can be asked is that it be possible for path-relative links in documents to be able to work as well when referred to by URNs as they can work when referred to by URLs.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Apr 2015 09:28:54 -0400

Juha,

This all sounds marvelous and I look forward to the day when this is in 
place.

My main questions are with how this system of identifiers and 
relationships interfaces to the world of network-accessible resources, 
which may be interactive and/or have their own rich set of internal 
links to one another.

Also, I'm primarily a network protocols person.   So whenever I look at 
something like this I ask myself how it will be implemented in network 
protocols, and whether those protocols will be organized in such a way 
as facilitate the use of those identifiers and relationships, or hinder 
such use.   One way that the network protocols can hinder such use is by 
not permitting URNs to be handled in a uniform way.   So if every 
different URN namespace has different rules for how software needs to 
request resolution (like which components to include), or if q-component 
works differently for different URN namespaces, or relative references 
work differently for different URN namespaces, any of those things could 
hinder use.

Since there are already numerous resources that are referred to using 
URLs and which accept queries, I would like it to be possible to name 
those resources (or at least some of those resources) with URNs without 
losing the ability to send queries to those resources.   So given the 
large amount of mindshare around using ? to introduce queries to those 
resources, to me it makes more sense to use URN q-component for that 
purpose also, and to define a different component to enable requests for 
things like metadata.

Also, I don't like RFC 3986's treatment of URNs at all.  But perhaps 
unfortunately, there's a large amount of mindshare around using not only 
3986 syntax for URNs but also its rules for relative references with 
URNs.   And part of what that means to me is that if we use 3986 syntax 
for URN components that weren't permitted in 2141, it's going to be 
difficult for URNs to avoid being hampered by 3986's rules for relative 
references and by the expectations in the web world for what those 
components mean.

So I think URNBIS needs to strong and technically sound statement about 
how to resolve the conflict between the needs of URNs, and this large 
amount of mindshare.  And URNBIS needs to do so in a way that both 
preserves the ability of the library community to further its goals, and 
also preserves the ability of network-accessible resources to accept 
queries, have relative references, allow identified subsets of the 
results to be referenced, and so forth.   To my understanding, figuring 
out how to resolve this conflict is the primary problem that is 
currently before us.

Keith

On 04/17/2015 02:10 AM, Hakala, Juha E wrote:
>
> Hello,
>
> Library community has well established practices for how to use 
> identifiers. URNBIS could use these practices as the starting point, 
> extend them if needed and alter them only when there is a good reason 
> to do so. As a result URNBIS should have a more unified understanding 
> of what kind of functionality needs to be supported now, and what can 
> be postponed for the time being.
>
> -Works, which are immaterial entities (such as The Tragicall Historie 
> of Hamlet, Prince of Denmarke)
>
> -Expressions, which are translations and other versions of these works 
> (such as a Finnish translation of Hamlet or a cartoon version of the 
> original English text)
>
> -Manifestations, which are physical embodiments of works & 
> expressions. Physical may mean hand-held (printed) or electronic (PDF, 
> EPUB3, etc.).
>
> -Public identities, which are not the same as persons;  George Orwell 
> is a public identity but the person behind it was Eric Blair. Public 
> identity can also belong to a legal entity (Rolling Stones or IETF) or 
> a figment of author’s imagination (such as Winnie the Pooh).
>
> Item (or copy) identifiers are work in progress. ISO TC 46/SC 9 is 
> currently developing International Standard Item Identifier, with 
> which it will be possible to identify particular items, such as the 
> copy of Diophantus’ Arithmetica containing some interesting comments 
> by Pierre de Fermat.
>
> The underlying data model which binds all these bibliographic and 
> other entities together is FRBR 
> (http://en.wikipedia.org/wiki/Functional_Requirements_for_Bibliographic_Records). 
> While it is important that we can identify things uniquely and 
> persistently, the real aim is more ambitious: to create linked data. 
> Libraries will – via collective effort, and in cooperation with 
> museums and archives - interconnect related works such as the original 
> Hamlet and Laurence Olivier’s 1948 movie (or to be more precise, 
> metadata records describing these works in our catalogues), works and 
> their expressions, works / expressions and their manifestations, and 
> manifestations and their items.
>
> This kind of functionality is not widely available in library systems 
> yet, but there are some systems which provide already a glimpse of 
> what the future will look like. OCLC’s WorldCat is my favourite; see 
> for instance the search results for Gone with the wind:
>
> In order to provide a solid basis for decentralized creation of linked 
> data we need persistent identifiers from works to items (and metadata 
> formats which enable us to specify the different roles these 
> identifiers will have; in a work metadata record manifestation 
> identifier acts as a link and vice versa). URN qualifiers will not be 
> needed for identification, but it is necessary to use q-component for 
> e.g. enabling the users to request metadata for a work with the 
> q-component. They will then be able to see that there are related 
> works and expressions (and take a closer look at them).  F-component 
> will not be relevant for us, but users will be able to cite documents 
> with them and manifestation identifiers. I can’t see any need for the 
> p-component for the time being.
>
> Rich data models such as FRBR are a must in digital archives, since 
> eventually they will contain several manifestations of most archived 
> digital resources, if migration is the preferred preservation method. 
> A user may initially find an outdated version of a document; in such 
> situation it is important to find out that there are more modern 
> versions available (and also that these versions will not have exactly 
> the same look and feel than the original).
>
> The scope of the URN system as a whole cannot be defined meaningfully 
> since each new namespace (and changes in identifier systems which 
> already have a namespace) alters the situation. At the moment URN does 
> not specifically target e.g. public identities, but if a namespace is 
> registered for International Standard Name Identifier, the problem is 
> solved. As far as I am concerned, URNs can be used to identify 
> resources (whatever they are), just like DOI is already being used to 
> identify all sorts of objects (in DOI, it is the identifier itself 
> which is digital, the identified object does not need to be).
>
> Juha
>
> *From:*urn [mailto:[email-masked]] *On Behalf Of *Keith Moore
> *Sent:* 16. huhtikuuta 2015 16:30
> *To:* [email-masked]
> *Subject:* Re: [urn] Re-examining p-components (and "/", hierarchy, 
> and relative references)
>
>     Here's why I ask. To my mind, we should certainly be able to use
>     URNs to name documents (if by document we mean a created work, not
>     any particular copy of that created work). Such a work might be an
>     electronic document that could be constructed using any of a
>     number of particular technologies: SGML, XML, HTML, EPUB, MS Word,
>     PDF, markdown, TeX, LaTeX, you name it. Although I agree that we
>     should certainly be able to use URNs to name electronic documents,
>     I don't see why HTML is special here (I'm not saying you think
>     it's special, BTW). Would you also agree that we should certainly
>     be able to use URNs to name PDF documents or MS Word documents or
>     EPUB documents?
>
>
> I absolutely agree that we should be able to use URNs to name any of 
> the above kinds of resources. The reason I cited HTML as an example 
> above is because (a) it's presumably familiar to most list readers, 
> and (b) HTML is a kind of resource that potentially uses path-relative 
> references.
>
> For example, if there are one or more URNs that refer to a document 
> that contains a link to "../../foo", the behavior of that link when 
> the document is accessed via any of those URNs should be reasonable, 
> well-defined, and namespace-independent.  Ideally, the defined 
> behavior of that link should be consistent with the behavior when the 
> same document is referred to by a URL that contains a path.
>
> multiple URLs point to such a document   So I suppose the most that 
> can be asked is that it be possible for path-relative links in 
> documents to /be able to/ work as well when referred to by URNs as 
> they can work when referred to by URLs.)
>
> Keith
>

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Fri, 17 Apr 2015 12:01:23 -0400

I think this is a rational, if hypothetical, reason for p-components, 

> generic URI parsers and related topics.

IMO, that can be achieved by being clear about what the NSS is, assert 
that relative URNs are not expected/permitted, and attest that "/" 
should not be used in a URN simply because one is importing a namespace 
that happens to use them and it's a matter of syntactic convenience not 
to escape them with %-encoding.

Leslie.

-- 

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
[email-masked]
-------------------------------------------------------------------

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Apr 2015 19:36:30 -0400

On 04/17/2015 12:01 PM, Leslie Daigle (ThinkingCat) wrote:
> should not be used in a URN simply because one is importing a 
> namespace that happens to use them and it's a matter of syntactic 
> convenience not to escape them with %-encoding. 

If relative references are never evaluated with respect to URNs, but 
only with respect to URLs that contain paths, I don't think we need to 
constrain p-components of URNs to be paths, or to mandate any 
relationship between the p-components and the resources named (e.g. 
*urn:example://a/b* and *urn:example://a/c* need have no relationship to 
one another), or define what they mean at all.   The only constraints we 
need to impose on them are those dictated by the desire to be 
syntax-compatible with RFC 3986.   A namespace could use p-components 
however it wished, as long as the rules for comparison for the sake of 
determining equivalence weren't broken.

So the only issue I would have with importing a namespace that happens 
to use "/" in the assigned portion of its names would be if the 
resulting syntax violated the 3986 grammar.

So for instance, if a namespace assigned names of the form a/b/c, it 
wouldn't do for it to advertise URNs of the form *urn:namespace:a/b/c* 
.   It would instead have to be *urn:namespace://a/b/c* .

Keith

---

From: "Leslie Daigle (ThinkingCat)" <[email-masked]>
Date: Fri, 17 Apr 2015 20:24:37 -0400

Bear in mind that the text you are quoting was written before today's 
discussion.

I could take a half-step back from it on this side of the interim.

 > .   It would instead have to be *urn:namespace://a/b/c* .

is slim to none.

I (still) believe the document should be clear that using p-components 
requires thought and care.

Leslie.

--

---

From: Keith Moore <[email-masked]>
Date: Fri, 17 Apr 2015 20:26:41 -0400

> > .   It would instead have to be *urn:namespace://a/b/c* .

Should 2141bis explicitly point that out?

> requires thought and care.

Other than conforming to syntax, what thought and care is required?

(I don't inherently disagree with you; I just don't immediately see what 
other concerns remain about p-components if they don't affect how 
relative references are evaluated.)

Keith

---

From: "Hakala, Juha E" <[email-masked]>
Date: Mon, 20 Apr 2015 12:38:41 +0000

Hello Keith,

Libraries etc. are already creating all sorts of links, for instance between metadata records describing different manifestations of resources (like printed and electronic versions of books) and resources and their component parts (like CD and tracks in it). A problem with this is that the identifiers used for this may not be globally unique. If database internal IDs have been used for linking, their usefulness may be limited when the bibliographic data is shared in the Web. Moving from present situation to something that is palatable in Semantic Web may be non-trivial. The sooner we use persistent identifiers in all resource linking, the better.

Dynamic resources (ones which change all the time) are an interesting  challenge. Traditional identifiers do not cope with them too well; granularity is an issue. For instance, ISSN can only be used to identify all versions of an entire web site. And ISBN community would soon run out of numbers if there were a lot of versions of each book. However, new identifier systems such as Handle/DOI and URN:NBN and some other URN namespaces allow - in theory - any level of granularity. In order to identify all versions of a Web page one can use e.g. National Bibliography Numbers based on MD5 or some other check sum. The identifier assignment processes must of course be fully automated; for instance the National Library of Finland has minted tens of millions of URN:NBNs to page images of digitized manuscripts, monographs, journals, newspapers etc.  There are also identifiers for OCR-converted texts - and images within them - to enable so called deep linking.

Regarding resolution and q-components: once we have updated RFC2141 and - I hope - agreed that q-component is allowed, the aim is to update RFC 2483. The new version of that RFC will  specify a mechanism with which the URN users can register new URN resolution services and service parameters. Parameter usage is important for e.g. services like URI to URC, since there are many different things a user may ask for: basic bibliographic description of a resource, its rights related information (what am I entitled to do with this resource), technical metadata (what application can be used to render this resource) or preservation metadata (how does the look and feel of this migrated version of the resource differ from previous versions).

There are definitely cases when URL + query can  be replaced by more persistent URN + query. Instead of making deep (and short-lived) links like this

http://z3950.loc.gov:7090/voyager?version=1.1&operation=searchRetrieve&query=[ISBN]

it would be better to let the URN resolver to map URN:ISBN + query for resource metadata into a URI-based database search. When search protocols and database applications change, URN resolution table of the appropriate URN resolver can be modified so that the URN is mapped to the current search syntax.

Depending on the namespace, for instance URI to URC service may or may not be supported, and even if it is, different metadata formats may be relevant. Library systems will be able to supply MARC 21, archival information systems will support EAD, museum systems LIDO, and all of these systems may be able to deliver Dublin Core records as common denominator. This will require shared (between clients and URN resolvers) understanding on URN query syntax, and "smart" URN resolvers which know how to deal with these resolution requests. Network protocols themselves should not be affected by this.

Namespaces I am familiar will not be able to accommodate p-component. There may be other namespaces which will find it useful.

I don't know how relative references could be used in productive manner in this context.

Juha

From: Keith Moore [mailto:[email-masked]]
Sent: 17. huhtikuuta 2015 16:29
To: Hakala, Juha E; [email-masked]
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)

Juha,

This all sounds marvelous and I look forward to the day when this is in place.

My main questions are with how this system of identifiers and relationships interfaces to the world of network-accessible resources, which may be interactive and/or have their own rich set of internal links to one another.

Also, I'm primarily a network protocols person.   So whenever I look at something like this I ask myself how it will be implemented in network protocols, and whether those protocols will be organized in such a way as facilitate the use of those identifiers and relationships, or hinder such use.   One way that the network protocols can hinder such use is by not permitting URNs to be handled in a uniform way.   So if every different URN namespace has different rules for how software needs to request resolution (like which components to include), or if q-component works differently for different URN namespaces, or relative references work differently for different URN namespaces, any of those things could hinder use.

Since there are already numerous resources that are referred to using URLs and which accept queries, I would like it to be possible to name those resources (or at least some of those resources) with URNs without losing the ability to send queries to those resources.   So given the large amount of mindshare around using ? to introduce queries to those resources, to me it makes more sense to use URN q-component for that purpose also, and to define a different component to enable requests for things like metadata.

Also, I don't like RFC 3986's treatment of URNs at all.  But perhaps unfortunately, there's a large amount of mindshare around using not only 3986 syntax for URNs but also its rules for relative references with URNs.   And part of what that means to me is that if we use 3986 syntax for URN components that weren't permitted in 2141, it's going to be difficult for URNs to avoid being hampered by 3986's rules for relative references and by the expectations in the web world for what those components mean.

So I think URNBIS needs to strong and technically sound statement about how to resolve the conflict between the needs of URNs, and this large amount of mindshare.  And URNBIS needs to do so in a way that both preserves the ability of the library community to further its goals, and also preserves the ability of network-accessible resources to accept queries, have relative references, allow identified subsets of the results to be referenced, and so forth.   To my understanding, figuring out how to resolve this conflict is the primary problem that is currently before us.

Keith

Juha

From: urn [mailto:[email-masked]] On Behalf Of Keith Moore
Sent: 16. huhtikuuta 2015 16:30
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [urn] Re-examining p-components (and "/", hierarchy, and relative references)

Keith