Re: [urn] URN:META namespace registration request (Dale R. Worley) Sat, 29 February 2020 02:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B07793A09EE for <>; Fri, 28 Feb 2020 18:48:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.982
X-Spam-Status: No, score=-0.982 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bHowfcogPx1E for <>; Fri, 28 Feb 2020 18:48:21 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B4CDA3A09E8 for <>; Fri, 28 Feb 2020 18:48:21 -0800 (PST)
Received: from ([]) by with ESMTP id 7s7EjGPS8sAwi7sAujqsrI; Sat, 29 Feb 2020 02:48:20 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20180828_2048; t=1582944500; bh=JcKvaBET9MxMlVdo+G5YKHfGrpdIkOnlgefR1jB9woo=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=N5SEFsQoJSfpkWJrzEL7LvNpfuSGKckZMzkcyJM7U4UZyME1urV7Y0TzIbM9eNpoM acYhREijzkDRHPA94OcdGLVKeJzXkFwDNJ1KFnmmBcFHVhVvsh40V1M+utexUnzZtY G+kCI+B55vqOkoXJ7wyrigJzZ3Cz2ASybjA0Sj0BS1u+0fv+5qS0AUdl3SNQSls+8x gtCwG81RibgFjd8D5hVhh7J8x5UjZ/W9rL5fcZf3o70ZqVwY8GeVNcF3loeo20pIhx +UEwez+a/uBp0a0S4rOByJDAX2VJAAR2zBkGeqVOIlggkhC2tTLi+OEct5d8FFhacH LEFqB14G2FI+g==
Received: from ([IPv6:2601:192:4600:c190:222:fbff:fe91:d396]) by with ESMTPA id 7sAqj15HIbBT87sArjdSut; Sat, 29 Feb 2020 02:48:19 +0000
X-Xfinity-VMeta: sc=-106.00;st=legit
Received: from ( []) by (8.14.7/8.14.7) with ESMTP id 01T2mFYQ008290; Fri, 28 Feb 2020 21:48:16 -0500
Received: (from worley@localhost) by (8.14.7/8.14.7/Submit) id 01T2mDmi008258; Fri, 28 Feb 2020 21:48:13 -0500
X-Authentication-Warning: worley set sender to using -f
From: (Dale R. Worley)
To: "Hakala\, Juha E" <>
In-Reply-To: <> (
Sender: (Dale R. Worley)
Date: Fri, 28 Feb 2020 21:48:13 -0500
Message-ID: <>
Archived-At: <>
Subject: Re: [urn] URN:META namespace registration request
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Feb 2020 02:48:25 -0000

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


    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?


    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  

    in the /terms/ namespace, and PURL

    in the /elements/1.1/ namespace. Different PIDs are necessary
    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

    French translation of DCMI Metadata Terms3 uses the same PURLs,
    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.
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.

    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

    and the Swedish description has URL

    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: 


    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

    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.


    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.


    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

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


    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.

    DC  Dublin Core 
    DDI DDI    
    EAD EAD    
    LIDO        LIDO   
    MARC        MARC 21
    MIX MIX    
    MODS        MODS   
    ONIX        ONIX   

    Administrative metadata

    Code        Format          URL

    TEXTMD      textMD
    AUDIOMD     audioMD
    VIDEOMD     videoMD 

    Cataloguing rules 

    Code        Rules           URL

    ISBD        ISBD  
    RDA RDA    

    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
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
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

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
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.

    Rules for lexical equivalence:

    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


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


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:
But this prefix is not an initial part:

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:


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

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

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

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

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


    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
    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?)


    Namespace URN:META:MARC: contains URNs which identify the tags of
    MARC 21 metadata formats ( in various

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

    If the language setting of the client is English (and as a
    default) URNs<nss> will be
    resolved at MARC 21 format specific pages at directories

    on the Library of Congress site. 

    EXAMPLE 1 

    URN of the MARC Bibliographic format tag 245 (Title Statement) 
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  

    EXAMPLE 2 

    URN of the MARC Authority format tag 100  

    resolves as a default to URL 

    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 

    resolves to

    and if it is Swedish, to

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

    EXAMPLE 4 

    URN of the Dublin Core Terms namespace property Title 

    resolves as a default to

    and URN of the Elements 1.1. namespace property Title

    resolves as a default to


    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

    or FINMARC documentation at   

    Additional documentation / information:  


    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 has
    been replaced by