Alternate identifiers in OPDS 2.0

[HadrienGardeur]

During our last two monthly calls, a number of stakeholders (including @jce1028 but also @barmintor through #66) mentioned their interest in supporting multiple identifiers in OPDS 2.0.

In our current draft, all metadata are inherited from the RWPM project, as documented in the default metadata profile.

A single identifier is currently allowed:

• it's validated against a URI in the dedicated JSON Schema
• and mapped to @id in the JSON-LD mapping document

While some identifiers can be expressed using a URI (ISBN, DOI and ISSN), some identifiers are unfortunately represented as a string, without any known URN namespace for them.

Proposal

• a new property that contains a list of alternate identifiers
• which would be used in: metadata, publisher, imprint, series, collection and all contributor roles (author, translator, narrator…)
• this new property would either support an array of URI or an array of "Identifier Objects"
• these new Identifier Objects would contain a value (string) and a scheme (URI)

Example 1: Multiple publication identifiers using URIs

"metadata": {
  "identifier": "urn:isbn:9780679760801",
  "altIdentifier": [
    "https://viaf.org/viaf/175580487/",
    "https://example.com/identifer/12345"
  ]
}

Example 2: Multiple publication identifiers using an Identifier Object

"metadata": {
  "identifier": "urn:isbn:9780679760801",
  "altIdentifier": [
    {
      "value": "123456789",
      "scheme": "https://example.com/identifierScheme"
    }
  ]
}

Example 2: Multiple identifiers on an author

"metadata": {
  "author": {
    "name": "Mikhail Bulgakov",
    "identifier": "https://isni.org/isni/000000012144993X",
    "altIdentifier": [
      "http://viaf.org/viaf/99836700",
      "http://id.loc.gov/authorities/n79056735"
    ]
  }
}

[HadrienGardeur]

We discussed this proposal during our latest monthly call on April 17th.

Overall, the proposal seems to be a good fit but the following points were discussed:

• A number of participants were more comfortable talking about "alternate identifiers" rather than "other identifiers", which better conveys the idea that these are equivalent to identifier. I'll update the proposal in this discussion accordingly.
• There's a separate but related conversation about relationship to other entities, for example the relationship between and ebook and a print book, or between a work identifier and one of its manifestation. It's easy to go down the rabbit hole if we look in that direction, but it's important to keep it in mind and discuss it with NYPL which is currently working on this.
• @llemeurfr is still uncomfortable with the usual RWPM approach of allowing both an array of strings and an array of objects.

[barmintor]

I am making sure we have all seen another working document: https://docs.google.com/document/d/1o94M8QPaigEZ8N6_EMwhzMQ-a3C5qgB4nC9LKqCL5JY/edit?usp=sharing

We had previously discussed using schema:identifier, which is I suppose not prohibited by the suggestions here; the identifier object examples in this discussion to not quite accommodate scoped identifiers such as MARC21 001 fields. I think this should (minimally) be documented in a non-normative example, as it is a core metadata use case for many libraries.

[llemeurfr]

Why not creating different wrappers for URLs and {scheme, value} objects?

"metadata": {
  "author": {
    "name": "Mikhail Bulgakov",
    "identifier": "https://isni.org/isni/000000012144993X",
    "altURIIdentifiers": [
      "http://viaf.org/viaf/99836700",
      "http://id.loc.gov/authorities/n79056735"
    ],
      "altTupleIdentifiers": [
    {
      "value": "123456789",
      "scheme": "https://example.com/identifierScheme"
    }
  ]
  }
}

The transformation to objects would be much easier (no specific JSON marshalling / unmarshalling).

[HadrienGardeur]

@llemeurfr I know that you don't really like the ability to use a mix of strings and objects in RWPM, but that's something that we already do all over the place: title, subtitle, author, translator, editor, artist, illustrator, letterer, penciler, colorist, inker, narrator, contributor, publisher, imprint, collection, series, subject…

Consistency is important and I believe that the current proposal is aligned with what we do elsewhere. I don't think that going in another direction with this property is a good idea.

While drafting this message, I noticed an inconsistency though in my current proposal: altIdentifiers instead of altIdentifier. With all of our other properties, we use the singular form, even when a property allows multiple values. I'll update the initial message accordingly.

[llemeurfr]

Another approach, for ids schemes that don't have a URI syntax, is to create our urn.

"altIdentifiers": [
      "http://viaf.org/viaf/99836700",
      "http://id.loc.gov/authorities/n79056735",
      "urn:rwp:ocolc:1397634"
    ]

Pros: simple to represent, marshal, manipulate.
Cons: parsing required for transforms to other representation (export). And we need to write a small spec for that.

[HadrienGardeur]

There's an official IANA registry, you're not supposed to mint new ones without an RFC or ISO standard: https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

Minting new URNs wouldn't be more helpful for clients who know nothing about them either, at least with the object it's very straightforward to identify an extension (just inspect the scheme).

[HadrienGardeur]

Here's the draft PR in the Readium repo for alternate identifiers: readium/webpub-manifest#102