<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
 namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place" downloadurl="http://www.5iantlavalamp.com/"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";
        color:black;}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:blue;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-reply;
        font-family:Arial;
        color:navy;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body bgcolor=white lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Ricardo,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Looking at this definition: &#8220;</span></font><b><span
style='font-weight:bold'>Persistence of LSID Data: </span></b>The data associated
with an LSID (i.e, the <b><u><span style='font-weight:bold'>byte stream</span></u></b>
returned by the LSID getData call) must never change&#8221;<o:p></o:p></p>

<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Perhaps this is a more straightforward way
to conceive LSIDs.&nbsp; The LSID goes with a byte stream.&nbsp; It&#8217;s
that byte stream that must stay the same.&nbsp; So, if there is a byte stream
associated with a collection that needs to stay the same, then whatever that
byte stream happens to be is the data that gets an LSID assigned to it.&nbsp;
That sure seems a clearer definition of what is data and what is metadata,
rather than the issue of primary object and all that.&nbsp; <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>So we can create a new definition in the
context of LSIDs: Data is a byte stream that is persistent, never changes and
can have an LSID.&nbsp; Metadata is a byte stream is non-persistent, might
change and is only associated with an LSID.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The institution who assigns an LSID can
make their own decision about whether the byte stream being provided is
persistent or non-persistent.&nbsp; By assigning an LSID to any byte stream,
whatever it is, the institution is declaring it to be data and persistent.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>So, in the example given of an observation
record with a determination that needs to remain fixed and unchanged, by
assigning an LSID to that observation+determination it would be &#8220;declared
to be data&#8221; and unchangeable.&nbsp; A different determination would then
be different data with a different LSID. &nbsp;That would provide a solution
for those who want to employ it.&nbsp; Others could choose not to use it.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Chuck</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
color=black face="Times New Roman"><span style='font-size:12.0pt;color:windowtext'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 color=black face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight:bold'>From:</span></font></b><font
size=2 color=black face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma;
color:windowtext'> tdwg-guid-bounces@lists.tdwg.org
[mailto:tdwg-guid-bounces@lists.tdwg.org] <b><span style='font-weight:bold'>On
Behalf Of </span></b>Ricardo Pereira<br>
<b><span style='font-weight:bold'>Sent:</span></b> Friday, July 13, 2007 9:47
AM<br>
<b><span style='font-weight:bold'>To:</span></b> tdwg-guid@lists.tdwg.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> [tdwg-guid] LSID metadata
persistence (or lack thereof)</span></font><font color=black><span
style='color:windowtext'><o:p></o:p></span></font></p>

</div>

<p class=MsoNormal><font size=3 color=black face="Times New Roman"><span
style='font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3 color=black
face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;&nbsp;&nbsp; Hi
there folks,<br>
<br>
&nbsp;&nbsp;&nbsp; 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 <st1:City
w:st="on"><st1:place w:st="on">Bratislava</st1:place></st1:City> conference.<br>
<br>
&nbsp;&nbsp;&nbsp; The first issue I would like to discuss is <b><span
style='font-weight:bold'>LSID metadata persistence</span></b>. First, let me
remind you of a corollary established by the LSID specification:<br>
<br>
<b><span style='font-weight:bold'>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; Corollary 1: </span></b><u>LSIDs are not guaranteed to be
resolvable indefinitely.</u> <br>
<br>
&nbsp;&nbsp;&nbsp; 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&nbsp; to resolve an LSID anymore. <br>
<br>
&nbsp;&nbsp;&nbsp; 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>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 1) <b><span style='font-weight:bold'>Persistence
of Assignment: </span></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>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 2) <b><span style='font-weight:bold'>Persistence
of LSID Data: </span></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>
&nbsp;&nbsp;&nbsp; What I want to discuss here is the <b><span
style='font-weight:bold'>persistence of LSID metadata</span></b> (what is
returned by the getMetadata call) or the lack thereof.<br>
<br>
&nbsp;&nbsp;&nbsp; A use case associated with <b><span style='font-weight:bold'>metadata
persistence</span></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>
&nbsp;&nbsp;&nbsp; The bad news is that LSID identification scheme (or any
other GUID that I know of) was not designed to guarantee <b><span
style='font-weight:bold'>metadata persistence</span></b>, and thus it cannot
implement the use case above by itself. To implement that use case, the specification
would have to <b><span style='font-weight:bold'>guarantee</span></b> that the
metadata (which we are using here as data) is immutable. But it doesn't.<br>
<br>
&nbsp;&nbsp;&nbsp; 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>
&nbsp;&nbsp;&nbsp; We then reach the following conclusion.<br>
&nbsp;&nbsp; <br>
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; <b><span
style='font-weight:bold'>Corollary 2: </span></b>LSIDs metadata is not
immutable nor persistent. <br>
<br>
&nbsp;&nbsp;&nbsp; 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><span style='font-weight:bold'>must
make a copy of it</span></b>, or arrange that someone else make that copy for
you.<br>
<br>
&nbsp;&nbsp;&nbsp; In other words, a client cannot <b><span style='font-weight:
bold'>assume</span></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>
&nbsp;&nbsp;&nbsp; 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
href="http://www.std-doi.de/">http://www.std-doi.de/</a>) and SEEK (<a
href="http://seek.ecoinformatics.org">http://seek.ecoinformatics.org</a>) have
done to some extent.<br>
<br>
&nbsp;&nbsp;&nbsp; While we cannot guarantee that LSID metadata is persistent
nor immutable, we can definitely document how the metadata have changed through
<b><span style='font-weight:bold'>metadata versioning</span></b>. That's the
topic of the next thread. We will move on to discuss <b><span style='font-weight:
bold'>metadata versioning</span></b> as soon as we are done with <b><span
style='font-weight:bold'>metadata persistence</span></b>.<br>
<br>
&nbsp;&nbsp;&nbsp; Cheers,<br>
<br>
Ricardo<o:p></o:p></span></font></p>

</div>

</body>

</html>