Identifier revision management

[jtauber]

In #232 I currently side-step the question of revisions. That's what this discussion is intended to be about.

The fact that an authority may give both an identifier and revision number means there is a conceptual notion of a single burrito with multiple revisions. In other words, the use of the same identifier (with different revision numbers) is an assertion by a particular authority that two burritos are two versions of the same thing.

Note that this notion is specific to an authority. Authority A may deem SB 1 and SB 2 to be versions of the same thing while Authority B gives them entirely different identifiers.

I don't know if the spec should say anything about what it means for two burritos to be versions of the same thing. Is it acceptable, for example, for the flavour to change between versions?

[jtauber]

What happens if I make a change to the SB, thereby invalidating other authorities' version numbers?

[jonathanrobie]

I don't think it makes sense for a SB to have revisions. A SB should not change.

A SB is created by some system that creates revisions of the underlying resource. The resource has revisions. The SB identifies the resource and the revision to which it corresponds.

[jtauber]

This is helpful conceptually, if we always view it as a snapshot. I'll try to tighten up some of the language to make this clearer.

[jag3773]

However, I think we do need to maintain the pointers to other id authorities somehow. If we don't do this, then we will not be able to round trip a project between two systems, which is a fundamental design goal.

I recommend that the id be the only required field and revision and timestamp are optional. Then we document and/or enforce with the schema that there can only be 1 revision+timestamp included. Possibly, this warrants 2 subsections under idAuthority, one for the current information and one for previously known ids to be listed.

[jonathanrobie]

What is the advantage of making revision and timestamp optional? I don't know how to roundtrip if I can't identify the revision that I need. I can't tell if a revision is earlier or later without the timestamp if I don't have access to the system that knows how to find out when revisions were created. I suspect making both required is much more useful.

[jonathanrobie]

However, I think we do need to maintain the pointers to other id authorities somehow. If we don't do this, then we will not be able to round trip a project between two systems, which is a fundamental design goal.

I'm not tracking with you. Could you sketch out the use case you have in mind? For Paratext and DBL, at least, identifying the source for a variant is sufficient. Paratext creates a resource, DBL creates a variant and gives it a DBL identifier and revision, with a section that identifies the source's identifier and revision in Paratext.