Proposed approach to versioning and shared names

[Alan Ruttenberg]

I have been thinking about how to handle the versioning issue in the
context of shared names.

Assumptions:
- Some databases explicitly version at the record level and have
distinct identifiers different version so the same record. An example
is Refseq.
- Some databases version at the "build" level - i.e. the whole
database gets a new version at once, however new
accessions/identifiers are not created.
- Most database do not explicitly version. Instead we always have the
"latest" version available.
- Previous attempts to manage versioning in similar efforts have
failed because they assume too much about what the provider will do.

Therefore, I propose the following:

In all cases, there will be a single "about" record without commitment
to encoding or version.

In those cases where a provider explicitly names versioned records, a
uri will be allocated using the provider's identifiers, and the about
record will link to it.

In those cases where the the database as a whole is versioned, and
where the provider or a third party provides access to prior versions,
the committee will determine the form of the URI for the prior
versions, for example by appending the database version to the
identifier. The URI will be linked to in the about record.

In the case of databases that do not explicitly version, third parties
who archive versions and wish to make them available via shared name
will be handled in the same way we handle other third party metadata,
i.e. review followed by inclusion in the about record. The URI form
will concatenate the identifier and the date on which the record was
archived.

Metadata provided in the about record will record information known
about the version, e.g. date, build, and links to any provider
information about versioning policy, so those clients who have a
particular interest in versions are able to easily determine which
versions are present and whatever is known about them.

I believe a policy along these lines give use the flexibility to
provide useful naming for versions, while not committing more than we
can to what, precisely, one can expect vis a vis persistence or
policy.

-Alan