Subject: [urn] several different proposals for URN syntax to include fragments and queries

From: Keith Moore <[email-masked]>
Date: Mon, 17 Jun 2013 01:03:23 -0400

I've attached a plain text document to this message that outlines 
several different proposals for URN syntax to include fragments and 
queries.   This is a result of brainstorming to see how many different 
ways I could think of to compromise between the different competing 
concerns of which I'm aware.    I like some of these ideas better than 
others, but I don't have a strong favorite at the moment.   Some of them 
are mentioned just for completeness, to make it easier to compare those 
proposals with others that are (IMO) more refined.

(I hope everyone can read this without much difficulty.  I didn't want 
to put it in the message body because I've seen too many cases where 
mail readers screwed things up in presentation and/or reply, nor (for 
various reasons) did I want to publish this as an internet-draft (at 
least not yet).)

What I'm hoping is that this list can be narrowed down into a small 
number of candidates, or at least provide some concrete examples for 
discussion.

Keith

---

From: John C Klensin <[email-masked]>
Date: Mon, 17 Jun 2013 10:14:42 -0400

--On Monday, June 17, 2013 01:03 -0400 Keith Moore
<[email-masked]> wrote:

> I've attached a plain text document to this message that
> outlines several different proposals for URN syntax to include
> fragments and queries.   This is a result of brainstorming to
> see how many different ways I could think of to compromise
> between the different competing concerns of which I'm aware. 
>...

Keith,

I had resolved to stop posting to this list before others
stepped into the conversation or you actually posted an I-D, but
I think something is missing from your criteria/ "conflicting
goals" that deserves comment before things go further.

The first part of your document includes:

> What follows is a list of several distinct proposals for how
> to adapt URN syntax to accommmodate query strings and/or
> fragment IDs.   This list is a result of some personal
> brainstorming about the different ways to do this given some
> conflicting goals, e.g.:
> 
> - Desire to retain the meaning of urn: as 'persistent
> identifier', or   at least to be able to distinguish
> persistent identifiers from those   for which there is no
> assurance of persistence;
> - Desire to enable users to compose a URI consisting of a URN
> and query   strings or fragment ID, for any resource named by
> that URN that accepted a query string or fragment ID
> (respectively), regardless of whether the resulting URI is
> persistent
> - Desire to avoid accidental mislabeling of non-persistent
> identifiers as if they provided assurance of persistence
> - Desire to avoid starting turf wars about exactly what URNs
> can or cannot do (or look like) based on expectations of
> other URIs.
 
> and
> 
> - [maybe] Desire to be able to specify URIs that reference
> URNs in ways such that some semantic other than "get the
> named resource" is specified.

To that list, I would add what I think is the elephant in the
room.  Stated in parallel with your list of goals above, it is:

	- Desire to have a sufficiently straightforward and
	efficient mechanism for documentation, review, approval,
	and registration of new namespaces to encourage those
	who intend to create or use a namespace to go through 
	that process. 

I think I've explained most of the reasons I think that is
important in earlier messages and will try to avoid repeating
myself, but we need to remember that, in a world of voluntary
standards, the IETF lost a certain amount of control over URNs
the day that 2141 was published and the "URN:..." syntax was
officially defined.  Other than education -- specifically
defining good ways to do things and explaining why they should
be adopted-- there is nothing we can do to force people to use
only namespaces and syntax that have our stamp of approval (or
to punish them if they do something that offends us).  

I think figuring out the best approach --and perhaps even more
important, documenting and explaining the reasons for choosing
it-- is very important and that your list makes a significant
contribution to that process.  But I think the choices we make
have to be informed by a clear understanding that, 

	* if what we specify doesn't meet people's perceived
	needs, and 
	
	* we don't succeed in either providing a different and
	at least equally attractive way to meet those needs or
	a really persuasive explanation of why the needs should
	be reconsidered,

the odds are astronomical that they will just do whatever they
like and ignore us with the result of damaging at least
predictability across the URN space(s) and possibly
interoperability across the Internet.

   john

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Jun 2013 10:35:21 -0400

> 	who intend to create or use a namespace to go through

While I don't disagree, for the moment I was just trying to figure out 
which syntax might actually work.  I don't immediately see how your 
concern influences the decision of which syntax to choose ... except 
perhaps that the sooner we make a decision on how to move forward with 
URN syntax that accommodates fragments and/or queries, the more likely 
it is that we can actually define documentation, review, approval, etc. 
procedures that people will pay attention to.

> to punish them if they do something that offends us).

Well, we can define protocols that will work if the syntax is correct 
and URNs are used properly, and are less likely to work if the syntax is 
incorrect or for URNs are used improperly.   But beyond that, not 
much.   Which is part of why it helps a lot if the protocols that we 
define (and specifically the URN syntax conventions that we define) work 
when used in a more-or-less obvious manner.

> interoperability across the Internet.

This is the normal state of affairs.  People are constantly working to 
damage the interoperability of the Internet, at every layer of the 
protocol stack.  What with all of the NATs, traffic shapers, 
interception proxies, firewalls, content filters, split DNS, and several 
other really bad ideas that are now widely deployed, frankly I'm amazed 
that the Internet still works at all.   But I don't think we should 
panic about it.   Let's just try to solve the problems of the part that 
we're working on, as best we can.... and also as quickly as we can, as 
long as we actually are solving the problems rather than just trying to 
get a half-baked non-solution out the door.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Jun 2013 16:28:08 -0400

It's been a few days and I haven't seen any responses to my proposals 
for URN syntax to include fragments or queries.

It would help to have some feedback, even if it's of the form "I hate 
them all", or "I can't tell which ones are better than others", or "I 
have no idea what you're talking about", or "I haven't had time to read 
the proposals".

----------

After a few more days' thought, I think the proposal that I'd prefer 
would be Proposal 3.1 with slight modifications.

- Retain the familiar ?query%20string or #fragmentID syntax for those 
features.   These do not affect resolution (they're removed before 
resolving the base URN) but affect the interpretation of and/or 
presentation of the resource after it is accessed.

- Declare that mURNs containing fragment IDs or query strings are NOT to 
be considered as persistent identifiers unless they include an explicit 
/persistent option flag following the NSS. This seems easier than trying 
to forbid people from using a 'urn:' prefix with non-persistent 
identifiers derived from base URNs.

- Extend the URN syntax to permit options that affect interpretation of 
the name, resolution, default operation when accessed (i.e. "clicked") 
as follows:

    mURN = "urn:" NID ":" NSS *option [ "?" query ] [ "#" fragment ]

    option = "/" option-name [ "=" option-value ]

    ; option-name and option-value are forbidden to contain "/" "=" "?"
    or "#"

- Tweak 2141 syntax to remove "?" and "#" from reserved characters in a 
URN NSS

- Create an IANA registry for option-names.    If namespace-specific 
option names are allowed (not sure whether this is a good idea, I can 
see both pluses and minuses), distinguish them somehow from 
namespace-independent URN option names.   Require at least expert 
review, if not IETF consensus, for new option names.

The reason I prefer this is because I think it's a good compromise 
between well-established URI syntax conventions and the unique 
requirements of URNs, and also because I think it has less potential to 
generate controversy than some of the other proposals (which is not to 
say that I think it will be entirely uncontroversial).

Keith

---

From: Renato Iannella <[email-masked]>
Date: Fri, 21 Jun 2013 12:49:32 +1000

On 21 Jun 2013, at 06:28, Keith Moore <[email-masked]> wrote:

> It would help to have some feedback, even if it's of the form "I hate them all", or "I can't tell which ones are better than others", or "I have no idea what you're talking about", or "I haven't had time to read the proposals".

I have just not been convinced of the need to support fragments/query in URNs.
I think the purpose of the NSS was to allow communities to define their own requirements in this respect.

Cheers...
Renato Iannella
Semantic Identity
http://semanticidentity.com
Mobile: +61 4 1313 2206

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Jun 2013 23:00:59 -0400

On 06/20/2013 10:49 PM, Renato Iannella wrote:
>
> On 21 Jun 2013, at 06:28, Keith Moore <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> have no idea what you're talking about", or "I haven't had time to 
>> read the proposals".
>

Thanks for replying.

Why do you think that this was the purpose of the NSS?   (Is it because 
"?" and "#" are marked as reserved characters in the NSS in RFC 2141?)

Why should the semantics of queries or fragments attached to URNs be 
specific to the namespace?

Why should queries and fragments work differently for resources named by 
URNs than for resources named by URLs?   In other words, if "foo" is a 
fragment of http://example.com/resource.html and urn:example:random 
resolves to http://example.com/resource.html, why should 
http://example.com/resource.html#foo potentially refer to something 
different than urn:example:random#foo?

In case it's not clear,

I think that fragments and queries should be defined by the resource 
(currently) pointed to by the URN, not by the namespace. Namespaces 
should not inherently be associated with specific media types (though 
some will tend to have such an association, it shouldn't be assumed that 
they do).

I think that if a resource that is named by a URN has fragments or 
accepts queries, users should be able to construct mURNs that refer to 
specific fragments or specific queries.   To me that means that a 
fragment should mean the same thing regardless of whether it's being 
accessed via a URN or a URL, and a query from a resource should also 
produce the same result regardless of whether the resource is being 
accessed via a URN or a URL, and that the interpretation of query 
strings and fragments needs to be consistent across all URNs.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Fri, 21 Jun 2013 09:07:40 +0200

> different than urn:example:random#foo?

I agree for fragments. I disagree with query parts. They may look like a 
similar construct, but they are not.

> some will tend to have such an association, it shouldn't be assumed that

No. The semantics of a query part depends on the URI scheme, not on the 
resource being identified.

Of course you could enforce the same semantics for all uses of the "urn" 
scheme -- is this what you intend?

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Fri, 21 Jun 2013 10:51:11 -0400

The discussion's been quite long, and it doesn't make sense for me to
reply to a particular message, so I'm just picking one.  I want to
make a couple of points:

I think we need to be careful not to conflate persistence with
immutability.  In general, URNs are meant to be persistent names for
things, but that doesn't guarantee that the things they're naming
won't change.  It would be bad if they changed fundamentally, of
course, but change that makes sense in the context of the name is what
makes URNs work for the real-world situations we want to use them for.
 To use a somewhat silly example, suppose I had a URN that identifies
my car, "urn:example:thing:leiba:car".  In a day of the Internet of
Things, that would be a perfectly reasonable name, allowing someone to
say "Put a message on Barry's car's dashboard display."  The fact that
I got rid of my Toyota a couple of years ago and got a Subaru doesn't
matter -- that URN now names a *different* car, but it still names
*my* car.

Less silly: we have a URN namespace for Internet drafts, defined in
RFC 2648.  The URN "urn:ietf:id:ietf-urnbis-rfc2141bis-urn-04" names
the recently expired version of the 2141bis document.  But 2648
doesn't say much about how these names work.  In real usage, it's very
likely that we want to be able to name the latest version of the
draft, whatever version that is at the time the name is used:
"urn:ietf:id:ietf-urnbis-rfc2141bis-urn".  Clearly, the content that
that name ultimately gets us to will change over time -- there was a
dramatic change between the -03 and -04 versions -- but the name will
always get us to the current version of that particular document.
Persistent, but not immutable... and we wouldn't want it to be
immutable.

In fact, 2648 says something about that, in "Identifier persistence
considerations":

            Persistence of the URNs of this namespace is independent of
            the mutability of the underlying documents.  A URN once
            assigned will never be reassigned to a different resource;
            the assignment is persistent and immutable.  Immutability of
            RFCs, STDs, FYIs and BCPs is at the discretion of the RFC
            Editor.  They may be composites of one or more RFCs and the
            set of RFCs that includes them may change with time.  It is
            important to note that this mutability of some resources is
            independent of the immutability of URN assignment to a
            resource.

Of course, that means that if we have a URN that names a part of that
document, the content of that section -- or even its existence -- can
change: "For information about functional equivalence in URNs, see
<urn:ietf:id:ietf-urnbis-rfc2141bis-urn#section.8>."  That works for
version -04, but Section 8 was "Security Considerations" in version
-03.  Whether that makes it inadvisable to do this sort of thing or
not will depend upon the sub-namespaces and the way those
sub-namespaces are used.  We might say that it makes sense for RFCs,
where, by policy, the content doesn't change, but not for I-Ds, where
fragments can change *fundamentally* from version to version.

I'll also note that I see a reasonable case for fragments actually
changing what resource the URN winds up resolving to.  Consider this:
"urn:isbn:0-679-40758-8" would name the edition of "Don Quixote" that
I have on my bookshelf.  It's a big book; it has, in one cover,
"Volume 1" (which subdivides into "Book I" through "Book IV") and
"Volume 2" (which has "Book V" and "Book VI").  If fragments were
allowed, it might be reasonable for, say,
"urn:isbn:0-679-40758-8#volume.1" to get me to
"http://example.com/don-quixote/vol1", and for
"urn:isbn:0-679-40758-8:volume.2" to get me to
"http://example.com/don-quixote/vol2".  Similarly,
"urn:isbn:0-679-40758-8#book.iii" might get me to
"http://example.com/don-quixote/vol1#bk3", and
"urn:isbn:0-679-40758-8#book.vi" to
"http://example.com/don-quixote/vol2#bk6".

The critical part here is that what we define has to be useful to the
folks who will actually *use* the URNs in the real world, and I think
that's where John's proposal takes us.  If they don't need fragments
as part of the URNs (or queries, which I find much more problematic as
anything other than something that's passed to the resource), then
we're fine in saying that they're not part of the URNs.  But if they
*do* (because they need to do the sorts of things above, or perhaps
because they need to do something entirely different and I got it all
wrong), then we have to allow them to do what they actually have to do
-- otherwise, we'll have simply defined some architecturally pure
thing that's not actually useful.

Barry

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2013 11:09:55 -0400

> thing that's not actually useful.

I've had a couple of ideas about this:

1. One is that URN resolution of a resource could return a list of 
fragment mappings.  So if you resolved urn:isbn:0-679-40758-8 you might 
get back something that included:

...
"fragments" = { ( "volume.1" = "http://example.com/don-quixote/vol1" ),
                            ( "volume.2" = 
"http://example.com/don-quixote/vol2" ),
                            ( "book.i" = 
"http://example.com/don-quixote/vol1#bk1" ),
                            ( "book.ii" = 
"http://example.com/don-quixote/vol1#bk2" ),
                            ( "book.iii" = 
"http://example.com/don-quixote/vol1#bk3" ),
                            ( "book.iv" = 
"http://example.com/don-quixote/vol1#bk4" ),
                            ( "book.v" = 
"http://example.com/don-quixote/vol2#bk5" ),
                            ( "book.vi" = 
"http://example.com/don-quixote/vol2#bk6" ) }
...

(Note that there's no real reason that, for an electronic copy, it would 
actually be needed to split this work into the equivalent of two 
volumes.   Though maybe you could have such a case for a work that 
required several terabytes of storage.)

2. Another idea is that you might need separate mechanisms to permit 
identifiers to refer to HTML-style fragments, than those used to refer 
to persistent fragments.   For consistency with other URIs that refer to 
HTML-style fragments I'd recommend continuing to use the '#' notation 
for these.   But using the syntax I proposed, you could define a 
/region=xxx option (call it something different than fragment to 
minimize the potential for confusion).   And I'm thinking that all such 
options should be input to any resolution service (so the client 
wouldn't have to know which options applied at which layer), so the 
resolution service would see that the client wanted region "book.iv" and 
could return the right URL (if not the whole list of regions).

In summary, I do see the potential that some fragment-like construct 
that were resolved as part of the URN could be useful.   I just don't 
think it's a good idea to prevent users from addressing individual 
HTML-style fragments of a document in conjunction with URNs.   And I 
think it would be confusing if we repurposed '#' to mean something 
subtly different for URNs than for other URIs.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Jun 2013 19:13:35 -0400

On 06/21/2013 03:07 AM, Julian Reschke wrote:
> No. The semantics of a query part depends on the URI scheme, not on 
> the resource being identified.

That seems like an odd statement to me, because the semantics of 
practically every resource on the web that currently accepts queries are 
controlled entirely by the resource.   Even within the context of a 
single URI scheme (e.g. http), query semantics differ widely from one 
resource to the next.

On the other hand, after surveying the use of query syntax in each of 
the several existing URI schemes, I can see why you might think that.   
Most uses of the query syntax are not really for anything that could be 
considered a query, but rather, just as a way to add options or 
parameters to a URI.   But I have to ascribe that to poor design of 
those URI schemes, or perhaps, to the failure of the URI syntax to 
incorporate a general mechanism for representing options or parameters, 
causing the query syntax to get repurposed in many cases.

I still think that for the case of URNs, it makes more sense to have the 
URI query syntax apply to the resource after it is resolved, and to have 
a separate syntax for parameters to be considered in the resolution process.

> Of course you could enforce the same semantics for all uses of the 
> "urn" scheme -- is this what you intend?

No, and I think it would be extremely difficult to define a single set 
of query semantics that were useful over any wide range of resources, 
whether the names of these resources were minted from a single URI 
scheme or multiple URI schemes.

Also, URNs were never intended to be just another URI scheme.   They 
were always intended to be stable, location-independent names that 
resolved to URLs.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Jun 2013 10:08:17 +0200

> single URI scheme (e.g. http), query semantics differ widely from one

That's because the HTTP URI scheme definition doesn't say; and thus it's 
up to the server implementer to decide.

> causing the query syntax to get repurposed in many cases.

The general URI syntax just defines the structure of the URIs. It's up 
to a scheme definition to decide what to do with this structure.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Jun 2013 06:11:55 -0400

On 06/22/2013 04:08 AM, Julian Reschke wrote:
> That's because the HTTP URI scheme definition doesn't say; and thus 
> it's up to the server implementer to decide.

That the HTTP URI scheme doesn't define the semantics of HTTP queries is 
entirely appropriate, because the variety of services supported by HTTP 
is so broad that it wouldn't make sense to define common query semantics 
across all of them.

Similarly, the variety of services supported by URNs is intended to be 
so broad that it wouldn't make sense to define common query semantics 
across all of them.   This is true even within a single URN namespace.   
Some namespaces might restrict the resources to which they assign names 
so that those resources have common query semantics, but this shouldn't 
be assumed to be true for URN namespaces in general.

So the semantics of a query that is bundled with a URN should be assumed 
by the URN architecture to be determined by the resource named.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Sat, 22 Jun 2013 12:15:58 +0200

> by the URN architecture to be determined by the resource named.

I find this use of terminology very confusing - the query is *part* of 
the name.

Best regards, Julian

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Jun 2013 06:40:35 -0400

Sent from my iPhone

On Jun 22, 2013, at 6:15 AM, Julian Reschke <[email-masked]> wrote:

> I find this use of terminology very confusing - the query is *part* of the name.

I find it confusing to speak of a URN that contains a query, because a URN is supposed to be persistent, and a URN that contains a query is very unlikely to be persistent.  And yet, I recognize that we need the ability to bundle queries with URNs, and that people will think of those queries as being "part of" those URNs. 

Really I suspect that the idea that a query is "part of" any URI is a mistake.   It makes more sense for the named resource to be the engine to which a query is submitted, than for the named resource to be the query result.  But the thinking that the query is part of the URI is too well established to change it.

---

From: Barry Leiba <[email-masked]>
Date: Sat, 22 Jun 2013 09:16:19 -0400

> I find it confusing to speak of a URN that contains a query, because a URN is
> supposed to be persistent, and a URN that contains a query is very unlikely to
> be persistent.

Again, be careful about conflating persistence and immutability.  We
can argue about where the line is, but a URN that names "all books
written by Keith Moore" (or all IoT objects owned by Keith Moore)
could well be a reasonable thing, which meets a meaning of persistence
that makes sense for the domain of use for those URNs.

Consider:
1. All RFCs that have Keith Moore as an author.
2. All RFCs that have an author affiliated with Cisco.
3. All RFCs produced by the MPLS working group.
4. All RFCs that have "MPLS" as a keyword.
5. All RFCs with the word "persistent" in the text.

I think we'd all agree that the last one is a transient query, not a
persistent thing.  On the others, we might have a variety of opinions
(mine is that (1) and (3) could reasonably be given persistent names).

That's why I think this needs to be defined down in the (sub-)namespace specs.

> Really I suspect that the idea that a query is "part of" any URI is a mistake.
> It makes more sense for the named resource to be the engine to which a query
> is submitted, than for the named resource to be the query result.

I mostly agree with this.  The trouble with what I say above is that
if I say that the queries in (1) and (3) above are part of the URNs,
and the queries in the others aren't, then how is anyone looking at
the URN supposed to know that?

And yet I can see value, for research and reference purposes, to have
"a URN" that names "all books written by Barack Obama" (as opposed to
"all books *about* Barack Obama", which, to me, would clearly be a
transient query).

Barry

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Jun 2013 10:49:08 -0400

On 06/22/2013 09:16 AM, Barry Leiba wrote:
> Again, be careful about conflating persistence and immutability.
I don't think I'm conflating the two.   When I say persistent, I am 
reasonably sure that I mean persistent.

>    We
> persistent thing.

Not necessarily.  As long as the meaning associated with the URN remains 
the same, it's persistent.   All of these seem like valid things with 
which to associate a URN.   (And none of these necessarily involve query 
strings within a URN.)

>   On the others, we might have a variety of opinions

I don't see how that follows at all.   The meaning of a query is 
associated with the name of the resource that implements the query, not 
with anything higher than that.

URNs with queries become much less useful (i.e. much less generally 
applicable) if you try to associate query semantics with the 
namespace.   And such a requirement would introduce a rather silly 
practice of having to define a new namespace every time you needed to 
name a new kind of query.

> the URN supposed to know that?

None of the examples you cited above require use of a query string 
within the URN.   A URN can be associated with a query without having to 
contain a query string.   The only reason for a URN to contain a query 
string is if you want to be able to substitute one query string for 
another, or to expose the relationship between the query and the base 
resource (i.e. the query engine) for some other reason.

> "all books *about* Barack Obama", which, to me, would clearly be a

No, "all books about Barack Obama" would not clearly be a transient query.

Again, when we talk about persistence of a URN, we're not talking about 
whether the results are the same from one reference of the URN to the 
next, we're talking about whether the meaning of the URN changes.

The problem with having a URN that contains a query string be persistent 
is that it's hard to nail down, in technical terms, what it means for a 
query to be persistent across all possible query strings.    And to me 
the simplest answer seems to be that while the base URN is expected to 
be persistent, a URN that contains a query string (or for that matter a 
fragment ID) has no assurance of persistence.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Jun 2013 15:20:16 -0400

> the URN supposed to know that?

(I neglected to address this bit in my previous response.)

First, I think it's probably too confusing to say that a query string 
that is bundled with a URN, isn't "part of" a URN.  No matter what we 
say in an RFC, people are going to think of whatever goes between quotes 
in an <A HREF="..."> or <IMG SRC="..."> or any other context in which a 
URI appears, as all being "part of" that URI, and they won't parse URNs 
any differently in that respect.

I'm still not really comfortable with the idea that there will be things 
that begin with 'urn:' that aren't persistent.   But trying to finesse 
that issue by saying that the query or fragment isn't "part of" the URN 
seems much more likely to cause confusion than simply declaring that 
when a URN contains a query string or a fragment, persistence is assured 
only for the "base" URN and not the entire URN.

And if it's "probably" too confusing to say that a query string that's 
bundled with a URN isn't "part of" the URN, it's certainly too confusing 
to say that some queries are "part of" a URN while others are not.

But that's also an illustration of why I think it's important to 
carefully specify the actual behavior of the various roles with respect 
to URNs, rather than hoping that those behaviors will be implied by what 
is or is not "part of" the URN.

Keith

---

From: Julian Reschke <[email-masked]>
Date: Sun, 23 Jun 2013 12:28:01 +0200

> any differently in that respect.

Absolutely!

Best regards, Julian

---

From: Renato Iannella <[email-masked]>
Date: Sun, 23 Jun 2013 21:28:10 +1000

On 21 Jun 2013, at 13:00, Keith Moore <[email-masked]> wrote:

> Why should the semantics of queries or fragments attached to URNs be specific to the namespace?   

Because that was why it was called the namespace-specific-string....it was designed to allow the community to support its own requirements, not force on them any current mechanism for fragment/query or anything else that we _currently_ do - but may not in the future.

Cheers...
Renato Iannella
Semantic Identity

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Jun 2013 10:36:35 -0400

On 06/23/2013 07:28 AM, Renato Iannella wrote:
>
> On 21 Jun 2013, at 13:00, Keith Moore <[email-masked] 
> Because that was why it was called the namespace-specific-string....it 
> was designed to allow the community to support its own requirements, 
> not force on them any current mechanism for fragment/query or anything 
> else that we _currently_ do - but may not in the future.

Yes, but as URNs are currently defined, the NSS cannot contain a query 
or a fragment - precisely because at the time that 2141 was written, we 
didn't know how to make them work.    And I would propose that we extend 
the URN syntax in such a way that the query or fragment is not part of 
the NSS, but instead appears after the NSS.    This wouldn't invalidate 
current URN syntax.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Sun, 23 Jun 2013 16:11:13 -0400

Just out of curiosity and possible clarity, is there a document that shows example of what people are proposing to do with query strings and fragments with URNs?

-MM

Michael Mealling
Co-Founder
Pipefish.com
+1-678-640-6884	@mmealling
Schedule a meeting:  http://meetme.so/michaelmealling

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Jun 2013 16:45:03 -0400

> Just out of curiosity and possible clarity, is there a document that shows example of what people are proposing to do with query strings and fragments with URNs?
I'd be interested in such a document (or maybe several documents, each 
from different parties) also.

Keith

---

From: Juha Hakala <[email-masked]>
Date: Mon, 24 Jun 2013 15:09:42 +0300

Hello,

Our plan here in Finland is to allow the use of fragments to specify 
locations within documents that have been previously identified with URNs.

 From library point of view, identification of a (persistent) resource 
is a non-trivial act, preferably performed by professionals who apply 
well established written rules which are identifier system (that is, 
namespace) specific. For instance, a book which is published in three 
volumes and many parallel forms (for instance, hardback, paperback, PDF) 
receives many ISBNs, as dictated by the ISBN rules. For each form there 
should be one ISBN to cover all three volumes, and then one for each 
volume. Therefore there will be e.g. urn:isbn:foo for the PDF version of 
the volume 3. This ISBN should never be re-assigned to another book or 
later manifestation of the same book, such as volume 3 in EPUB 3 format. 
That book will get a different ISBN; metadata records describing the two 
versions will be linked to one another and to the record describing the 
(immaterial) work.

[I am well aware that some publishers do not use ISBNs correctly. But 
there are also people who jaywalk, and nobody argues that there should 
not be traffic lights for pedestrians because of that.]

It is not feasible to extend the act of formal identifier assignment to 
fragments, such as chapter 1 of volume 3. This would be too time 
consuming, and our existing identifier systems for (digital) 
manifestations such as ISBN for books as a rule do not allow extensions 
for e.g. fragment identification. Also, it is impossible to know in 
advance what kind of fragment identification will be desired by the users.

So, we want to allow our users - that is, all sorts of lay people who 
are not familiar with the principles of how to apply bibliographic 
identifiers - to specify fragments when they need to e.g. make a 
reference to certain location of a book that has previously been 
identified with e.g. urn:isbn. The resulting URI (urn:isbn:foo#bar) will 
be, due to the ISBN application rules, tied to the PDF manifestation of 
the volume 3 of the book, so after a while some digital archaeology will 
be needed to guarantee that the document can be displayed to the user.  
But the URN + fragment combo will be as persistent as the base URN. If 
the book is held in national bibliography collection there will be more 
modern versions of the resource with different URNs; the user will find 
out about them with the help of resource metadata.  Using the same 
identifier for all these versions would be an abomination, given that 
there will be significant differences in look and feel and perhaps also 
in intellectual content between them.

In this model, fragment is not and must not be part of the identifier 
(namespace specific string). It follows that fragment does not identify 
anything, it is only used to indicate a location within the identified 
document. Fragments can be used whenever they are applicable (based on 
RFC 3986). This means, among other things, that fragments can only be 
applied in namespaces which deal with identification of (digital) 
manifestations when locations within these resources can be pinpointed 
with RFC 3986.

And anyone can add fragment to an existing URN any time after the URN 
has been assigned.

Our need to use queries is based on the fact that there are a lot of URN 
resolution services already, and when the applications used by 
libraries, archives, museums etc. multiply, it will be possible to use 
additional services that we can't even imagine now.

I agree with the view that using fragments is easier than using queries 
because fragments are always applied to resources that have already been 
identified (persistently). Any identifier system (URN namespace) which 
can be used to identify resource manifestations such as PDF versions of 
books can benefit from fragment use; being able to use fragments would 
significantly broaden the scope of e.g. the ISBN system. Identifier 
systems which do not identify tangible documents (such as ISSN which 
identifies periodicals and ISTC which identifies textual works) will not 
be able to benefit from fragments since it is a priori impossible to use 
fragments with e.g. urn:istc.

Queries, however, are not namespace dependent. The resolution services 
available will depend on technical infrastructure the URN resolver can 
use. For instance, if somebody uses URN resolver to require resource 
metadata from the National Library of Finland now, we would be able to 
supply just descriptive metadata (author, title, isbn etc.). In 2023 our 
URN resolver should be able to provide also administrative metadata 
(rights information; technical metadata about a text document; 
preservation metadata describing the changes due to the file format 
migration) as well. But in order to supply this information, we need 
digital archive (which contains this metadata) and a mechanism with 
which to pass service related parameters to the resolver, so that the 
query can be passed to the correct target.

National libraries are already building international resolver networks. 
If these service parameters are local, maintaining these networks will 
become difficult. There is a need to agree on services and service 
parameters to avoid plenty of re-invention of wheels.

Some people participating in the discussion have expressed the view that 
an URN + query identifies a different resource than the base URN.  I 
disagree: query is not part of the NSS. From library point of view, the 
identified resource remains the same, only the resource related 
resolution service required changes. Then anyone (a human or an 
application) can add a query to an existing URN any time after the URN 
has been assigned, without any limitations apart from those imposed by 
the resolver and the rest of the technical infrastructure.

There is of course one interesting borderline case here. One of the 
services could (and should) be "migrate this document to file format X 
and deliver it to me". For instance, I may be unable to read OOXML 
documents and therefore want the document in PDF/A. In such a case, 
there is a need to specify migration service (in this particular case, 
migration has to take place in two steps: first to PDF with Office, and 
then to PDF/A with Acrobat for reasons which are obvious to anyone who 
has ever tested this migration). But if the resulting PDF/A file is 
preserved for long term and therefore identified, the act of 
identification will be independent of the user and resolution service 
which migrated the document to the new file format.

Best regards,

Juha

On 23.6.2013 23:11, Michael Mealling wrote:
> _______________________________________________
> urn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/urn

-- 

  Juha Hakala
  Senior advisor

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503)
  FIN-00014 Helsinki University
  tel +358 9 191 44293