I probably don't know what I'm talking about but ...

Kevin Richards RichardsK at LANDCARERESEARCH.CO.NZ
Mon Oct 17 17:26:11 CEST 2005


My thoughts...
 
First problem - any GUIDs currently in place that are not using the decided upon system will need to be "resolved"/"translated" from the existing system to the decided system and vice versa - just something that will need to be done for any data provider wishing to buy into the TDWG GUID system.
 
Second - one of the reasons I feel GUIDs should only really represent digital information and not real wolrd objects is exactly the problem described by Jerry.  It is quite difficult to determine if two digital objects are actually referring to the same real world object and hence very error prone (equivalence of objects is an application specific problem and shouldnt alter with the GUID mechanism).  Eg trying to work out if 2 digital representations of a person are referring to the same person has been a big problem for a long time.
 
Third - the relationship problem between different data objects is solved in the LSID world by the use of metadata - ie the LSID metadata for an object could describe the format the data object is served up in and the relationships to other LSIDs.  The idea with LSIDs is that the data returned for an LSID should only be the data for that object - any related objects are referred to in the metadata.  Ie the objects that an LSID refers to would need to be fairly low level, eg a Name Object from the TCS schema.  Higher level objects could be represented by LSIDs but it gets harder to maintain these and guarantee the 'bit for bit' consistency of a data object.
 
Kevin

>>> CooperJ at LANDCARERESEARCH.CO.NZ 17/10/2005 4:29 p.m. >>>

Hi all,
 
I don't really feel qualified to get involved but I have a number of issues that worry me. They are probably non-issues and result from my ignorance and lack of time to read the background info but I thought I'd chuck them into the debating pot anyway. Feel free to tell me to buzz-off and read some more...
 
First is that many of us are already using GUIDS to identify objects that have equivalents elsewhere and some of us are reluctant to give them up for good reason. So for example we have our name GUIDs in our names catalogue and IndexFungorum has its name GUIDs for the same name strings (same real world entity but differet 'bit for bit' digital representation). What we need is the ability to handle the fact that multiple digital object GUIDS may reference the same real-world entity and sometimes some of those 'duplicates' will need deprecating (but not loosing), and some 'synonyms' we will just have to live with, and resolve. Second is an issue touched on, and that is the 'bit equivalence' of the digital object being referenced. In many cases the real-world entities being referenced by different object GUIDs will be identical but their 'bit for bit' digital object representation may not, i.e. the need for a 'synonymy' of GUIDs may have a real-world basis. Third is a worry I have about the lack of definition of the scope of the entity being referenced. The more that is inlcuded in a particular scope the more need there is for versioning of digital objects representing the real-world entities, and the more likley will be 'bit for bit' discrepancies in the various extant digital objects represented by extant GUIDs. And then surely many (most) objects for which a GUID is required will be composed of sub-elements which may require their own GUIDs. How do you represent, and resolve a potential cascading chain of GUIDs where each GUID has the potential for many synonyms? . This just re-invents the 'taxon concept' problem in GUID-space and highlights the fact that nested layers of indirection do not actually solve the problem.
 
Jerry
 
Jerry Cooper PhD
Research Leader: Biodiversity Informatics
Landcare Research
PO Box 40, Lincoln 8152
New Zealand
+64 3 325 6701 ext 3734
CooperJ at LandcareResearch.CO.NZ
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++




++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++


--=__PartAC8EB1F3.0__Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Description: HTML

<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1515" name=GENERATOR></HEAD>
<BODY style="MARGIN: 4px 4px 1px; FONT: 10pt Tahoma">
<DIV>My thoughts...</DIV>
<DIV>&nbsp;</DIV>
<DIV>First problem - any GUIDs currently in place that are not using&nbsp;the decided upon system will need to be&nbsp;"resolved"/"translated" from the existing system to the decided system and vice versa - just something that will need to be done for any data provider wishing to buy into the TDWG GUID system.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Second - one of the reasons I feel GUIDs should only really represent digital information and not real wolrd objects is exactly the problem described by Jerry.&nbsp; It is quite difficult to determine if two digital objects are actually referring to the same real world object and hence very error prone (equivalence of objects is an application specific problem and shouldnt alter with the GUID mechanism).&nbsp; Eg trying to work out if 2 digital representations of a person are referring to the same person has been a big problem for a long time.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Third - the relationship problem between different data objects is solved in the LSID world by the use of metadata - ie the LSID metadata for an object could describe the format the data object is served up in and the relationships to other LSIDs.&nbsp; The idea with LSIDs is that the data returned for an LSID should only be the data for that object - any related objects are referred to in the metadata.&nbsp; Ie the objects that an LSID refers to would need to be fairly low level, eg a Name Object from the TCS schema.&nbsp; Higher level objects could be represented by LSIDs but it gets harder to maintain these and guarantee the 'bit for bit' consistency of a data object.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Kevin</DIV>
<DIV><BR>&gt;&gt;&gt; CooperJ at LANDCARERESEARCH.CO.NZ 17/10/2005 4:29 p.m. &gt;&gt;&gt;<BR></DIV>
<DIV style="FONT: 10pt Tahoma; COLOR: #000000">
<DIV>Hi all,</DIV>
<DIV>&nbsp;</DIV>
<DIV>I don't really feel qualified to get involved but I have a number of issues that worry me. They are probably non-issues and result from my&nbsp;ignorance and lack of time to read the background info but I thought I'd chuck them into the debating pot anyway. Feel free to tell me to buzz-off and read some more...</DIV>
<DIV>&nbsp;</DIV>
<DIV>First is that many of us are already using GUIDS to identify objects that have equivalents elsewhere and some of us are reluctant to give them up for good reason. So for example we have our name GUIDs in our names catalogue and IndexFungorum has its name GUIDs for the same name strings (same real world entity but differet 'bit for bit' digital representation). What we need is the ability to handle the fact that multiple digital object GUIDS may reference the same real-world entity and sometimes some&nbsp;of those 'duplicates' will need deprecating (but not loosing), and some 'synonyms' we will just have to&nbsp;live with, and resolve.&nbsp;Second is an issue touched on, and that is the 'bit equivalence' of the digital object being referenced. In many cases the real-world entities being referenced by different object GUIDs will be identical but their 'bit for bit' digital object representation may not, i.e. the need for a 'synonymy' of&nbsp;GUIDs may have a real-world basis.&nbsp;Third is a worry I have about the&nbsp;lack of definition of the scope of the&nbsp;entity being referenced. The more that is inlcuded in a particular scope the more need there is for versioning of&nbsp;digital objects representing the real-world entities,&nbsp;and the more likley will be 'bit for bit' discrepancies in the various extant digital objects represented by extant GUIDs. And then surely many (most)&nbsp;objects for which a GUID is required will be composed&nbsp;of sub-elements which may require their own GUIDs.&nbsp;How do you represent, and resolve a potential cascading chain of GUIDs where each GUID has the potential for many synonyms? . This just re-invents the 'taxon concept' problem in GUID-space and highlights the fact that nested layers of indirection do not actually solve the problem.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Jerry</DIV>
<DIV>&nbsp;</DIV>
<DIV>Jerry Cooper PhD<BR>Research Leader: Biodiversity Informatics<BR>Landcare Research<BR>PO Box 40, Lincoln 8152<BR>New Zealand<BR>+64 3 325 6701 ext 3734<BR><A href="mailto:CooperJ at LandcareResearch.CO.NZ">CooperJ at LandcareResearch.CO.NZ</A></DIV>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<BR>WARNING: This email and any attachments may be confidential and/or<BR>privileged. They are intended for the addressee only and are not to be read,<BR>used, copied or disseminated by anyone receiving them in error. If you are<BR>not the intended recipient, please notify the sender by return email and<BR>delete this message and any attachments.<BR><BR>The views expressed in this email are those of the sender and do not<BR>necessarily reflect the official views of Landcare Research. <BR><BR>Landcare Research<BR>http://www.landcareresearch.co.nz<BR>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<BR><BR></DIV></BODY></HTML>

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<BR>
WARNING: This email and any attachments may be confidential and/or<BR>
privileged. They are intended for the addressee only and are not to be read,<BR>
used, copied or disseminated by anyone receiving them in error.  If you are<BR>
not the intended recipient, please notify the sender by return email and<BR>
delete this message and any attachments.<BR>
<BR>
The views expressed in this email are those of the sender and do not<BR>
necessarily reflect the official views of Landcare Research.  <BR>
<BR>
Landcare Research<BR>
http://www.landcareresearch.co.nz<BR>
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++<BR>
<BR>
</BODY></HTML>


More information about the tdwg-tag mailing list