Re: [urn] URN:META namespace registration request

[[e-mail] (Dale R. Worley)]

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.

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