Paul and List,
First, I should clarify something about my earlier post. I wrote at the start of Scenario 3:
"3) Issue data-less LSIDs without using the revision ID feature, and track data change history separately from the LSIDs"
That should have been "...and track *metadata* change history separately from the LSIDs" (metadata, not data).
So, without making things too complicated as we 'start to walk' in this domain of biodiversity informatics my vote is for a variation of scenario 3) from Rich. The reason I vote for this is that in the fullness of time, and the 'herb.IMI' database has already started this, much of the metadata with be LSIDs and it's correctness (i.e. sorting out typos etc) will be delegated to the entities who issue those LSIDs. As IPNI improves the quality of the metadata associated with the LSIDs they issue (and if I understand correctly they do use the scenario 3) from Rich) so the quality of the metadata associated with a 'herb.IMI' LSID improves. The reason I prefer the data + metadate 'model' is that in this instance the data is fixed ... who changes collection/accession numbers? ... so perfect for this role. Even if a collection moves to a new owner the original data need not 'disappear' in the same way that DOI's move with the objects as book and journal titles change from one publisher to another.
So...if I understand correctly, you differ from my scenario 3 in that you do generate data-bearing LSIDs for specimens, but the data part is limited to only the Accession number, not the complete set of data fields associated with the record -- correct? So, in effect, the object LSID actially applies to is the binary accession number, not the "concept" of the specimen. I can imagine in this case that the LSID can be thought of as representing the "concept of the specimen" because the accession number itself is a surrogate for the physical specimen. The only thing that concerns me about this approach is that there is a non-zero incidence of accidental duplicate catalog numbers within a given collection, and possibly errors in associating catalog numbers. For example, if the computer database for a collection had an error created by a technician who, for example, entered the metadata for accession number IMI1234569 by mistake, when it should have been IMI1234596 (and vice versa), then branding the accession number as "data" for the LSID means that the LSID technically *must* stay with the accession number (not the specimen associated with the metadata for that LSID), after the error is discovered. Not a huge problem, but could surprise people who had indexed the LSID before the error was discovered, who then came back to resolve it again after the error was fixed (i.e., they would get totally wrong information). Given how rare this problem is likely to be (against a backdrop of many far more likely problems we will have to overcome), I don't see this as a strong reason not to proceed with your plan.
Final point, the 'data' is the 'herb.IMI' accession number; in context this is a GUI because of the existence of Index Herbariorum. So, our data will be 123456 not IMI123456 because ... in the fullness of time we will include an Index Herbariorum LSID to 'identify' the 'institutional acronym' element of the metadata.
Is the binary data for the accession number in 8-bit, or 16-bit? I'm assuming 8-bit would be fine, as I suspect all collections would have accession numbers that can be rendered with 256-character ASCII. Is there any "wrapper" to the number as binary data, or is it a straight ASCII binary representation (e.g.: 001100010011001000110011001101000011010100110110 for "12345")?
I'm not sure I follow the logic of how embedding the accession number as data for the LSID allows the LSID to move to a new owner. I would think the opposite. Isn't it likely that the new owner would create their own accession number for the specimen? In this case, they would be forced to generate a new LSID if they were following the same practice of encoding the accession number as "data", rather than metadata.
Also, wouldn't it make more sense to include the acronym (IMI) as part of the data for the LSID? At least that way the "12345" would have *some* context.
Finally, this approach would work only for collections where there is a strict 1:1 correlation between accession numbers and specimen objects for which an LSID is desired.
Thanks for your comments -- this thread is already forcing me to think about things in a way I hadn't thought of them before.
Aloha, Rich
Richard L. Pyle, PhD Database Coordinator for Natural Sciences and Associate Zoologist in Ichthyology Department of Natural Sciences, Bishop Museum 1525 Bernice St., Honolulu, HI 96817 Ph: (808)848-4115, Fax: (808)847-8252 email: deepreef@bishopmuseum.org http://hbs.bishopmuseum.org/staff/pylerichard.html