<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi there folks,<br>
<br>
As Chuck mentioned a few weeks ago, we do have a few outstanding
issues to address regarding LSIDs. I would like to discuss those one by
one, in an orderly manner, and reach consensus as much as we can. Then
we can sum them up in a TDWG standard, possibly by or shortly after the
Bratislava conference.<br>
<br>
The first issue I would like to discuss is <b>LSID metadata
persistence</b>. First, let me remind you of a corollary
established by the LSID specification:<br>
<br>
<b> Corollary 1: </b><u>LSIDs are not guaranteed to be
resolvable indefinitely.</u> <br>
<br>
In other words, there is no guarantee that one will always be able
to retrieve the
data associated with an LSID as the authority may choose (or be forced)
not to
resolve an LSID anymore. <br>
<br>
Second, let me distinguish this kind of persistence I'm talking
about from other two related concepts (which we'll not discuss in this
thread):<br>
<br>
1) <b>Persistence of Assignment: </b>Once assigned to an
object, an LSID is indefinitely associated with it. The same LSID
cannot be assigned to another object. Ever! The LSID may not be
resolvable anymore, but it cannot be assigned to another object. This
is established by the LSID specification.<br>
<br>
2) <b>Persistence of LSID Data: </b>The data associated with
an LSID (i.e, the byte stream returned by the LSID getData call) must
never change. Although the LSID may not be resolvable anymore
(according to corollary 1), the data associated with an LSID must never
ever change. That's defined by the LSID spec, too. <br>
<br>
What I want to discuss here is the <b>persistence of LSID metadata</b>
(what is returned by the getMetadata call) or the lack thereof.<br>
<br>
A use case associated with <b>metadata persistence</b> is when
someone
collects observation records (and implicitly, their determinations) and
runs an experiment (a model or simulation) with it. This person may
want to record the identifiers
of the points used so that someone using the results of that experiment
may refer back to the primary data, to validate or
repeat it the experiment.<br>
<br>
The bad news is that LSID identification scheme (or any other GUID
that
I know of) was not designed to guarantee <b>metadata persistence</b>,
and thus it cannot implement the use case above by itself. To implement
that use case, the specification would have to <b>guarantee</b> that
the metadata (which we are using here as data) is immutable. But it
doesn't.<br>
<br>
Most of us wish that metadata was persistent, but it isn't. Many
things can change in the metadata: a new determination, a mispeling
that is corrected, many things. We just cannot guarantee that the
metadata will look like it was sometime ago.<br>
<br>
We then reach the following conclusion.<br>
<br>
<b>Corollary 2: </b>LSIDs metadata is not immutable nor
persistent. <br>
<br>
The consequence of this corollary is that, if you need to refer
back to a piece of information (metadata) associated with an LSID,
exactly as it was when you got it, you <b>must make a copy of it</b>,
or arrange that someone else make that copy for you.<br>
<br>
In other words, a client cannot <b>assume</b> that the metadata
associated with an LSID today will be the same tomorrow. If the client
does assume that, it may be relying on a false assumption and its
output may be flawed.<br>
<br>
If we are not happy with that conclusion, we may develop an
additional component in our architecture, an archive of some sort, to
handle (meta)data persistence. That is exactly what the STD-DOI project
(<a class="moz-txt-link-freetext" href="http://www.std-doi.de/">http://www.std-doi.de/</a>) and SEEK (<a class="moz-txt-link-freetext" href="http://seek.ecoinformatics.org">http://seek.ecoinformatics.org</a>) have
done to some extent.<br>
<br>
While we cannot guarantee that LSID metadata is persistent nor
immutable, we can definitely document how the metadata have changed
through <b>metadata
</b><b>versioning</b>. That's the topic of the next thread. We
will move on to discuss <b>metadata
</b><b>versioning</b> as soon as we are done with <b>metadata
persistence</b>.<br>
<br>
Cheers,<br>
<br>
Ricardo<br>
<br>
</body>
</html>