simplifying identifiers

[jtauber]

In light of the improved clarity I think we've gained over the last couple of months on the role of identifiers and, in particular, them essentially being about what a particular system needs in order to associate the scripture burrito with a known resource or project, I'd like to throw the following proposal minimalist straw proposal out there:

All we need is an authority + identifier

No need for separate revision numbers or timestamps.

If revision numbers or timestamps are needed in order for a system to associate the burrito with a particular revision of a resource, then can't just just be part of the identifier? Should it really be the burrito spec's job to decide the structure and format of identifiers needed by a system? Why not just let the entire identifier be opaque from the burrito's point of view and any system that can read the identifier (either because it is the system that minted it or it happens to be able to read identifiers by another particular system) can glean all the information it needs from it. No need to force a particular structure.

[jtauber]

To add to this with an analogy. On the Web, URIs are identifiers. There is no attempt to distinguish identification of a resource with identification of difference revisions. URIs can be used to indicate a particular revision, or the latest revision, or all revisions. URIs themselves don't make this discussion. I'm questioning whether identifiers need to either.

[jonathanrobie]

We added revision numbers and dates because of DBL use cases. When someone exports a SB from Paratext and uploads it to DBL, DBL needs to know if this is newer than what it currently has as the most recent version - is this the most current version of the Paratext resource that has been uploaded to DBL or not? DBL also needs to be able to list the revisions it has of a given resource in order even if they were uploaded out of sequence. For this purpose, the date of creation of the Paratext resource is what matters. DBL should not need access to the Paratext servers to correctly sort the revisions it has by date.

…

On Thu, Feb 11, 2021 at 8:21 AM James Tauber ***@***.***> wrote: To add to this with an analogy. On the Web, URIs are identifiers. There is no attempt to distinguish identification of a resource with identification of difference revisions. URIs can be used to indicate a particular revision, or the latest revision, or all revisions. URIs themselves don't make this discussion. I'm questioning whether identifiers need to either. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#244 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANPTPLKT4WPRRYYA6NBCGDS6PKVNANCNFSM4XOZ4H3A> .

[jtauber]

So in this use case, DBL infers that two burritos are representations of two versions of the "same" resource because they have the same Paratext identifier (just differ in revision number and/or timestamp).

[jtauber]

So what that use case really needs is:

1. an identifier that stays the same across revisions
2. some ordered indicator of revision (whether a sequential number or timestamp)

[jonathanrobie]

The timestamp is particularly helpful, it lets people see, for instance, that a project has created no new revisions for 10 years. And if there are questions, someone working with DBL might have a conversation with someone working with Paratext projects, comparing notes.

…

On Thu, Feb 11, 2021 at 9:13 AM James Tauber ***@***.***> wrote: So what that use case really needs is: 1. an identifier that stays the same across revisions 2. some *ordered* indicator of revision (whether a sequential number or timestamp) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#244 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AANPTPLAW2FJM56ZI2D3F43S6PQYZANCNFSM4XOZ4H3A> .

[jtauber]

Helpful agreed, but should we require it or merely recommend it in SB?

One possibility is that we REQUIRE an ordered indicator and RECOMMEND it be a timestamp (if there are cases where a revision number is possible but a timestamp is not?)

[jtauber]

Or maybe we just REQUIRE a timestamp, in which case drop the revision number?

[jtauber]

In other words, I'm arguing we don't need both timestamp AND revision number. We just need something that can be compared across burritos with the same resource/project identifier.