Persistent ID proposal

Persistent ID proposal

Summary

Proposal for persistent (external) ID generation, management, and use in the knowledge grid, and updates to the knowledge object model in fedora, and the knowledge object model and API in Object Teller front-end, to accommodate.

Here is a discussion in [question and answer](Questions and Answers) format.

The basics
Use ark: ids
Use ezid.cdlib.org to mint ids
Use fedora internal ids for knowledge objects/containers
Use n2t.net as the root name mapping authority (resolver) so that n2t.net/ark:/... redirects to a KO in a K-grid instance
Every K-grid instance is an NMA, too, that knows how to map ark: ids to it's own KOs
Only one library can "own" an object (the creating library, but can transfer ownership within/between libraries). That's the local URL set as target at ezid.
Changing and (re)publishing an existing KO probably requires at least a version change, and may require a new ark: id. More will be revealed.

The create/update lifecycle
On creating a knowledge object
> create the KO as private
> create an ark: id, in the reserved state, via ezid
> update the entry at ezid with the KO's local URL (establishes "ownership")
On updates to the KO
> update the local KO
> KO should be private/unpublished, otherwise "republish" to the ezid entry with relevant metadata

Publishing/unpublishing a KO
On publishing a KO (assuming you are the owner)
> update the ezid entry with relevant metadata
> update the ezid entry to public (updates n2t.org)
> make the KO public in the local library
On unpublishing a KO (assuming you are the owner)
> this means the ezid target is you, but beware, others may hold references or have copies, so
> mark it unavailable at ezid and add a note as to what happened
> make the KO private in the local library
> consider letting everyone who uses or has cloned the KO know it's gone (how?)

Note: there is far more to the publish workflow, this is just the basic id management portion

Fetching a KO
If found locally (using the ark: id) return the object

| | If not found locally, | > either query n2t.org for a new URL (maybe in some other K-grid instance?) and try to get it | > or send them on the n2t.org and hope for the best!

Deleting a KO
First make sure it's unpublished
If it's never been published
> the ark: id is reserved and no one else will be relying on it, so
> delete it at ezid
> delete it in the K-grid. Bye-bye.
If it has been published previously and you are not the owner
> the ezid target URL is not you, and others may hold references or have copies, so,
> delete the KO locally
> consider letting everyone who uses your copy the KO know it's gone (how?)
If it has been published previously and you are the owner
> the ezid target is you, but others may still hold references or have copies, so
> mark it unavailable at ezid and add a note as to what happened
> delete the KO locally
> consider letting everyone who uses or has copied the KO know it's gone (how?)

Transferring ownership of a KO Update the ezid entry with a new target URL (updates n2t.org)

Examples

(all the same object)

http://dlhs.med.umich.edu/object-teller/ko/ark:/234543/789098
http://dlhs.med.umich.edu/object-teller/ko/234543/789098
http://kgrid4.baylor.edu/object-teller/ko/234543/789098
http://n2t.net/ark:/234543/789098

(w/ suffix passthrough, allows containment and variation)

http://dlhs.med.umich.edu/object-teller/ko/ark:/234543/789098/v2/payload
http://dlhs.med.umich.edu/object-teller/ko/ark:/234543/789098/v2/payload.html
http://n2t.net/ark:/234543/789098/payload/
http://dlhs.med.umich.edu/object-teller/ko/ark:/234543/789098

---

Some possible extensions (don't worry about these now)

We might need to have one library (or library service more correctly) that can act as a central ark: id minter once there are multiple, distributed libraries. It's not super clear how to handle a library owned by another organization getting ark: ids from ezid and attaching them to KOs.

• If they are their own name assigning authority and use the same ezid minting process, it should work pretty much seamlessly.
• if they use their own minter but are willing to create/register the ark: id with ezid (which will push it to n2t.org) I think that'll work too. Which leads us to the next point:

Maybe we can allow each library to choose it's own persistent ids...but what sort of workflow and features would they need to support.

• As mentioned above, if it's an ark: id and registered with ezid (requires an account) that probably works ok. We don't need to control minting ids, but to enable some distributed library use cases they have to be registered (mapped) centrally
• the biggest risk to allowing non-ark: id persistent identifiers (other than losing the natural goodness of the ark: style) is that suffix pass-through is complicated somewhat. We would probably have to enhance the K-grid name mapping services, to cover cases ezid doesn't support, and so we'd be taking on an additional role as the central NMA for at least some of the distributed libraries. Like I said, complications....

We could allow private networks/relationships between libraries

• This might mean that my library can talk to your library about its KOs—and resolve, import/export, search, even manage collections in your library. However, the KOs (meaning the ark: ids) are simply not known/resolvable publicly. This could be pretty straightforward to implement by just not providing a target URL at a/the central NMA via ezid, and/or keeping the id reserved but not published, and/or adding specific meta-data, and/or just blocking attempts to access the "private" portion of a particular library.
• It might also mean that two (distributed) libraries could seem more like one? Have a trust relationship? Share collections and users?
• Not sure.

There is probably a case to be made for centralizing not just persistent identifiers, but some metadata

• at least in indexed form to aid in distributed discovery use cases
• Again, not sure.

There is probably a case to be made for using ark: ids as the internal identifier

• for the root KO at least
• then different libraries will have the same internal id for the same object
• in some ways this makes them implementation-level backups, not just logical backups