Subject: [urn] Draft Agenda for URNBIS session at IETF 80

From: Andrew Newton <[email-masked]>
Date: Wed, 16 Mar 2011 14:11:38 -0400

This has been uploaded to the datatracker tool, but I'm unsure how
long it will take to be reflected on the IETF meeting page. So here it
is.

-andy

Draft URNBIS Working Agenda for IETF 80

1. Note Well
2. Agenda Bashing
    4 minutes 32.9 seconds
3. Discussion of draft-ietf-urnbis-rfc2141bis-urn-00
    20 minutes
    Andy Newton (tentative)
4. Discussion of draft-ietf-urnbis-rfc3406bis-urn-ns-reg-00
    20 minutes
    Andy Newton (tentative)
5. Discussion of draft-ietf-urnbis-rfc3187bis-isbn-urn-00
    20 mintues
    Juha Hakala
6. Discussion of draft-ietf-urnbis-rfc3188bis-isbn-urn-00
    20 mintues
    Juha Hakala
7. Presentation on URN extension for media content naming
    10 minutes
    Feng Cao
8. Charter Discussion
    Andy Newton
    10 minutes
9. Any Other Business

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Mar 2011 11:31:59 -0600

> Draft URNBIS Working Agenda for IETF 80

I think that should be 3 minutes 14.159 seconds. ;-)

> 3. Discussion of draft-ietf-urnbis-rfc2141bis-urn-00

Based on list discussion, it seems that we could use quite a bit of time
on fragment identifiers. 20 minutes might not be enough...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Andrew Newton <[email-masked]>
Date: Thu, 17 Mar 2011 13:50:03 -0400

On Thu, Mar 17, 2011 at 1:31 PM, Peter Saint-Andre > Based on list
discussion, it seems that we could use quite a bit of time
> on fragment identifiers. 20 minutes might not be enough...

I can increase the time limit as there is play in the agenda.

It would be nice if participants can think of solutions to the
problem. The simple restating of opposing requirements will not lead
to much forward progress.

-andy

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 17 Mar 2011 11:53:48 -0600

> to much forward progress.

I completely agree. So let's keep discussing it on the list here before
the Prague meeting. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Juha Hakala <[email-masked]>
Date: Wed, 23 Mar 2011 16:19:33 +0200

Hello,

> to much forward progress.

I have asked Dutch colleagues in the PersID initiative - who first told 
me that they need fragment identifiers - to specify their use case. 
Marjan Grootveld from DANS wrote the following clarification:

> Persistent Identifiers for fragments
> 
> DANS (Data Archiving and Networked Services, www.dans.knaw.nl) is the Dutch digital archive for research data from the social sciences andhumanities. DANS is also a member of the European PersID initiative concerning the use of URN:NBN for long-term preservation.
> 
> DANS notices a growing demand from researchers to persistently identify fragments of larger units. Two examples from research projects may illustrate this.
> 
> DANS collaborates with the Veteran Institute (NL) and the Radboud University (NL) on providing permanent access to interviews with Dutch veteran military staff who have carried out missions in the last six decades. These audiovisual interviews are being re-used by researchers studying for instance the use of metaphors in the way the interviewees talk about violence, or their mental images of friend and foe. In a so-called EnrichedPublication the researchers illustrate their findings with links to relevant fragments of the interviews. To preserve Enriched Publications for the longterm, not only the underlying publication, but also these fragments need persistent identification.
> 
> Another project will provide digital means to answer the historical research question How do parliamentarians use references to World War II in parliamentary discourse? The University of Amsterdam, NIOD/ Institute for War, Holocaust and Genocide studies (NL) and DANS join forces to find out. The basis for automatic linguistic and statistical analysis is the Dutch Hansard (curated in XML format). The answer to the research question consists of references to specific parts of large documents. Here again, persistent identification fragments is required to properly preserve research outcomes.
> 
> Currently URN:NBN does not provide a way to persistently identify fragments. We ask the committee to change this and extend the standard, because there is a real need for it in the research community.

So, if I have understood the first example correctly, the preference of 
the DANS colleagues is to have a single URN identifying the entire 
interview (in this case, an audiovisual file), but there is a need to 
provide multiple persistent access points to the interview. The 
preferred choice for this is a fragment identifier which encompasses the 
relevant segment of the interview. DANS will see to it that the 
applications facilitating access to this research data will be able to 
resolve these URNs correctly, using the links the researchers embed into 
the data.

I am not entirely sure what the constraints set by the media type are in 
this particular case. But I hope that it is possible to use <fragment> 
in this manner and stay aligned with the RFC 3986.

Without taking a closer look I can not say if the Dutch colleagues 
should utilise the W3C effort (see 
http://www.w3.org/2008/WebVideo/Fragments/) Jean-Pierre Evain mentioned 
in his message to this list. Will check this before the URNBIS WG meeting.

Best regards,

Juha

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

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email [email-masked], tel +358 50 382 7678

---

From: Ted Hardie <[email-masked]>
Date: Wed, 23 Mar 2011 08:05:21 -0700

Hi Juha,

Thanks for providing the use case.  What is not clear (to me, at
least) is why they cannot provide identifiers for structured portions
of larger resources without re-using the fragment identifier syntax.

urn:example-nid:large-resource-id:contained-resource-id

seems to cover this ground; you can even elaborate it to:

urn:example-nid:large-resource-id:container-type:contained-resource-id

No one objects to identifying resources  contained within other
resources, at least  as far as I know.  The problem is the syntax
re-use with the fragment identifier in URIs, which is understood in
relation to the media type, rather than more generally.

regards,

Ted

On Wed, Mar 23, 2011 at 7:19 AM, Juha Hakala <[email-masked]> wrote:
> I have asked Dutch colleagues in the PersID initiative - who first told me
> that they need fragment identifiers - to specify their use case. Marjan
> Grootveld from DANS wrote the following clarification:
>
>> DANS (Data Archiving and Networked Services, www.dans.knaw.nl) is the
>> Dutch digital archive for research data from the social sciences
>> andhumanities. DANS is also a member of the European PersID initiative
>> concerning the use of URN:NBN for long-term preservation.
>>
>> DANS notices a growing demand from researchers to persistently identify
>> fragments of larger units. Two examples from research projects may
>> illustrate this.
>>
>> DANS collaborates with the Veteran Institute (NL) and the Radboud
>> University (NL) on providing permanent access to interviews with Dutch
>> veteran military staff who have carried out missions in the last six
>> decades. These audiovisual interviews are being re-used by researchers
>> studying for instance the use of metaphors in the way the interviewees talk
>> about violence, or their mental images of friend and foe. In a so-called
>> EnrichedPublication the researchers illustrate their findings with links to
>> relevant fragments of the interviews. To preserve Enriched Publications for
>> the longterm, not only the underlying publication, but also these fragments
>> need persistent identification.
>>
>> Another project will provide digital means to answer the historical
>> research question How do parliamentarians use references to World War II in
>> parliamentary discourse? The University of Amsterdam, NIOD/ Institute for
>> War, Holocaust and Genocide studies (NL) and DANS join forces to find out.
>> The basis for automatic linguistic and statistical analysis is the Dutch
>> Hansard (curated in XML format). The answer to the research question
>> consists of references to specific parts of large documents. Here again,
>> persistent identification fragments is required to properly preserve
>> research outcomes.
>>
>> Currently URN:NBN does not provide a way to persistently identify
>> fragments. We ask the committee to change this and extend the standard,
>> because there is a real need for it in the research community.
>
> So, if I have understood the first example correctly, the preference of the
> DANS colleagues is to have a single URN identifying the entire interview (in
> this case, an audiovisual file), but there is a need to provide multiple
> persistent access points to the interview. The preferred choice for this is
> a fragment identifier which encompasses the relevant segment of the
> interview. DANS will see to it that the applications facilitating access to
> this research data will be able to resolve these URNs correctly, using the
> links the researchers embed into the data.
>
> this particular case. But I hope that it is possible to use <fragment> in
> this manner and stay aligned with the RFC 3986.
>
> Without taking a closer look I can not say if the Dutch colleagues should
> utilise the W3C effort (see http://www.w3.org/2008/WebVideo/Fragments/)
> Jean-Pierre Evain mentioned in his message to this list. Will check this
> before the URNBIS WG meeting.
>
> Best regards,
>
> Juha
>
>>
>> -andy

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Mar 2011 20:10:10 -0600

<hat type='individual'/>

> relation to the media type, rather than more generally.

Yes, that seems like a reasonable approach. I'm still not quite sure why
folks think they need to use the fragment identifier syntax here.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Juha Hakala <[email-masked]>
Date: Thu, 24 Mar 2011 08:56:00 +0200

Hello,

> folks think they need to use the fragment identifier syntax here.

I hope Marjan or other Dutch colleagues can explain their situation in 
more details.

Generally, there seems to be at least three approaches:

1. <fragment> is used according to the requirements of URI syntax

2. URNs with no implicit or explicit (URI syntax-based) fragment 
specification are given to component parts of a resource. This is the 
approach chosen by my library when we give identify for instance images 
or chapters within a book using URN:NBN. One (the only?) caveat with 
this is that some standard-based namespaces such as URN:ISBN may not 
allow assignment of identifiers to fragments.

3. URNs with implicit (namespace-based) fragment specification are used. 
The syntax and semantics of this activity should be detailed in the 
namespace registration and based on the identifier standard used. An 
example of this is SICI which identifies e.g. issues and articles in 
journals (see 
http://en.wikipedia.org/wiki/Serial_Item_and_Contribution_Identifier).

SICI is based on ISSN 
(http://en.wikipedia.org/wiki/International_Standard_Serial_Number) but 
but its syntax is a lot more complex since it covers serial "fragments". 
  However, usage of URI syntax <fragment> is not needed and might even 
be counterproductive.

Depending on how the system holding these resources have been built, 
journal articles and issues may or may not be fragments in the URI 
syntax sense of the word. Mapping from URN:SICI to URLs would deal with 
this.

If this approach is acceptable, then RFC2141bis may incorporate 
<fragment> but the RFC should make it clear that a) <fragment> should be 
used only when the media type allows it, b) depending on the URN 
namespace, there may be other approaches for identification of fragments 
which are not limited by the stipulations of the URI syntax.

Best regards,

Juha

-- 

  Juha Hakala

---

From: "Kocer, Kadir Karaca" <[email-masked]>
Date: Thu, 24 Mar 2011 17:59:42 +0100

>folks think they need to use the fragment identifier syntax here.

Hallo Peter,

let me try to explain why German National Library needs fragments.

If you resolve those 4 URNs

urn:nbn:de:gbv:3:1-233295
urn:nbn:de:gbv:3:1-233295-p0005-9
urn:nbn:de:gbv:3:1-233295-p0013-3
urn:nbn:de:gbv:3:1-233295-p0415-6

you will see that the first one represents the digitized book itself as an intellectual work and the other ones take you directly to a specific scanned page.

This is our actual implementation in German National Library and its almost the same logic you suggested
large-resource-id:contained-resource-id (- instead of last : but that is just detail)
You are right. It works so far.

First problem is a management problem:
a) for this single book you need almost 420 URNs!
b) for each URN you have to manage 2 to 4 URLs (archive copies, front pages)
c) some kind you have to manage the relationship "this is a page of book X"
d) each time the copyright owner "reorganizes" his system all 420 URNs must be updated

you may think "So what? It is not a big problem with a good database management system"
But the huge amount makes the difference.

German National Library has about 15.000.000 printed documents itself.
Not to mention its partners and future web harvesting activities.

A big digitization project can not --or better should not-- produce over 100.000.000 URNs just because the fragment identifiers are not standardized and each book needs 420 URNs!

Other problems are more philosophical nature:
each scanned page is there because of the nature of original book. Not because it is an intellectual work itself. Most pages do not mean much without the previous and following pages.
And many more or less similar questions ...

This is why German National Library promotes the idea: URN just for the intellectual entity and fragments for all levels of granularity.

Our example above would turn to:

urn:nbn:de:gbv:3:1-233295
urn:nbn:de:gbv:3:1-233295#p0001
.
.
urn:nbn:de:gbv:3:1-233295#p0013
.
.
urn:nbn:de:gbv:3:1-233295#p0415

- just one URN to manage
- just one URN to update
- just one URN to resolve
   -> resolving of the fragments will be the responsibility of the document owner
- the relationship is clear
   -> no need to manage hierarchies
- virtual intermediate levels can be defined
urn:nbn:de:gbv:3:1-233295#b3c07 (band 3, chapter 7)

This allows also the document repository to organize its document management more flexible.

Hope this helps
Karaca Koçer

---

From: [email-masked]
Date: Thu, 24 Mar 2011 17:22:41 +0000

Thanks Karaca very good explanation, we must take in consideration this good organisation.

Best regards

Maurizio Lunghi

Le mail ti raggiungono ovunque con BlackBerry® from Vodafone!

-----Original Message-----
From: "Kocer, Kadir Karaca" <[email-masked]>
Sender: <[email-masked]>
Date: Thu, 24 Mar 2011 18:00:20 
To: <[email-masked]>
Cc: Marjan Grootveld<[email-masked]>; Ackermann,Uta<[email-masked]>; Kett, Jürgen<[email-masked]>; Altenhoener,Reinhard<[email-masked]>
Subject: Re: [urn] Draft Agenda for URNBIS session at IETF 80

Hallo Peter,

- just one URN to manage
- just one URN to update

Hope this helps
Karaca Koçer

---

From: Ted Hardie <[email-masked]>
Date: Thu, 24 Mar 2011 10:44:01 -0700

Howdy,

Some questions in-line.

> urn:nbn:de:gbv:3:1-233295-p0415-6

Can you describe in more detail what you mean by "resolve" here?  Are
resources being returned, and do those resources have an assigned
media-type?  If so, what is the media-type?

> You are right. It works so far.
I agree that the syntax is irrelevant here; the semantics look the same to me.

> a) for this single book you need almost 420 URNs!

Is the paint point here minting the URNs?

> b) for each URN you have to manage 2 to 4 URLs (archive copies, front pages)

Can you describe why you have to manage multiple URLs here?

> d) each time the copyright owner "reorganizes" his system all 420 URNs must be updated
Obviously you are not re-assigned URNs, but I'm not sure what kind of
update you mean.  Are you talking about updates to the meta-data
associated with the book?  Surely it is a matter of system to design
to determine whether or not identifiers with a specific type (i.e.
contained identifiers within a larger work) have meta-data updates
applied, or simply have a pointer to the base metadata and so inherit
its updates.

> This is why German National Library promotes the idea: URN just for the intellectual entity and fragments for all levels of granularity.

All levels of granularity is actually a big part of the problem.  A
fragment identifier associated with a page number makes sense relative
to a media-type composed of scanned pages.  It makes some sense,
though not as much, to a copy read aloud into an audio file; even
then, the reader must then read the page numbers for it to be useful.
But if you change copies of the book to one set with a different
typeface (as large print books are), the page numbers are no longer
the same.  And if the book is represented in an electronic format that
repaginates when the user shifts the font size, then the page
numbering may change even during a single reading session.

A chapter reference, on the other hand, is useful no matter which copy
of the book is being reference.

On the urn space, what I've tended to assume from that is that
urn:example-nid:containing-resource:container-type:contained-resource
is stable across representations when the container-type is a
structured part of the representation (e.g. chapter).  If the
container-type is not stable across representations, then the
containing resource must be a specific representation of the resource.
 Let's take a specific edition of the Latin Bible as an example: it
has structured sub-containers (Old Testament, New Testatment,
Apocrapha as collections of books, the books therein contained, the
chapters with the books, the verses within the chapters).   If I want
to mint a URN for each specific verse, it is relatively trivial to do,
and it is valid across all representations.

But if I want to mint a URN for page 213, I have to limit myself to a
specific copy of the work.

When there is a digital representation, what that has tended to mean
is that folks use URLs, with their implication of a retrievable
resource of a specific media type, when they want to refer to specific
representations of a resource.  Fragment identifiers are easy to use
there, because they relate to the media type of the resource.  Note
that the resource doesn't actually have to be retrievable for this to
function--like XML namespaces, the URLs can be notional.

To return to the question above, a lot will end up depending on what
you mean by "resolution".

Thanks again for sharing the details of your use case,

regards,

Ted Hardie

---

From: "Kocer, Kadir Karaca" <[email-masked]>
Date: Fri, 25 Mar 2011 16:00:09 +0100

Hi Ted,

>Can you describe in more detail what you mean by "resolve" here?

Every Persistent Identifier is actually nothing more than a sequence of alphanumeric characters without a defined meaning.
It is the "Resolving" that takes the given identifier and delivers the user something he/she can start with.

Some possible options are listed in RFC
http://tools.ietf.org/html/rfc2483
(which should be updated too IMHO)

I would suggest you go to our Resolver
http://nbn-resolving.org
and try the resolving yourself.

If you give all those 4 URNs above and analyze the Responses, I'm sure you will see my point of view.

Have a nice weekend.
Karaca

---

From: Juha Hakala <[email-masked]>
Date: Mon, 28 Mar 2011 13:47:20 +0300

Hello,

I have a few comments to the agenda.

> 4. Discussion of draft-ietf-urnbis-rfc3406bis-urn-ns-reg-00

Alfred Hoenes will be able to attend the meeting, and I assume that he 
will be able to present both of these I-Ds.

If 40 minutes is all we have (see below), I would allocate 25 minutes to 
2141bis and 15 to 3406bis, since most of the discussion on the list has 
concentrated on the URN syntax. But this is a bit academic; we can be 
somewhat flexible with the timing.

> 6. Discussion of draft-ietf-urnbis-rfc3188bis-isbn-urn-00

The title of the latter presentation should be:

Discussion of draft-ietf-urnbis-rfc3188bis-nbn-urn-00

Not sure if 20 minutes is needed (including the presentation and 
discussion); methinks that 10-15 minutes will be sufficient, so that 
there is more time for those agenda items that are more challenging (or 
to the following topic). From the point of view of the namespace 
registrations, the key thing is to agree on URN syntax; after that it 
will be trivial to add the missing bits to rfcs 3187 and 3188.

Pierre Godefroy (from the ISSN International Centre) might want to say a 
few words about the revision of rfc3044, the namespace registration for 
issn. But AOB may be enough for this for now; as far as I am concerned 
it is up to Pierre to decide.

> 7. Presentation on URN extension for media content naming

10 minutes should be sufficient for this discussion. The issue I will 
bring up is not resolution as such, but resolution services (as defined 
in rfc2483) since there is a gap between what is available and what is 
needed by projects such as PersID, especially in the area of metadata 
exchange. But in IETF 80 the aim is just to introduce the problem, not 
to solve it. The first priority is to complete the chartered tasks.

See you in Prague,

Juha

-- 

  Juha Hakala

---

From: "Pierre GODEFROY" <[email-masked]>
Date: Mon, 28 Mar 2011 12:52:26 +0200

Hello,

Thanks to Juha Hakala for proposing an item on the revision of rfc3044 (URN-ISSN). I do not know if this should/could be a formal point. In any case I would only need 5 minutes to describe the beginning of the process and its challenges; so I guess it could be under AOB, if AOB in itself has sufficient time in itself.

See you all in Prague,

Pierre Godefroy
Project Manager
ISSN International Centre
45 rue de Turbigo
75003 PARIS
FRANCE
+33 1 44 88 22 18

-----Message d'origine-----
De : Juha Hakala [mailto:[email-masked]] 
Envoyé : lundi 28 mars 2011 12:47
À : Andrew Newton
Cc : [email-masked]; Pierre GODEFROY
Objet : Re: [urn] Draft Agenda for URNBIS session at IETF 80

Hello,

See you in Prague,

Juha

-- 

  Juha Hakala