innovation in metadata design, implementation & best practices

Topic: Encoding schemes for the Library Application Profile
Modified: 2004-03-22 09:41, Monday
Maintainer: Tom Baker
Latest version:
See also:

Shepherd: Rebecca Guenther


In Ithaca, and then again in Seattle, we discussed whether
the following Encoding Schemes, needed for the DCMI Library
Application Profile, should be formally approved and declared
by DCMI:

    9) Country Codes (sic)

Whether or not this should be done is a question that differs
case by case, depending on whether the maintainers of the
resources in questions were likely themselves to assign URIs
or whether evolving practice for URIs and URNs would likely
provide workable solutions in the short term that could make
a DCMI-specific approach redundant.

The following is my rough-cut assemblage of notes and excerpts
from email as a guide; Rebecca will provide the latest status
on each.

Incidentally, I discovered while writing this summary that
clicking on any of the URIs above takes one to the top of
the file, even though
none of those URIs exist...


In Ithaca in June 2003, we discussed proposals for several
encoding schemes [1].

The Ithaca notes show we approved two proposals [2]:
-- (by a vote of 7 to 1) 
-- (by a vote of 8 to 0)

We also decided [2]: "New terms to go in the terms namespace
with one or two exceptions (MARC, DOI?). Discussions and
agreement on new terms to be continued online in early to

I see the proposals were discussed in July 2003 [3,4,5]
and then in Seattle, and this would appear to be the state
of affairs:

   Discussed and approved. I have put a draft of the decision text at
   If Rebecca confirms this is accurate, we can publish it after the 
   Bath meeting.

   Note that Roland suggested [4]: "As far as ISO
   8601 is concerned i refer to the Abstract of as well as May I suggest
   to include both links with the registration of ISO 8601."
   Rebecca agreed that these links should be included.

   In Ithaca, we decided that Rebecca needed to investigate
   whether AAT has a persistent URI at Getty. So it was deferred
   for further research (the URI could be added later once approved).
   This should now change to use the MARC namespace. Getty has
   not established persistent URIs. They were comfortable
   with using the MARC source code rather defining a new
   one in the DC namespace. (Contact there was Murtha Baca).
   I included this revised proposal in the document discussed
   in Seattle and it was approved. The URI should be: There was some
   discussion of whether, as an Encoding Scheme, AAT would
   need to be in uppercase, but it was affirmed that such URI 
   assignment policies are the prorogative of the agency assigning
   the URIs.

   In Ithaca, we decided this needs to be revised and
   resubmitted for a vote [3]. In Seattle, this was submitted
   as "gmgpc" and using the MARC namespace (the same as
   TGM2). So it is: Same
   question about upper vs. lower case.

   Rebecca in July [3]: "Andy indicated that any of these may
   be expressed as a URI, and that they should be expressed
   this way. Thus, it is not necessary to add, since the
   encoding scheme "uri" would be indicated. (I think there
   is disagreement about this approach, since some have not
   been registered through IANA as a URI scheme or URN name
   space.) Comments?"

   In February 2004: "Can't be expressed as URI, since it
   hasn't been approved as a URN namespace or URI scheme. See

   Roland on SICI [4]: "Some Problem with SICI: The
   Contribution Segment seems to explicitly use <
   and > signs. Use of SICI's in a literal way could
   cause trouble in XML. Need to get into touch with
   SICI about standardized escaping mechanism - seeAlso (on a
   related problem with interpreting SICI as URN)"

   Rebecca, 2004-02: This could still be a problem and needs
   to be done.

   SEATTLE Vote on SICI [6]: UB approves SICI conditionally (and
   unanimously). If the IETF InfoURI proposal is accepted
   SICI will be encoded as a URI and UB approval for SICI
   as an encoding scheme is unnecessary. If this is the case
   the vote becomes redundant.

   Roland on ISBN [4]: "ISBN registered as Formal URN
   Namespace: seeAlso RFC3187"
   Rebecca, 2004-02: Yes. Express as URI.

   Roland on ISSN [4]: "ISSN registered as Formal URN
   Namespace: seeAlso RFC3044"
   Rebecca, 2004-02: Yes. Express as URI.

   Roland on DOI [4]: doi:10.1004/123456. -- But Tom does
   not believe this prefix was approved by IETF.

   Roland: Quoted from : "A DOI is
   an implementation of URI.." seeAlso NISO Z39.84 [I don't
   know whether Z39.84 has been recognized outside the US]
   - and info:doi/

   Rebecca: But it's not registered as a URI scheme. That is
   essentially why info came about. When those things were written
   I think noone knew what a stumbling block this was going to be.

   SEATTLE Vote on DOI [6]: UB approves DOI conditionally (and
   unanimously). If the IETF InfoURI proposal is accepted
   DOI will be encoded as a URI and UB approval for DOI as
   an encoding scheme is unnecessary. If this is the case
   the vote becomes redundant.

   Rebecca, 2004-02: On SICI and DOI: Info has not been formally
   approved by IETF, but NISO has already established a registry
   for info schemes. Does that give it some sort of status? I
   would think so. We could then bring a proposal to approve
   info in the NISO namespace and use schemes that are registered

   Roland: There was quite some discussion about info on
   rdf-interest and confusion. We need to consider what to
   do with pending (such as info) and possibly conflicting
   standardization approaches (such as doi).

   Rebecca: DOI is registered under INFO, so is not a
   conflicting approach. See:

   Roland: Right. But NISO has set up the registry anyhow. My
   point was that you had said SICI would come under info but
   that DOI was going another way. But that is not the case--
   they are both going the route of info.

   Andy, 2004-02-23:
   1) A URI scheme doesn't have to be registered for something
      to be a valid URI - it just has to conform to the
      URI spec. So
      is a valid URI irrespective of whether the 'doi' scheme
      is registered with IANA or not.

   2) It is not clear to me (based on discussions with Norman
      Paskin at DOI) whether the IDF is going firmly down
      the 'info' route or not. It is still the case that
      they only really recommend the doi:10.100/234 form of
      encoding AFAIK. So, 'info' may be one way of encoding
      a DOI, but it may be that the IDF never really endorse
      this mechanism??

      However, this is largely irrelevant... in order to
      encode a DOI in DC metadata you only need to use the
      URI encoding scheme, either as

      <meta name="DC.identifier" scheme="DCTERMS.URI"
      content="doi:10.1000/234"/> or <meta name="DC.identifier"
      scheme="DCTERMS.URI" content="info:doi/10.1000/234" />

      I have to confess that I still don't understand why
      we approved DOI as an encoding scheme in Seattle.
      Someone kindly put me out of my misery and remind we
      why we want to invent a DC-specific way of encoding DOIs
      (and the rest!)?

9) Country Codes (sic)
   To be revised and resubmitted for a vote.

   SEATTLE Decision [6]: Rebecca will consult with Andy as to
   proper URI identification of the Marc GAC and MARC Country
   Codes schemes. They will both live in a LC namespace.

   These go in the LC namespace: