[tdwg-guid] First step in implementing LSIDs?[Scanned]

[Kevin Richards]

I think it would be best to completely ignore the idea LSID data, unless
we have a strong use case for it.  (I'm pretty sure we came to this
conclusion after the GUID meetings).  All "required" information should
be in the metadata.

The other issue here is how to "create" an LSID - what to use for the
Object part of the LSID.  If we use, for example, accession numbers,
then the LSID does get "tied" to a particular
dataset/database/organisation (the problem of moving objects from one
organisation to another was also covered in the GUID meetings - see the
GUID pages on the Wiki and the guid mailing list history for some rich
discussion on these topics).  So long as this issue has been considered
when creating LSIDs, and they are guaranteed unique, I dont particularly
see the problem with using the "accession number".

Kevin


>>> "Paul Kirk" <p.kirk at cabi.org> 06/02/07 10:14 PM >>>
Yes Rich, our plan is to apply the LSID to the accession 'number'
(actually an accession 'code' as we have an historical legacy of suffix
'a', 'b', etc for subdivisions of the original collection which in many
cases is a collection of objects rather than one physical object - a bag
of leaves for example). And yes, there are some possible problems with
errors associated with the metadata but ... in the cotenxt of a DBMS
where the accession number is set to unique values only, duplications
are in reality impossible, and yes there are far more important
challenges to address than this ... ;-)
 
I assume you are correct about the
001100010011001000110011001101000011010100110110 ... I'm a systematist
leaning towards nomenclature rather than an IT person.
 
I guess the 'change of ownership' comment was directed at the importance
of retaining the accession number as this is cited in the literature,
and the utility of keeping this as a resolvable LSID.
 
A rather complex model is required for 'managing' the objects of a
collecting event and what subsequently happens to those objects, which
others have more experience of and valid opinions on - I refer, for
example, to a pit trap for insects where multiple objects are assigned
an initial accession number, the objects are subsequently divided and
divided again and again and finally a few may end up on pins as name
bearing types.
 
Cheers,
 
Paul

________________________________

From: Richard Pyle [mailto:deepreef at bishopmuseum.org]
Sent: Sat 02/06/2007 10:08
To: 'Paul Kirk'; 'Jason Best'; tdwg-guid at lists.tdwg.org
Subject: RE: [tdwg-guid] First step in implementing LSIDs?[Scanned]




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 at bishopmuseum.org
http://hbs.bishopmuseum.org/staff/pylerichard.html




************************************************************************
The information contained in this e-mail and any files transmitted with
it is confidential and is for the exclusive use of the intended
recipient. If you are not the intended recipient please note that any
distribution, copying or use of this communication or the information in
it is prohibited. 

Whilst CAB International trading as CABI takes steps to prevent the
transmission of viruses via e-mail, we cannot guarantee that any e-mail
or attachment is free from computer viruses and you are strongly advised
to undertake your own anti-virus precautions.

If you have received this communication in error, please notify us by
e-mail at cabi at cabi.org or by telephone on +44 (0)1491 829199 and then
delete the e-mail and any copies of it.

CABI is an International Organization recognised by the UK Government
under Statutory Instrument 1982 No. 1071.

**************************************************************************



++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
WARNING: This email and any attachments may be confidential and/or
privileged. They are intended for the addressee only and are not to be read,
used, copied or disseminated by anyone receiving them in error.  If you are
not the intended recipient, please notify the sender by return email and
delete this message and any attachments.

The views expressed in this email are those of the sender and do not
necessarily reflect the official views of Landcare Research.  

Landcare Research
http://www.landcareresearch.co.nz
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++