Subject: [urn] URN:META namespace registration request

From: "Hakala, Juha E" <[email-masked]>
Date: Wed, 5 Feb 2020 13:26:04 +0000

Hello all,

please find attached a URN namespace registration request covering identifier systems used for identification of metadata elements (such as Title, Creator, Identifier, etc.) in metadata formats. These identifier systems are cool URIs with one exception - Dublin Core uses PURL.

My colleagues from Dublin Core Metadata Initiative have suggested registration of this namespace. If and when registered, it gives an option for DCMI to replace PURL system (which is "endangered species") with URN. We have also discussed the need for META namespace in the National Library of Finland. We believe that using URNs for identification of metadata elements may improve the quality of MARC and Dublin Core metadata produced in libraries, by enabling us to create more functional and persistent links in their metadata records.

All the best,

Juha

Juha Hakala
Senior advisor
Library Network Services, The National Library of Finland
P.O.Box 15 (Yliopistonkatu 1), 00014 Helsingin yliopisto
email [email-masked]<mailto:[email-masked]>

---

From: "Henry S. Thompson" <[email-masked]>
Date: Wed, 05 Feb 2020 14:27:14 +0000

This looks good to me.

It might be a good idea to include some information about how resolvers
might be found, or even, dare I say it, to solicit a commitment from one
or more meta-resolvers (e.g. n2t.net, identifiers.org) to offer support
for sub-namespaces on request.

Two nits:

  http://urn.fi/urn:meta:marc:bd245
yields
  Unknown URN.

  There are no (concrete) examples of the use of hyphen, it would be
  nice to have one

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 7 Feb 2020 08:40:34 +0000

Hello Henry; all, 

both nits you reported have been fixed in the attached version. http://urn.fi is now http://example.com to make it clear that these URNs are just examples, and hyphen is included in (new) Dublin Core -based examples. 

I have also improved the layout of the examples and added an example on MARC authority format tag 100. 

For each metadata format and cataloguing rule there will be one and only one URN resolver (multiple formats / rules may share the same resolver). This simplifies the task of finding the correct resolver. Initially META URNs will be represented as HTTP URIs with the resolver location, but once DNS (or some other network service used instead of it) knows where the resolvers are located, HTTP URIs can be reduced to technology independent URNs.  

All the best, 

Juha 

-----Alkuperäinen viesti-----
Lähettäjä: Henry S. Thompson <[email-masked]> 
Lähetetty: keskiviikko 5. helmikuuta 2020 16.27
Vastaanottaja: Hakala, Juha E <[email-masked]>
Kopio: [email-masked]; Paul Walk <[email-masked]>; Suominen, Osma I <[email-masked]>; jJohn C Klensin <[email-masked]>; Thomas Baker <[email-masked]>
Aihe: Re: [urn] URN:META namespace registration request

This looks good to me.

It might be a good idea to include some information about how resolvers might be found, or even, dare I say it, to solicit a commitment from one or more meta-resolvers (e.g. n2t.net, identifiers.org) to offer support for sub-namespaces on request.

Two nits:

ht
-- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 650-4587, e-mail: [email-masked]
                       URL: http://www.ltg.ed.ac.uk/~ht/  [mail from me _always_ has a .sig like this -- mail without it is forged spam]

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 07 Feb 2020 23:04:07 -0500

Comments on URN:META registration request, version 1, 2020-02-07

This document seems to be an outline or advocacy proposal for the use
of URNs.  And it seems to be directed entirely to the library
bibliographic community.  As such, it doesn't seem to be designed to
be understandable by the IETF community.  And it isn't organized as a
namespace registration but rather as an exposition or advocacy.  It
really needs to be revised carefully.

Some specific issues are:

The term "metadata" is used without definition.  If I understand
correctly, this is used to mean "metadata in library bibliographic
records", which is a small subset of the information in the world
described as "metadata".  It would help if this was clarified.

The phrase "cool URI" is used a number of times.  Is this a technical
term or some sort of commentary?

"PURL" seems to be a technical reference to a specific system.  It
would help if this was properly footnoted.

"DCMI community" is used without definition.

The ABNF rule for meta-nss has a component nbn-string, which is not
defined.  It appears to be intended to be meta-string (or vice-versa).

There is this text:

    However, URNs should replace "cool" URIs, since using them as
    identifiers for metadata elements is not ideal. There are several
    reasons for this:

    1. It is not possible to provide links to alternative versions
    (e.g. human readable / machine readable) versions of element
    descriptions with one URL.

However, given that "URN" and "URL" are disjoint, and "URL" is a
strict subset of "URI", it's difficult to figure out what this might
mean, as e.g. it seems to imply that "cool URIs" are all URLs, and
that somehow URNs would replace the cool URIs as URLs...

There is this text:

    Rules for lexical equivalence:

    None.

However, defining lexical equivalance is a requirement.  And indeed,
the ABNF is annotated with rules for lexical equivalence, "; The
entire prefix is case insensitive."

There is a long discussion of resolution processes without giving
anywhere near enough information that one could write a resolver
client.  I suspect that the document is implicitly referring to a
style of resolution system that is common in the library bibliographic
world.  But if this document is truly to define resolution for a
namespace, it has to actually define it.

The format-code part of the URN is actually a sub-namespace
identifier, and it references a particular metadata system which is
maintained by a particular maintenance organization.  The text says
"As assigned by the respective format maintenance agency", but that
implies that codes are self-assigned (a recipe for chaos), whereas the
text later explains "New codes are added by the National Library of
Finland on request."

Dale

---

From: "Hakala, Juha E" <[email-masked]>
Date: Fri, 14 Feb 2020 12:47:03 +0000

Hello Dale; all, 

I have been busy all week, and on skiing holiday next week, so I will not be able to respond to your comments and edit the registration request before the last week of February. Sorry! 

As regards terms and definitions, we have not had such section in previous registration requests, but I can of course provide descriptions to novel terms listed below. 

All the best, 

Juha

-----Alkuperäinen viesti-----
Lähettäjä: Dale R. Worley <[email-masked]> 
Lähetetty: lauantai 8. helmikuuta 2020 6.04
Vastaanottaja: Hakala, Juha E <[email-masked]>
Kopio: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Suominen, Osma I <[email-masked]>
Aihe: Re: [urn] URN:META namespace registration request

This document seems to be an outline or advocacy proposal for the use of URNs.  And it seems to be directed entirely to the library bibliographic community.  As such, it doesn't seem to be designed to be understandable by the IETF community.  And it isn't organized as a namespace registration but rather as an exposition or advocacy.  It really needs to be revised carefully.

The term "metadata" is used without definition.  If I understand correctly, this is used to mean "metadata in library bibliographic records", which is a small subset of the information in the world described as "metadata".  It would help if this was clarified.

The phrase "cool URI" is used a number of times.  Is this a technical term or some sort of commentary?

"PURL" seems to be a technical reference to a specific system.  It would help if this was properly footnoted.

The ABNF rule for meta-nss has a component nbn-string, which is not defined.  It appears to be intended to be meta-string (or vice-versa).

There is this text:

However, given that "URN" and "URL" are disjoint, and "URL" is a strict subset of "URI", it's difficult to figure out what this might mean, as e.g. it seems to imply that "cool URIs" are all URLs, and that somehow URNs would replace the cool URIs as URLs...

There is this text:

    None.

However, defining lexical equivalance is a requirement.  And indeed, the ABNF is annotated with rules for lexical equivalence, "; The entire prefix is case insensitive."

There is a long discussion of resolution processes without giving anywhere near enough information that one could write a resolver client.  I suspect that the document is implicitly referring to a style of resolution system that is common in the library bibliographic world.  But if this document is truly to define resolution for a namespace, it has to actually define it.

The format-code part of the URN is actually a sub-namespace identifier, and it references a particular metadata system which is maintained by a particular maintenance organization.  The text says "As assigned by the respective format maintenance agency", but that implies that codes are self-assigned (a recipe for chaos), whereas the text later explains "New codes are added by the National Library of Finland on request."

Dale

---

From: "Hakala, Juha E" <[email-masked]>
Date: Tue, 25 Feb 2020 11:51:46 +0000

Hello Dale, 

please find attached a revised version of the request. I hope takes all your issues into account. I have also tried to provide better explanation of how these URNs can be used, and the context of such usage. 

Some comments below. 

Best regards,  

Juha 

-----Alkuperäinen viesti-----
Lähettäjä: Dale R. Worley <[email-masked]> 
Lähetetty: lauantai 8. helmikuuta 2020 6.04
Vastaanottaja: Hakala, Juha E <[email-masked]>
Kopio: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Suominen, Osma I <[email-masked]>
Aihe: Re: [urn] URN:META namespace registration request

This document seems to be an outline or advocacy proposal for the use of URNs.  And it seems to be directed entirely to the library bibliographic community.  

Juha: no, it is directed to any community or organization which maintains a metadata format. Library community has been using them for over 50 years, but archives, museums and publishers created their own formats in 90's. And many other communities have followed the suite since then. 

Dale: As such, it doesn't seem to be designed to be understandable by the IETF community.  And it isn't organized as a namespace registration but rather as an exposition or advocacy.  It really needs to be revised carefully.

Juha: I have added definition of metadata from ISO 5127. It covers much more than just bibliographic metadata. 

Dale: The phrase "cool URI" is used a number of times.  Is this a technical term or some sort of commentary?

Juha: the term was used in the same way as Tim Berners-Lee used it. But I have replaced cool URI with URI/URL in the attached version. 

Dale: "PURL" seems to be a technical reference to a specific system.  It would help if this was properly footnoted.

Juha: I have added a link to a page describing the PURL system.  

Juha: this term is no longer used in the request, but you can find out about the community from https://www.dublincore.org/themes/community/. 

Dale: The ABNF rule for meta-nss has a component nbn-string, which is not defined.  It appears to be intended to be meta-string (or vice-versa).

Juha: nbn-string was a typo, I corrected it to meta-string. 

Dale: There is this text:

Juha: this section has been heavily edited and should not be a problem anymore. 

There is this text:

    None.

Juha: I added a sentence saying that the case insensitivity of the prefix must be taken into account.  

Dale: There is a long discussion of resolution processes without giving anywhere near enough information that one could write a resolver client.  I suspect that the document is implicitly referring to a style of resolution system that is common in the library bibliographic world.  But if this document is truly to define resolution for a namespace, it has to actually define it.

Juha: the hard part is to create a mapping table in the URN:META resolver, since depending on how the format maintenance agencies have established the current URLs, it may be necessary to create the URN - URLs mappings manually. In most cases there is a logic on how current URLs have been established, so manual work can be minimized. 

There should be no need to develop a dedicated resolver client. Any Web browser will do, as far as I am concerned. URNs will at least eventually be represented as HTTP URIs (with resolver URL included), and the only specific requirement will be support for HTTP language negotiation. 

Dale: The format-code part of the URN is actually a sub-namespace identifier, and it references a particular metadata system which is maintained by a particular maintenance organization.  The text says "As assigned by the respective format maintenance agency", but that implies that codes are self-assigned (a recipe for chaos), whereas the text later explains "New codes are added by the National Library of Finland on request."

Juha: I have corrected the syntax section so that it says " As assigned by the National Library of Finland". Format codes must be centrally managed; otherwise the result is chaos, as you say. 

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 28 Feb 2020 21:48:13 -0500

I've finally put in the time for a proper review of the new version of
the URN:META registration.

Dale

----------------------------------------------------------------------
    The National Library of Finland maintains Finnish translations of
    MARC 21 and Dublin Core metadata formats. Their elements have been
    identified with URLs, which the library would like to replace with
    URNs in order to benefit from URN resolution services.

Should this be part of the "Background" section?

    Background:  

    According to ISO 5127, metadata is data about other data,
    documents or records that describes their content, context,
    structure, data format, provenance and/or rights attached to
    them. Metadata elements and their machine readable codes are
    specified in (cataloguing) formats. Libraries have been using a
    metadata format (MARC) since late 1960s, but since 90's museums,
    archives and many other organizations have joined them.

Does "have joined them" refer to "using a metadata format (MARC)" or
to (presumably) "using metadata formats"?

    As a part of general drive towards open linked data, organizations
    maintaining metadata formats have started to publish these
    specifications in the Web, but often in a form (e.g. a PDF
    document) which is not machine readable.

    Even if element level documentation is accessible via HTTP URIs,
URIs with scheme HTTP are always URLs, so it's better to say "via HTTP URLs".
    there has been no coordination between metadata formats or even
    between translations of the same format on how these URIs have
    been assigned and what information has been made available.

    Dublin Core community users Persistent URLs1 (PURLs) as
    identifiers2. DC metadata element Creator has a Persistent URL

    http://purl.org/dc/terms/creator  

    in the /terms/ namespace, and PURL 

    http://purl.org/dc/terms/1.1/creator

    in the /elements/1.1/ namespace. Different PIDs are necessary
PIDs?
    because term definitions in /terms/ namespace may differ from
    those in /elements/1.1/ namespace.

    NOTE These PURLs identify creator-related metadata elements in the
    Dublin Core format, not the creators themselves. Creators have
    other identifiers, such as ORCiDs and ISNIs, which may be
    expressed as URIs
    (e.g. http://www.isni.org/isni/0000000124292982).

    French translation of DCMI Metadata Terms3 uses the same PURLs,
DCMI?
    but they resolve to English texts. In order to access the French
    version, it is necessary to use URLs. URL for creator in French is
Strictly, you mean "non-PURL URLs", since all PURLs are URLs.
    http://www.yoyodesign.org/doc/dcmi/dcmi-terms/index.html#terms-creator.
Given that there are two different "creator" metadata elements in DC
that are described above, which of those is this URL the French
translation for?
    Translations to e.g. Czech, Japanese and Italian are similar in
    this respect:  they rely also to the PURL of the English version.
It's not clear to me what "in this respect" means -- the
distinguishing feature of the French translation described immediately
above is that it is referenced by a URL that is not a PURL, and yet
this sentence says that the Czech, Japanese, and Italian versions
"rely also to the PURL of the English version".  I suspect you mean
something like:  the *name* of the metadata element is the PURL, but you
fetch the *documentation* for the element in various languages using
various different URLs.  (Which doesn't seem like a bad system to me,
other than that the documentation URLs for different languages seem to
be syntactically unrelated.)

    MARC 21 identifier assignment policy differs from Dublin
    Core. Each translation has its own set of URIs. Library of
    Congress has assigned URL
I assume that the Library of Congress is the maintainer of MARC?  It
might be worth mentioning that here since IETF readers may not know that.

    https://www.loc.gov/marc/bibliographic/bd245.html

    to the description of MARC 21 tag 245 (Title statement). URL of
Presumably you mean "to the English description of ..." here, given the
previous sentences have been discussing multiple languages.
    the Finnish description of this tag is

    https://marc21.kansalliskirjasto.fi/bib/20X-24X.htm#245

    and the Swedish description has URL 

    http://www.kb.se/katalogisering/Formathandboken/Bibliografiska-formatet/210-249/#245

    There is a Web page listing all MARC 21 translations4, but URIs
    their elements are not interlinked.

    NOTE Some XML-based metadata formats have XML namespaces: 

    AudioMD: http://www.loc.gov/audioMD/
    MARCXML: http://www.loc.gov/MARC21/slim
    PREMIS: http://www.loc.gov/premis/rdf/v3/
    VideoMD: http://www.loc.gov/videoMD/

    Unfortunately namespaces for AudioMD, MARCXML and VideoMD are not
    resolvable using e.g. HTTP, and functionality supported by the
    PREMIS namespace is insufficient - links to individual tags such
    as

    http://www.loc.gov/premis/rdf/v3/Copyright

    do not provide useful results, since they all take the client only
    to the beginning of the file containing all element
    descriptions. When implemented in this manner links to
    descriptions of metadata elements do not help human and machine
    users of metadata to understand the metadata provided.

    Purpose:

    Provide a uniform basis and a tool for identification of elements
    in metadata formats.

    Functional improvements to the current URL-based identifiers of
    metadata elements.

    Benefits:

    1. Linking to alternative versions (e.g. human readable / machine
    readable) of element descriptions with one URN.

    2. Automatic selection of the appropriate language (see
    below). For instance, a bibliographic record containing a link to
    the URI explaining MARC tag 245 in Finnish is only useful for
    users who understand Finnish, because the HTTP server holding
    these pages cannot redirect Swedish / English speaking users to
    MARC tag 245 pages on other HTTP servers that would be appropriate
    for them.

    3. Having a URN namespace dedicated for metadata elements may
    improve co-ordination on how identifiers for metadata elements are
    created and what they resolve to. It may also encourage the
    organizations maintaining metadata formats to provide
    documentation separately for each metadata element and in a form
    more suitable to the Web than e.g. PDF.

It seems that you are starting the description of a further benefit,
and so want to state "item 4" here and describe it as "A
resolution service for URN:META identifiers can direct users to
information in their preferred languages if the resolution method
communicates their language preferences to the resolver." then
continue with the following example

    If a URN:META identifier is assigned to the Library of Congress
    description of MARC 245 tag5, it is possible to direct a user to
I would say "it is possible for a resolution service to direct ...".
    the descriptions of this tag in other languages6, depending on the
You may want to say "in multiple languages", as "in other languages"
suggests there is a single language which is the unspoken default.
(In practice, I'm sure everyone agrees this unspoken default language
is English, but let's try to be internationalized!)
    language settings of the user's Web client. This functionality can
    be implemented by supporting the HTTP Accept-Language header in
    the URN resolver. A prerequisite for this functionality is that
    all element URLs from translated versions are harvested to the
    resolver's URN -- URL mapping table. Since these URLs should be
    stable, keeping the links up to date is feasible.

    If a network protocol used does not support language negotiation
    the required functionality may also be implemented with the URN
    R-component.

    NOTE A URN should not be assigned if an element already has a
    (well-managed) PID.
PID?
This item probably belongs somewhere else.  It sounds like it's
related to uniqueness properties of the URNs in the namespace.

    Syntax:  

    The Namespace-Specific String (NSS) may consist of two parts:
Only say "may consist" if it could consist of some other set of
parts.  I believe you mean "consists of ..." or even "MUST consist of ...".

       o a prefix consisting of a code identifying the metadata format and
         optional sub-namespace code(s) separated by a colon(s); and

You've omitted mention of the hyphen which separates these two parts.

       o a string assigned by the format maintenance agency or a third
         party. Such strings may be constructed according to the local
         preferences as long as they are are aligned with the requirements
         of RFC 3986 and RFC 8141.

The "third party" is not described elsewhere in this document.  You
need to specify that.  I suspect that you mean that some format
maintenance agencies have rules permitting other parties to assign
strings in certain ways.  A way to fold these cases together is "a
string assigned under the auspices of the format maintenance agency",
meaning that the prefix specifies the maintenance agency, and the
agency's rules specify who defines the meta-string and how.

    The following formal definition uses ABNF [RFC5234].

        meta-nss     = prefix "-" meta-string

        prefix      = format-code *( ":" subspc )
                    ; The entire prefix is case insensitive.

        format-code  = 1*(ALPHA / DIGIT)
                    ; As assigned by the National Library of Finland
                    ; (identifies the metadata format to which the branch
                    ; is delegated).
You might want to say "(identifies the metadata format and its
maintenance agency)".

        subspc      = 1*(ALPHA / DIGIT)
                    ; As assigned by the respective format maintenance agency.

        meta-string  = path-rootless
                    ; The "path-rootless" rule is defined in RFC 3986.
                    ; Syntax requirements specified in RFC 8141 MUST be
                    ; taken into account.
You probably want to add a comment "The meta-string is
case-sensitive." or "The meta-string is case-sensitive unless
specified as case-insensitive by the maintenance agency."

    The following metadata format codes SHALL be used: 
You probably want to say instead "The initial assignments of
format-codes to maintenance agencies is:"  Also, since these are
delegations to organizations, you need to give at least
semi-formal names of the organizations.  The URLs you list should
probably be titled "for further information, see".

(My suggestions below would add a column "Resolver base URL" to this table.)

    Descriptive metadata 

    Code        Format(s)               URL
You probably want to say "format-code" explicitly instead of "code" if
you mean the format-code defined above, to maximize clarity.

    BF  BIBFRAME        http://www.loc.gov/bibframe/ 
    DC  Dublin Core     https://www.dublincore.org/specifications/dublin-core/ 
    DDI DDI             https://ddialliance.org/explore-documentation 
    EAD EAD             https://www.loc.gov/ead/ 
    IMARC       INTERMARC       https://www.bnf.fr/fr/intermarc-bibliographique-de-diffusion 
    LIDO        LIDO            http://network.icom.museum/cidoc/working-groups/lido/ 
    MARC        MARC 21         https://www.loc.gov/marc/marcdocz.html
    MARCXML     MARCXML         http://www.loc.gov/standards/marcxml/ 
    MIX MIX             http://www.loc.gov/standards/mix/ 
    MODS        MODS            http://www.loc.gov/standards/mods/ 
    ONIX        ONIX            https://www.editeur.org/8/ONIX/ 
    UNIMARC     UNIMARC         https://www.ifla.org/unimarc 

    Administrative metadata

    Code        Format          URL

    PREMIS      PREMIS          http://www.loc.gov/standards/premis/ 
    TEXTMD      textMD          https://www.loc.gov/standards/textMD/
    AUDIOMD     audioMD         https://www.loc.gov/standards/amdvmd/
    VIDEOMD     videoMD         https://www.loc.gov/standards/amdvmd/ 

    Cataloguing rules 

    Code        Rules           URL

    ISBD        ISBD            http://iflastandards.info/ns/isbd/elements/
    RDA RDA             https://www.rdaregistry.info 

    One code may cover an entire family of formats (e.g. MARC
    Authority, Bibliographic and Holdings formats). Sub-namespaces may
    be used to differentiate formats within these format families if
    necessary.
Add "Since all prefixes with the same format-code are delegated to the
same maintenance agency, such families are perforce maintained by the
same agency."

    National translations of metadata standards and cataloguing rules
    shall use the codes and URNs of the original specifications. Thus
    the Finnish translation of MARC 21 shall use the prefix MARC of
    MARC 21 and URNs assigned to the elements of the English version
    of the format. HTTP language negotiation will be used by the URN
    resolver to direct the client to the correct language version.
The last sentence assumes that resolution is done via HTTP.  If there
are other possibilities, this sentence should be written more generically.

    National variants of metadata formats (e.g. historical FINMARC
    format, which was based on equally outdated USMARC) should have
    their own format codes, since their tags may differ from the
    original ones. For instance, UKMARC tag 245 is not the same as
    USMARC tag 245, since in the former subtitle had its own tag, 248.
Add "whereas in the latter, subtitle ..."?
    New codes will be added by the National Library of Finland on
    request.
This sentence is very important and should be moved into a separate
section titled "Registering format-codes" or something like that, with
the section giving long-lived postal and e-mail addresses for
submitting registration requests, and any necessary procedural
information.

You also want to state that the National Library of Finland will
publish the registration database; ideally you will provide a URL for
fetching a machine-processable copy of the registration database.

    The structure (if any) of the meta-string is determined by the
    authority for the prefix.  Whereas the prefix is case insensitive,
    meta-strings MAY be case sensitive at the preference of the
    assigning authority; parsers therefore SHALL treat these as case
    sensitive, and any case mapping needed to introduce case
    insensitivity is the responsibility of the relevant resolution
    system.
You want to move or duplicate the second sentence of this paragraph into
the section "Rules for lexical equivalence".

    A hyphen MAY be used as the delimiting character between the
    prefix and the meta-string.  Within the meta-string, a hyphen MAY
    be used for separating different sections of the identifier from
    one another.
The first sentence above is redundant as the ABNF says that a hyphen
MUST be used as the delimiting character in that position.  The second
sentence is largely redundant, as the syntax of RFC 3986 allows
hyphens in many places in path-rootless; it is only a suggestion that
a particular meaning can be assigned to hyphen.  An open question is
whether it is RECOMMENDED that "a hyphen be used for separating
different sections of the identifier from one another" or just MAY.

    A colon SHOULD be used within the prefix only as a delimiting
    character between the format code and sub-namespace code(s), which
    splits the format specific namespace into smaller parts.
Similarly, a colon can only be used in this way, as the ABNF does not
permit colons in format-code or subspc.  So stating this is redundant.

    Maintenance agencies SHOULD NOT use in meta-strings characters
    requiring percent-encoding.

    Case insensitivity of the prefix must be taken into account when
    URN:META identifiers are analyzed.
Better is to say "compared" than "analyzed".  But you should copy to
here the statements from above about which sections of the URN are
case-sensitive and which are not.

    META assignment:

    National and international metadata format maintenance agencies
    may use URN META when they want to assign persistent identifiers
    for the metadata elements and tags of their formats, and provide
    URN-based access to machine or human readable descriptions about
    these metadata elements. For the time being these descriptions are
    unstructured text on Web pages.

    The URN assigned to the element shall not change even if the
    description of the element is changed. URNs assigned to deleted
    elements shall not be re-used.

    Metadata format maintenance agencies shall have procedures in
    place to make sure that the assigned URNs are unique and
    persistent. Since the number of metadata elements on formats is
    relatively low (at most a few hundreds) such procedures can be
    simple (e.g. URN can be based on the name of the element).

    If a format has been translated to multiple languages, agencies
    maintaining the original version and its translations shall agree
    between themselves who will assign URNs to its elements, default
    value being the organization responsible of the original version
    of the format.
Really, the agency registered for the format-code either assigns the
URN or decides which organization assigns the URN -- that's what
registration means.  You may want to state the above sentence saying
"... SHOULD agree among themselves ..., but the registered agency for
the format-code has ultimate authority".

    Security and Privacy:

    URN:META identifiers do not have any known security or privacy issues. 
You may want to add, "They are intended to have publicly-known
meanings and do not refer to specific individuals, groups, or
organizations."

    Interoperability:  

    URN:META identifiers do not have any known interoperability related issues. 

    Resolution:  

The section needs major revision.  Right now, it speaks generally and
vaguely about possible ways to do resolution.  What the section needs to do
is provide enough information so that if someone wanted to write a
program that would resolve a general URN:META, they could do so.

My guess as to what you want to say runs something like this:

Each registrant of a format-code MUST register a base URL (ending in
"/") for a resolution service for URN:METAs that have that
format-code.  A registrant may provide additional base URLs for
prefixes composed of that format-code and one or more following
subspc's.  The base URL for resolving a particular URN:META is the
base URL for the longest registered prefix which is an initial part of
the URN's prefix.

(One prefix is an initial part of another prefix if it contains the
latter's format-code and the leading zero or more entire subscp's of
the latter.  Thus, "urn:meta:example:abc:def-012345" has these
prefixes as initial parts:
    example
    example:abc
    example:abc:def
But this prefix is not an initial part:
    example:abc:d
)

A URN:META is resolved by composing a URL by concatenating the base
URL with the URN:META and fetching that URL using the normal
HTTP/HTTPS GET method.  The retrieved resource SHOULD describe the
identified metadata element and MAY provide or reference further
information about it.

Resolution services MAY respond to GET requests with a redirection
response whose Location header field is a URL of a preexisting
description of the element.  If information about the element is
available in multiple languages, a resolution service SHOULD use
the HTTP Accept-Language header to select a URL of a resource in the
user's requested language.

With this approach, Example 1 would be revised as:

EXAMPLE 1 

urn:meta:marc-bd245
URN of the MARC Bibliographic format tag 245 (Title Statement)

Assuming that the registered resolver base URL for urn:meta:marc is
http://example.com/, urn:meta:marc-bd245 would be resolved by fetching

http://example.com/urn:meta:marc-bd245 

which (absent an Accept-Language header in the GET request) would redirect to

https://www.loc.gov/marc/bibliographic/bd245.html  

If the request contained "Accept-Language: fi" (preferring Finnish), it
would redirect to

https://marc21.kansalliskirjasto.fi/bib/20X-24X.htm#245

If the request contained "Accept-Language: sv" (preferring Swedish),
it would redirect to

http://www.kb.se/katalogisering/Formathandboken/Bibliografiska-formatet/210-249/#245

    General

    URNs in the URN:META namespace shall be resolvable. 

    URN:META namespace shall support URN to URL resolution service
    from the identifier to the page describing the identified metadata
    element, or another service which fulfills a relevant function
    within this context.
What does "another service which fulfills a relevant function within
this context" mean?

    Resolution services may be maintained by the agencies maintaining
    the formats or a third party. If so, the agency maintaining the
    format and the agency shall agree on how the URN -- URL mappings
    are maintained.

    Locating the appropriate resolver

    There is no automated mechanism for locating the correct URN
    resolver for a URN:META identifier. Once a format maintenance
    agency has decided to implement URNs, if makes independently the
s/if/it/
    decision of which resolver shall support resolution of its URNs
    within the URN:META namespace.

    Initially URN:META URNs will be represented as HTTP
    URIs. Eventually URN:META identifiers may become resolvable as
    such. Each sub-namespace may have its own resolver.
This paragraph needs to be revised.  What does the word "represented"
mean?  What does "resolvable as such" mean?  (How can a URN be
resolvable without being resolvable "as itself" in some sense?)

    Example 

    Namespace URN:META:MARC: contains URNs which identify the tags of
    MARC 21 metadata formats (https://www.loc.gov/marc/) in various
    languages.

    In this example, URNs are expressed as HTTP URIs which use
    (non-existent) URN resolver located http://example.com.

    If the language setting of the client is English (and as a
    default) URNs http://example.com/urn:meta:marc:<nss> will be
    resolved at MARC 21 format specific pages at directories

    https://www.loc.gov/marc/bibliographic/
    https://www.loc.gov/marc/authority/
    https://www.loc.gov/marc/holdings/

    on the Library of Congress site. 

    EXAMPLE 1 

    URN of the MARC Bibliographic format tag 245 (Title Statement)

    http://example.com/urn:meta:marc:bd245 
Assuming that the final path component of this URL is intended to be a
URN:META, it is incorrect, as a hyphen separates the prefix from the
meta-string.  The format you want is urn:meta:marc-bd245.  Similarly
with a number of examples below.

    resolves as a default to URL

    https://www.loc.gov/marc/bibliographic/bd245.html  

    EXAMPLE 2 

    URN of the MARC Authority format tag 100

    http://example.com/urn:meta:marc:ad100  

    resolves as a default to URL 

    https://www.loc.gov/marc/authority/ad100.html 

    unless the Accept-Language header setting is used to direct the
    user to a page in e.g. Finnish or Swedish.

    Since pages for all tags in MARC 21 format for bibliographic data
    have been named in the Library of Congress Web site using the same
    syntax (file name is bdxxx.html, where xxx is the MARC tag), no
    URN -- URL mapping table is required in the resolver. URNs can be
    mapped to URLs of their descriptive pages programmatically.

    Using HTTP language negotiation the client may request this page
    in other languages.

    EXAMPLE 3 

    If the language setting of the client is Finnish, URN 

    http://example.com/urn:meta:marc:bd245 

    resolves to  

    https://marc21.kansalliskirjasto.fi/bib/20X-24X.htm#245

    and if it is Swedish, to 

    http://www.kb.se/katalogisering/Formathandboken/Bibliografiska-formatet/210-249/#245

    If the language setting is not supported, default (English) shall be used. 

    EXAMPLE 4 

    URN of the Dublin Core Terms namespace property Title

    http://example.com/urn:meta:dc:terms-title 

    resolves as a default to 

    http://purl.org/dc/terms/title

    and URN of the Elements 1.1. namespace property Title 

    http://example.com/urn:meta:dc:elements-title

    resolves as a default to 

    http://purl.org/dc/elements/1.1/title

    Persistence

    Persistence of URN:META resolution services depends on the
    persistence of metadata formats.

    Element specific metadata about deprecated metadata formats such
    as USMARC, UKMARC or FINMARC may be hard to find and its form and
    content may not be suitable for URN resolution. See for instance
    UKMARC documentation at

    https://www.webarchive.org.uk/wayback/archive/20160107133726/http://www.bl.uk/bibliographic/ukmarc.html

    or FINMARC documentation at 

    https://www.kiwi.fi/display/Marc21/FINMARC   

    Additional documentation / information:  

    None

    Revision Information:  

    This registration request is applicable to metadata formats and
    cataloguing rules listed above. Other formats and rules may be
    added in the future, with additional examples.

    This request has been updated 2020-02-07. Examples including
    hyphen have been added, and resolver address http://urn.fi has
    been replaced by http://example.com.

[END]