<HTML dir=ltr><HEAD><TITLE>Re: [tdwg-guid] LSID metadata persistence (or lack thereof)</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16481" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText60852 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Ricardo,</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2>I disagree on your assertion of consensus&nbsp;on a couple of points.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>On 2) there is no consensus/decision on whether XML can be returned from a getData call.&nbsp; I asked this question and it has not been answered.&nbsp; We could disallow XML as an allowed format for getData and allow it only for getMetadata.</FONT></DIV><FONT face=Arial size=2></FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT face=Arial size=2>We do not have consensus and actually have disagreement on "<FONT face="Times New Roman">We shouldn't for example return the bare scientific<BR>name of a species in the getData() call just because that can be immutable"&nbsp; <FONT face=Arial>because </FONT>"the name itself is in the metadata"&nbsp;&nbsp; </FONT><FONT face=Arial>I for one believe that we cannot avoid returning a scientific name byte stream in the getData for an LSID for a scientific name.&nbsp; That requirement is fundamental to what we need for biodiversity data.&nbsp; Pragmatically and empirically, names and specimens/observations are THE most fundamental data objects existing today in the databases published by GBIF.&nbsp; So if&nbsp;we&nbsp;can't&nbsp;put LSIDs on names, we have failed to enable&nbsp;one of the most fundamental needs of this community.&nbsp; If the definition of LSIDs needs to be amended to enable that, then so be it.&nbsp;</FONT></FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT size=2>Chuck</FONT></DIV>
<DIV dir=ltr>&nbsp;</DIV>
<DIV dir=ltr>
<DIV dir=ltr>
<HR tabIndex=-1>
</DIV>
<DIV dir=ltr><FONT face=Tahoma size=2><B>From:</B> tdwg-guid-bounces@lists.tdwg.org on behalf of Ricardo Pereira<BR><B>Sent:</B> Fri 7/13/2007 8:12 PM<BR><B>Cc:</B> tdwg-guid@lists.tdwg.org<BR><B>Subject:</B> Re: [tdwg-guid] LSID metadata persistence (or lack thereof)<BR></FONT><BR></DIV></DIV>
<DIV>
<P><FONT size=2>&nbsp;&nbsp;&nbsp; Folks,<BR><BR>&nbsp;&nbsp;&nbsp; Thanks much to all of you who replied to my post. All the posts were<BR>really relevant to our discussion.<BR><BR>&nbsp;&nbsp;&nbsp; Before we go ahead, however, let us stop for a minute to try and<BR>summarize the points we agree upon and the points in which there is<BR>still significant controversy.<BR><BR>&nbsp;&nbsp;&nbsp; I believe that we reached consensus in the following issues:<BR><BR>1) We do agree that *LSID metadata is not required to be persistent*<BR>(i.e. clients cannot assume it is immutable). See note [1].<BR><BR>2) We should not force XML representations of data to be byte identical<BR>just to return that in the LSID getData() call. We must find another way<BR>to fulfill this requirement.<BR><BR>3) We should not try to return something in the LSID getData() call just<BR>for the sake of it. We shouldn't for example return the bare scientific<BR>name of a species in the getData() call just because that can be<BR>immutable and thus fulfill the requirement from the LSID spec. This is<BR>counterproductive because the name itself is in the metadata already and<BR>no client would gain anything from calling getData() in this case.<BR><BR><BR>&nbsp;&nbsp;&nbsp; We have also raised new issues that may be worth discussing (in<BR>their own separate thread if possible):<BR><BR>4) We "may" bend the immutability rule of LSID getData() to our benefit<BR>and accept data that is not byte stream identical, but only<BR>"semantically" identical (depending on content type maybe). If we do<BR>this, we may use the LSID getData() call more effectively to identify<BR>real datasets such as matrices, identification keys, etc.<BR><BR>5) As Brian pointed out, we may need to revisit what we call data and<BR>metadata. We have been using the LSID getMetadata() call to return what<BR>some people may call data (taxon names, specimens, collections). And we<BR>forgot completely that there may be other kinds of data out there that<BR>may be returned in the getData() call and that those still need metadata<BR>to describe them. I think this may be worth discussing in a separate thread.<BR><BR>&nbsp;&nbsp;&nbsp; Did I leave anything out? If so, please let us know by replying to<BR>my post and adding a short entry to either list above.<BR><BR>&nbsp;&nbsp;&nbsp; Cheers,<BR><BR>Ricardo<BR><BR><BR><BR>Notes:<BR>-------<BR><BR>[1] Matt may disagree with me here, but my point is that we can't force<BR>all authorities (i.e. data providers) to keep perfect archives of all<BR>versions of their databases given a heterogeneous and distributed<BR>environment we operate in. While some may want to provide this feature,<BR>other providers may not want or be able to.<BR><BR><BR>Richard Pyle wrote:<BR>&gt; It seems to me that there is a third method to resolving the problem:&nbsp;<BR>&gt;<BR>&gt; When we want to identify an object that is itself digital in nature (e.g., a<BR>&gt; database record, or a binary data file such as a PDF, JPG, ASCII, Unicode,<BR>&gt; or whatever), we resolve said binary object via getData().&nbsp; If, for some<BR>&gt; reason, we change the exact bit-sequence of that digital/binary object<BR>&gt; (e.g., color-correct an image, change a text string from ASII to Unicode, or<BR>&gt; whatever...), we assign a new LSID to it (whether that "new" LSID differs<BR>&gt; from the "old" LSID only via the optional "Revision" part of the LSID, or<BR>&gt; via a new Object Identification part, is a topic for another debate).<BR>&gt;<BR>&gt; When we want to identify an object that does not itself have a digital<BR>&gt; manifestation -- like a physical object (e.g., specimen or a particular<BR>&gt; printed copy of a publication) or an abstract/conceptual object (e.g., a<BR>&gt; taxon name, a taxon concept, a geographica place, or a cited publication) --<BR>&gt; then we return *nothing* in response to getData(), and we treat all the<BR>&gt; attributes of said physical/abstract/conceptual object of interest to us as<BR>&gt; metadata.<BR>&gt;<BR>&gt; If there are cases where certain metadata elements of an object without an<BR>&gt; inherent digital existence need to persists (and there are), yet we also<BR>&gt; want to allow modifications to metadata elements without the need to<BR>&gt; generate new identifiers for the underlying object (and we do) -- then we<BR>&gt; deal with those within our own community via adopted standards and best<BR>&gt; practices.<BR>&gt;<BR>&gt; I would disagree strongly with bending the existing LSID standard, and would<BR>&gt; just as strongly favor working within its existing framework (which, I<BR>&gt; think, we can).&nbsp; I would also disagree with the practice of embedding XML<BR>&gt; documents as "data" for an LSID, unless the LSID is intended to represent<BR>&gt; the XML document itself (in which case there might be a different LSID to<BR>&gt; represent the database record that was used to generate the XML document;<BR>&gt; and yet another LSID to represent the abstract concept that the database<BR>&gt; record was created to represent -- like a taxon name, for example).<BR>&gt;<BR>&gt; If we want to use LSIDs to pass around XML packages (that are not rendered<BR>&gt; as RDF) about abstract objects (e.g., taxon names), why doesn't our<BR>&gt; community define within our semantic vocabulary something along the lines of<BR>&gt; "TCS_XML", which can be established as a standard metadata component for<BR>&gt; LSIDs assigned to taxon concepts (i.e., abstract objects, identified by<BR>&gt; "data-less" LSIDs).&nbsp; The exact bytestream of the content of that metadata<BR>&gt; element can change, without changing its canonical rendering.<BR>&gt;<BR>&gt; I'm beginning to suspect (strongly) that I am completely missing some<BR>&gt; fundamental point here -- and perhaps is is the same point that underlies<BR>&gt; the apparent antagonism towards LSIDs in general (which I do not yet share).<BR>&gt; But I am fairly certain we are dealing with some level of miscommunication<BR>&gt; here.<BR>&gt;<BR>&gt; Aloha,<BR>&gt; Rich<BR>&gt;<BR>&gt;&nbsp;&nbsp;<BR>&gt;&gt; -----Original Message-----<BR>&gt;&gt; From: tdwg-guid-bounces@lists.tdwg.org<BR>&gt;&gt; [<A href="mailto:tdwg-guid-bounces@lists.tdwg.org">mailto:tdwg-guid-bounces@lists.tdwg.org</A>] On Behalf Of P.<BR>&gt;&gt; Bryan Heidorn<BR>&gt;&gt; Sent: Friday, July 13, 2007 12:48 PM<BR>&gt;&gt; To: Dave Vieglais<BR>&gt;&gt; Cc: tdwg-guid@lists.tdwg.org<BR>&gt;&gt; Subject: Re: [tdwg-guid] LSID metadata persistence (or lack<BR>&gt;&gt; thereof)[Scanned]<BR>&gt;&gt;<BR>&gt;&gt; There seems to be two methods to resolving this problem.<BR>&gt;&gt;<BR>&gt;&gt; One is to change the LSID definitions to allow semantic<BR>&gt;&gt; equivalence in the data and not require exact bit stream equivalence.<BR>&gt;&gt;<BR>&gt;&gt; The other option is to change the data representation so that<BR>&gt;&gt; it is "easily" reduced to a repeatable canonical form. For<BR>&gt;&gt; example, it is almost as easy as saying where XML ordering<BR>&gt;&gt; does not specify order of elements, elements will be ordered<BR>&gt;&gt; alphabetically. Seems stupid but it almost works.. except<BR>&gt;&gt; where you have repeating elements with the same element name<BR>&gt;&gt; where it does not work.<BR>&gt;&gt;<BR>&gt;&gt; It seems a little odd to bend the standards for the data<BR>&gt;&gt; being delivered to fit the requirement of the LSID spec. In<BR>&gt;&gt; theory, the other standard developers who set the data being<BR>&gt;&gt; delivered did not fix order because it did not matter.<BR>&gt;&gt;<BR>&gt;&gt; This is different from Chuck's observation that the semantics<BR>&gt;&gt; of the element within some of the standards are<BR>&gt;&gt; insufficiently specified.&nbsp;<BR>&gt;&gt; So, what we mean is a darwin mode species name is just a<BR>&gt;&gt; string and nothing more now.<BR>&gt;&gt;<BR>&gt;&gt;<BR>&gt;&gt; --Bryan<BR>&gt;&gt;<BR>&gt;&gt; On Jul 13, 2007, at 5:18 PM, Dave Vieglais wrote:<BR>&gt;&gt;<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; I think we are all in agreement that the data and metadata<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; referenced<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; by an LSID remains unchanged (in the case of the metadata, semantic<BR>&gt;&gt;&gt; equivalence is a requirement for reasons such as outlined<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; by Matt).&nbsp;<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; My question is to do purely with the data that an LSID references<BR>&gt;&gt;&gt; through the getData() operation.&nbsp; The form of that data could be<BR>&gt;&gt;&gt; anything really - an encrypted byte stream, digital image,<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; Open Office<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; document, spreadsheet, xml document...<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; We all know that the same data can be represented many ways<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; that are<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; logically, semantically and functionally equivalent yet form a<BR>&gt;&gt;&gt; different set of bytes when serialized.&nbsp; Data expressed in<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; XML is one<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; example (is &lt;a/&gt; = &lt;a /&gt; = &lt;a&gt;&lt;/a&gt; ?).&nbsp; A pallet based image is<BR>&gt;&gt;&gt; another - the order of colors in the palette may be<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; changed, and the<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; pixel values adjusted to match the new palette order, but<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; the image is<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; still the same. There are many more simple examples that can be<BR>&gt;&gt;&gt; constructed that violate the unchanged bytes rule but for all<BR>&gt;&gt;&gt; practical and functional purposes the data are unchanged.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; As mentioned previously, enforcing and implementing the unchanged<BR>&gt;&gt;&gt; bytes rule is not challenging. It is however quite different from<BR>&gt;&gt;&gt; stating that the data are returned unchanged.&nbsp; It is this<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; that I, and<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; I'm sure a lot of other implementors would appreciate consensus on.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; Dave V.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; On Jul 14, 2007, at 09:20, Matthew Jones wrote:<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; In terms of the metadata returned from an LSID, or any<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; other digital<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; identifier, there are definite cases where metadata must be<BR>&gt;&gt;&gt;&gt; semantically persistent in order to preserve the utility<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; of data and<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; accuracy of scientific results.<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; As a trivial example, given a set of observations<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; collected at time<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; t, one can represent the data for those observations in<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; dataset D and<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; the metadata for the dataset, including the time value t, in a<BR>&gt;&gt;&gt;&gt; metadata document M.&nbsp; In a later event, it is discovered<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; that t was<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; entered incorrectly, and needs to be adjusted, creating metadata<BR>&gt;&gt;&gt;&gt; document M'. That M and M' are not congruent is critical knowledge<BR>&gt;&gt;&gt;&gt; when analyzing data from D with data from another dataset D2.&nbsp; In<BR>&gt;&gt;&gt;&gt; other words, because there is no true distinction between data and<BR>&gt;&gt;&gt;&gt; metadata (any given piece of information can be stored in either<BR>&gt;&gt;&gt;&gt; location), a proper archive must be able to distinguish<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; any changes<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; in the data and any changes in the metadata.<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; That said, there are some metadata that could change with<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; little or<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; no impact on data interpretation (e.g., the spelling of<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; the street on<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; which Technician Tom gets his snailmail).&nbsp; But at the current time<BR>&gt;&gt;&gt;&gt; its impossible to distinguish this kind of metadata from the<BR>&gt;&gt;&gt;&gt; important kind in the general case of the existing<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; metadata standards<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; in use (e.g., FGDC BDP, ISO 19115, EML, GML, etc).<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; Our process in the KNB/SEEK/NCEAS and other ecological<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; data archives<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; is to give persistent identifiers to both data objects and<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; metadata<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt; objects, and provide new identifiers when either changes.<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; Matt<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; Dave Vieglais wrote:<BR>&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; Hi Bob,<BR>&gt;&gt;&gt;&gt;&gt; Just because a standard is published does not mean that it is<BR>&gt;&gt;&gt;&gt;&gt; practical.&nbsp; Requiring that a set of bytes referenced by<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; an LSID are<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; unchanged has a lot of implications with respect to the<BR>&gt;&gt;&gt;&gt;&gt; implementation of data services.&nbsp; For example, if it is agreed to<BR>&gt;&gt;&gt;&gt;&gt; abide by the rule that the blob referenced by an LSID remains<BR>&gt;&gt;&gt;&gt;&gt; forever unchanged, then that implies that the data<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; provider stores<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; the data as a blob, rather than risking the process of<BR>&gt;&gt;&gt;&gt;&gt; reconstructing on the fly from some database, especially for the<BR>&gt;&gt;&gt;&gt;&gt; example of data expressed in XML where functionally identical<BR>&gt;&gt;&gt;&gt;&gt; objects (constructed using different DOM libraries for<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; example) are<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; not identical blobs.<BR>&gt;&gt;&gt;&gt;&gt; Asserting that two instances of an object with the same LSID are<BR>&gt;&gt;&gt;&gt;&gt; semantically equivalent is a vastly more complicated<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; processes than<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; asserting that the canonical representation of those<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; instances are<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; identical.&nbsp; Generally there can be defined a simple set of<BR>&gt;&gt;&gt;&gt;&gt; guidelines for constructing the canonical form of an<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; object (eg. for<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; xml <A href="">http:www.w3.org/TR/xml-c14n</A> ) whereas asserting semantic<BR>&gt;&gt;&gt;&gt;&gt; equivalence is an ongoing topic of research.<BR>&gt;&gt;&gt;&gt;&gt; Requiring identical blobs is certainly possible, but<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; people need to<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; be aware of the implications of such a requirement in the early<BR>&gt;&gt;&gt;&gt;&gt; stages of designing a system to support such a specification.&nbsp; My<BR>&gt;&gt;&gt;&gt;&gt; preference for the canonical form relaxes the implementation<BR>&gt;&gt;&gt;&gt;&gt; requirements considerably whilst still maintaining the<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; integrity of<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; the data and the intent of the LSID.<BR>&gt;&gt;&gt;&gt;&gt; regards,<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp; Dave V.<BR>&gt;&gt;&gt;&gt;&gt; On Jul 14, 2007, at 08:08, Bob Morris wrote:<BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; This entire discussion confuses me. The LSID standard is<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; published.<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; Why is there a discussion of what an LSID should be? The<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; standard<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; requires that the data, as defined by the return of<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; getData,&nbsp; to be<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; identical for all resolutions of the LSID. From page 9<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; of the LSID<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; spec:<BR>&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt; " bytes getData (LSID lsid)<BR>&gt;&gt;&gt;&gt;&gt;&gt; bytes getDataByRange (LSID lsid, integer start, integer length)<BR>&gt;&gt;&gt;&gt;&gt;&gt; Metadata_response getMetadata (LSID lsid, string[]<BR>&gt;&gt;&gt;&gt;&gt;&gt; accepted_formats)<BR>&gt;&gt;&gt;&gt;&gt;&gt; Metadata_response getMetadataSubset (LSID lsid, string[]<BR>&gt;&gt;&gt;&gt;&gt;&gt; accepted_formats, string selector) The data retrieval<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; services may<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; implement all of the methods, or only methods for<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; retrieving data,<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; or only methods for retrieving associated metadata.<BR>&gt;&gt;&gt;&gt;&gt;&gt; The same LSID named data object must be resolved always<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; to the same<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; set of bytes. Therefore, all of the data retrieval<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; services return<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; the same results for the same LSID. The user has, however, the<BR>&gt;&gt;&gt;&gt;&gt;&gt; choice of which one of these to utilize depending on its<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; location,<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; known quality of service and other attributes. With<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; metadata, the<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; situation is different. Each data retrieval service can provide<BR>&gt;&gt;&gt;&gt;&gt;&gt; different metadata for the same LSID."<BR>&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt; This doesn't seem very ambiguous to me, and doesn't have<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; anything<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; to do with imperfect storage of data or anything else about the<BR>&gt;&gt;&gt;&gt;&gt;&gt; physical or electronic world. If two calls to getData() with the<BR>&gt;&gt;&gt;&gt;&gt;&gt; same argument on two occasions to possibly two different<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; resolution<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; services do not yield the same set of bytes, then one or<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; the other<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; or both of those is not executing a compliant service response.<BR>&gt;&gt;&gt;&gt;&gt;&gt; Unless this discussion is really "Shall we call something other<BR>&gt;&gt;&gt;&gt;&gt;&gt; than the return of getData by the term 'data associated with the<BR>&gt;&gt;&gt;&gt;&gt;&gt; LSID?' there seems to be nothing to discuss.<BR>&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt; Bob<BR>&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt; On 7/13/07, Paul Kirk &lt;p.kirk@cabi.org&gt; wrote:<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; In an imperfect world there is no such thing as an 'identical-<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; byte-stream'<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; because the technology we use is imperfect ... the disk<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; controllers which manage our bytes and the disk we use to store<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; our bytes have recognized error rates. Perhaps I'm<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; being a pedant<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; in the above analysis but I was almost persuaded that<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; except for<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; digital objects (images,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; sounds) which can<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; be data all other 'things' (names, specimen accession<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; numbers) had<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; to be metadata. This to me makes no sense in the real but<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; imperfect world we live in. An LSID assigned to a name<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; (e.g. Homo<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; sapiens) is assigned to the name as data, not metadata. What is<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; 'identical' here it that if the spelling has to change for any<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; reason the new spelling gets a new LSID and the now incorrect<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; spelling gets deprecated (but is still resolvable) with<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; a pointer<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; to the correct spelling/LSID in the metadata.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; OK?<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Paul<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp; ________________________________<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp; From: tdwg-guid-bounces@lists.tdwg.org on behalf of<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; Chuck Miller<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Sent: Fri 13/07/2007 19:03<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; To: Dave Vieglais<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Cc: tdwg-guid@lists.tdwg.org<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Subject: RE: [tdwg-guid] LSID metadata persistence (or lack<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; thereof)[Scanned]<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Dave,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; What you say is true.&nbsp; But, I think we already have too many<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; variations, subtleties, and reinterpretations which are<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; endlessly<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; debated.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; The LSID standard would be simple, clear and consistent<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; if we used<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; the identical-byte-stream definition.&nbsp; The LSID would<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; uniquely tag<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; a persistent byte stream. A persistent byte stream is<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; always the<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; same thing without any further explanation or clarification.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; The provider of an LSID byte-stream would need to commit to<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; keeping that byte-stream persistent and not represent it in<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; multiple ways, even though technically they could.&nbsp; If<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; they can't<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; commit to that, then it can't be an LSID byte-stream.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; And in the name of simplicity and clarity, if they had<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; to provide<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; different byte-stream representations then they would have to<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; assign a different LSID to each and use "SameAs" metadata.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Chuck<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; -----Original Message-----<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; From: Dave Vieglais [<A href="mailto:vieglais@ku.edu">mailto:vieglais@ku.edu</A>]<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Sent: Friday, July 13, 2007 12:42 PM<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; To: Chuck Miller<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Cc: Ricardo Pereira; tdwg-guid@lists.tdwg.org<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Subject: Re: [tdwg-guid] LSID metadata persistence (or lack<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; thereof)<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Hi Ricardo, Chuck,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Asserting that the byte stream returned as data<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; associated with an<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; LSID should never change is perhaps a bit confusing from a<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; programmatic view.&nbsp; There are for example many ways to<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; represent<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; data in xml that are identical from an information<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; content point<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; of view, but the byte streams could be very different.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Perhaps it might be better to state something like "the<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; canonical<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; representation of the data associated with an LSID must not<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; change", or something to that effect?<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Dave V.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; On Jul 14, 2007, at 05:29, Chuck Miller wrote:<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Ricardo,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Looking at this definition: "Persistence of LSID<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; Data: The data<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; associated with an LSID (i.e, the byte stream returned by the<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; LSID<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; getData call) must never change"<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Perhaps this is a more straightforward way to conceive<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; LSIDs.&nbsp; The<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; LSID goes with a byte stream.&nbsp; It's that byte stream that<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; must stay<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the same.&nbsp; So, if there is a byte stream associated with a<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; collection that needs to stay the same, then whatever<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; that byte<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; stream happens to be is the data that gets an LSID assigned<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; to it.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; That sure seems a clearer definition of what is data<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; and what is<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; metadata, rather than the issue of primary object and<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; all that.<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; So we can create a new definition in the context of LSIDs:&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Data is<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; a byte stream that is persistent, never changes and<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; can have an<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; LSID.&nbsp; Metadata is a byte stream is non-persistent,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; might change<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; and is only associated with an LSID.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; The institution who assigns an LSID can make their<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; own decision<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; about whether the byte stream being provided is persistent or<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; non-<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; persistent.&nbsp; By assigning an LSID to any byte stream,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; whatever it<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; is, the institution is declaring it to be data and persistent.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; So, in the example given of an observation record with a<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; determination that needs to remain fixed and unchanged, by<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; assigning an LSID to that observation+determination<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; it would be<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; "declared to be data" and unchangeable.&nbsp; A different<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; determination<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; would then be different data with a different LSID.&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; That would<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; provide a solution for those who want to employ it.&nbsp; Others<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; could<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; choose not to use it.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Chuck<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; From: tdwg-guid-bounces@lists.tdwg.org [<A href="mailto:tdwg-guid-">mailto:tdwg-guid-</A><BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; bounces@lists.tdwg.org] On Behalf Of Ricardo Pereira<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Sent: Friday, July 13, 2007 9:47 AM<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; To: tdwg-guid@lists.tdwg.org<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Subject: [tdwg-guid] LSID metadata persistence (or<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; lack thereof)<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Hi there folks,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; As Chuck mentioned a few weeks ago, we do have a few<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; outstanding issues to address regarding LSIDs. I<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; would like to<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; discuss those one by one, in an orderly manner, and reach<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; consensus<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; as much as we can. Then we can sum them up in a TDWG<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; standard,<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; possibly by or shortly after the Bratislava conference.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; The first issue I would like to discuss is LSID metadata<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; persistence. First, let me remind you of a corollary<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; established by<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; the LSID specification:<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Corollary 1: LSIDs are not guaranteed to be<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; resolvable<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; indefinitely.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; In other words, there is no guarantee that one will<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; always be<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; able to retrieve the data associated with an LSID as the<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; authority<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; may choose (or be forced) not&nbsp; to resolve an LSID anymore.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Second, let me distinguish this kind of persistence I'm<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; talking<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; about from other two related concepts (which we'll not<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; discuss in<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; this thread):<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1) Persistence of Assignment: Once assigned to an<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; object,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; an LSID is indefinitely associated with it. The same LSID<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; cannot be<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; assigned to another object. Ever! The LSID may not be<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; resolvable<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; anymore, but it cannot be assigned to another object. This is<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; established by the LSID specification.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2) Persistence of LSID Data: The data<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; associated with an<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; LSID (i.e, the byte stream returned by the LSID getData call)<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; must<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; never change. Although the LSID may not be resolvable anymore<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; (according to corollary 1), the data associated with an LSID<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; must<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; never ever change. That's defined by the LSID spec, too.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; What I want to discuss here is the persistence of LSID<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; metadata<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; (what is returned by the getMetadata call) or the<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; lack thereof.<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; A use case associated with metadata persistence is when<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; someone<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; collects observation records (and implicitly, their<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; determinations)<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; and runs an experiment (a model or simulation) with it. This<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; person<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; may want to record the identifiers of the points used so that<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; someone using the results of that experiment may refer back<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; to the<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; primary data, to validate or repeat it the experiment.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; The bad news is that LSID identification scheme (or any<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; other<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; GUID that I know of) was not designed to guarantee metadata<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; persistence, and thus it cannot implement the use<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; case above by<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; itself. To implement that use case, the specification would<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; have to<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; guarantee that the metadata (which we are using here<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; as data) is<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; immutable. But it doesn't.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Most of us wish that metadata was persistent, but<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; it isn't.<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Many things can change in the metadata: a new<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; determination, a<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; mispeling that is corrected, many things. We just cannot<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; guarantee<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; that the metadata will look like it was sometime ago.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; We then reach the following conclusion.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Corollary 2: LSIDs metadata is not immutable nor<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; persistent.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; The consequence of this corollary is that, if you need to<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; refer<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; back to a piece of information (metadata) associated with an<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; LSID,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; exactly as it was when you got it, you must make a copy of<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; it, or<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; arrange that someone else make that copy for you.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; In other words, a client cannot assume that the metadata<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; associated with an LSID today will be the same<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; tomorrow. If the<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; client does assume that, it may be relying on a false<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; assumption<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; and its output may be flawed.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; If we are not happy with that conclusion, we may<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; develop an<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; additional component in our architecture, an archive of some<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; sort,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; to handle (meta)data persistence. That is exactly what the<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; STD-DOI<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; project (<A href="http://www.std-doi.de/">http://www.std-doi.de/</A>) and SEEK (<A href="http:///">http://</A><BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; seek.ecoinformatics.org) have done to some extent.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; While we cannot guarantee that LSID metadata is<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; persistent nor<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; immutable, we can definitely document how the metadata have<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; changed<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; through metadata versioning. That's the topic of the next<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; thread.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; We will move on to discuss metadata versioning as<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; soon as we are<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; done with metadata persistence.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp; Cheers,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; Ricardo<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; tdwg-guid mailing list<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; tdwg-guid@lists.tdwg.org<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt; <A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; tdwg-guid mailing list<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; tdwg-guid@lists.tdwg.org<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; <A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; P Think Green - don't print this email unless you really need to<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; ******************************************************************<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; ******<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp; The information contained in this e-mail and any files<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; transmitted with it is confidential and is for the<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; exclusive use<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; of the intended recipient. If you are not the intended<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; recipient<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; please note that any distribution, copying or use of this<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; communication or the information in it is prohibited.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp; Whilst CAB International trading as CABI takes steps<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; to prevent<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; the transmission of viruses via e-mail, we cannot<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; guarantee that<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; any e-mail or attachment is free from computer viruses<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; and you are<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; strongly advised to undertake your own anti-virus precautions.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp; If you have received this communication in error,<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; please notify<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; us by e-mail at cabi@cabi.org or by telephone on +44 (0)1491<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; 829199 and then delete the e-mail and any copies of it.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp; CABI is an International Organization recognised by the UK<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; Government under Statutory Instrument 1982 No. 1071.<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; ******************************************************************<BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; ********<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; tdwg-guid mailing list<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; tdwg-guid@lists.tdwg.org<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt; <A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt;&gt; --Robert A. Morris<BR>&gt;&gt;&gt;&gt;&gt;&gt; Professor of Computer Science<BR>&gt;&gt;&gt;&gt;&gt;&gt; UMASS-Boston<BR>&gt;&gt;&gt;&gt;&gt;&gt; ram@cs.umb.edu<BR>&gt;&gt;&gt;&gt;&gt;&gt; <A href="http://bdei.cs.umb.edu/">http://bdei.cs.umb.edu/</A><BR>&gt;&gt;&gt;&gt;&gt;&gt; <A href="http://www.cs.umb.edu/~ram">http://www.cs.umb.edu/~ram</A><BR>&gt;&gt;&gt;&gt;&gt;&gt; <A href="http://www.cs.umb.edu/~ram/calendar.html">http://www.cs.umb.edu/~ram/calendar.html</A><BR>&gt;&gt;&gt;&gt;&gt;&gt; phone (+1)617 287 6466<BR>&gt;&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt;&gt;&gt; tdwg-guid mailing list<BR>&gt;&gt;&gt;&gt;&gt; tdwg-guid@lists.tdwg.org<BR>&gt;&gt;&gt;&gt;&gt; <A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR>&gt;&gt;&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt; tdwg-guid mailing list<BR>&gt;&gt;&gt; tdwg-guid@lists.tdwg.org<BR>&gt;&gt;&gt; <A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR>&gt;&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;&gt; _______________________________________________<BR>&gt;&gt; tdwg-guid mailing list<BR>&gt;&gt; tdwg-guid@lists.tdwg.org<BR>&gt;&gt; <A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR>&gt;&gt;&nbsp;&nbsp;&nbsp;&nbsp;<BR>&gt;<BR>&gt;<BR>&gt; _______________________________________________<BR>&gt; tdwg-guid mailing list<BR>&gt; tdwg-guid@lists.tdwg.org<BR>&gt; <A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR>&gt;<BR>&gt;&nbsp;&nbsp;<BR><BR>_______________________________________________<BR>tdwg-guid mailing list<BR>tdwg-guid@lists.tdwg.org<BR><A href="http://lists.tdwg.org/mailman/listinfo/tdwg-guid">http://lists.tdwg.org/mailman/listinfo/tdwg-guid</A><BR></FONT></P></DIV></BODY></HTML>