October 2005 - tdwg-tag - lists.tdwg.org

Re: Topic 1: What do we mean by "GUID"?
by Kevin Richards 13 Oct '05

13 Oct '05

>>>From my computer-oriented viewpoint I consider a GUID in our discussion domain to be a an identifier (a character string that represents an object) that "points" to a particular record in a database or file on a computer. The idea is that the ID is globally unique - ie there is no other identifier in the world that is the same, but this is not easy to guarantee. I think the main aim here is to ensure it is unique within the domain for which it was intended (and a the main reason for using an existing GUID system such as ARK). I thnik my main point here is that the GUID must represent a digital object (eg database record) and cannot represent a physical object (ie you cannot transfer the physical object via the Internet). A record in a database may refer to a physical object, however the GUID will refer to the database record and the physical object will be "described" in the database record and referred to perhaps by a physical address/location. GUIDs should be assigned to any record/file/etc that will be served up to external users. I think the ARK article does cover most of the issues surrounding GUIDs, except implementation specific issues such as who the authorities should be and what form/granularity the data to be served up should be in. I still favour LSIDs where the resolution of an LSID works in well with the DNS system, and perhaps because they are actuially intended for the life sciences domain. The "problem definition" of the GUID as described below in Donald's email seems to sum up the requirements of a GUID to me. I'm not sure that "statements of commitment" are a job for the GUID itself, but they should be implied. Implied commitments for LSIDs include byte-identical data every time and infinite persistence of the data (a big ask I know). Kevin >>> dhobern(a)GBIF.ORG 12/10/2005 3:37 a.m. >>> [ I will be trying to provide some structure to discussions in this mailing list by raising specific topics and looking for comments. Please keep the Topic number in responses ] Topic 1: What do we mean by GUID? The most fundamental thing that we need to establish as we consider a GUID implementation is a definition for "GUID" in this context. We have been using a number of terms to describe the identifiers we need (unique, resolvable, persistent, etc.). I've been spending some time following up on Rod Page's recommendation that we consider the use of Archival Resource Keys (ARK) from the California Digital Library (see http://wiki.gbif.org/guidwiki/wikka.php?wakka=ARK). The CDL web site includes an excellent overview of this GUID model, which also serves as an excellent introduction to the issues involved. I would urge you all to read this document * it's only nine pages long!): http://www.cdlib.org/inside/diglib/ark/arkcdl.pdf This document arrives at the following problem definition for persistent, actionable identifiers: The goal: long-term actionable identifiers. Requirement: that identifiers deliver you to objects (where feasible). Requirement: that identifiers deliver you to object metadata. Desirable: each object should wear its own identifier. Requirement: that identifiers deliver you to statements of commitment. The problem: URLs break for some objects (that is, associations between URLs and objects are not maintained), and we have no way to tell which ones will or won't break. Why URLs break: because objects are moved, removed, and replaced * completely normal activities * and the provider in each case demonstrates insufficient commitment to update indirection tables, or to plan identifier assignment carefully. Persistence is in the mission of few organizations. Conventional hypothesis: use indirect names (PURLs, URNs, Handles) instead of URLs; what worked for DNS should work for digital object references. Wrong. Indirection is spectacularly successful and elegant in DNS, but it's a side issue in the provision of digital object persistence. This document clearly identifies issues around provider service commitments as the key problem that needs solving. The construction of ARKs seeks to address this in a couple of ways. It separates the role of Name Assigning Authority (i.e. who initially assigns the identifier) from that of the Name Mapping Authority (i.e. who is able to map the identifier to the data object at any particular time). It also defines a simple standard relationship between three things: the data object, the metadata for the object, and a commitment statement from the provider as to what aspects of persistence are guaranteed. ARK is a technology that we have not really considered up to this point. My question for discussion is what, if anything, is missing or wrong about the problem definition provided in this document? If we agree that it provides a crisp definition of what we need, that in itself will be a major step forward. Please provide your thoughts. Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 --------------------------------------------------------------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Topic 1: What do we mean by "GUID"?
by Patricia Mergen 12 Oct '05

12 Oct '05

--- Kevin Richards <RichardsK(a)LANDCARERESEARCH.CO.NZ> wrote: > From my computer-oriented viewpoint I consider a > GUID in our discussion domain to be a an identifier > (a character string that represents an object) that > "points" to a particular record in a database or > file on a computer. The idea is that the ID is > globally unique - ie there is no other identifier in > the world that is the same, but this is not easy to > guarantee. I think the main aim here is to ensure > it is unique within the domain for which it was > intended (and a the main reason for using an > existing GUID system such as ARK). > > I thnik my main point here is that the GUID must > represent a digital object (eg database record) and > cannot represent a physical object (ie you cannot > transfer the physical object via the Internet). A > record in a database may refer to a physical object, > however the GUID will refer to the database record > and the physical object will be "described" in the > database record and referred to perhaps by a > physical address/location. I tend to agree with this suggestion that the GUIDS should apply to the records served through the GBIF/TDWG network. The physical objects like for example the specimens in the institution have already their identifiers which are not GUIDS and serve for internal use mainly. Currently these identifiers are already used in DarwinCore or ABCD data served to GBIF to link to Physical objects or additional information available elsewhere. > > GUIDs should be assigned to any record/file/etc that > will be served up to external users. Could GBIF/TDWG in this context not play the role of a ticketting service serving "GUIDS" for the UNIT level data to the providers? For example if a provider wants to provide 2000 new records to GBIF, 2000 unique identifiers (like accession numbers) will be assigned to his 2000 records? The interlinking and localisation business could than be dealt with at an other level using the "description" of the record. Regards Pat > > I think the ARK article does cover most of the > issues surrounding GUIDs, except implementation > specific issues such as who the authorities should > be and what form/granularity the data to be served > up should be in. I still favour LSIDs where the > resolution of an LSID works in well with the DNS > system, and perhaps because they are actuially > intended for the life sciences domain. The "problem > definition" of the GUID as described below in > Donald's email seems to sum up the requirements of a > GUID to me. I'm not sure that "statements of > commitment" are a job for the GUID itself, but they > should be implied. Implied commitments for LSIDs > include byte-identical data every time and infinite > persistence of the data (a big ask I know). > > Kevin > > > >>> dhobern(a)GBIF.ORG 12/10/2005 3:37 a.m. >>> > > [ I will be trying to provide some structure to > discussions in this mailing list by raising specific > topics and looking for comments. Please keep the > Topic number in responses ] Topic 1: What do we mean > by GUID? The most fundamental thing that we need to > establish as we consider a GUID implementation is a > definition for "GUID" in this context. We have been > using a number of terms to describe the identifiers > we need (unique, resolvable, persistent, etc.). > I've been spending some time following up on Rod > Page's recommendation that we consider the use of > Archival Resource Keys (ARK) from the California > Digital Library (see > http://wiki.gbif.org/guidwiki/wikka.php?wakka=ARK). > The CDL web site includes an excellent overview of > this GUID model, which also serves as an excellent > introduction to the issues involved. I would urge > you all to read this document * it's only nine pages > long!): > http://www.cdlib.org/inside/diglib/ark/arkcdl.pdf > This document arrives at the following problem > definition for persistent, actionable identifiers: > The goal: long-term actionable identifiers. > Requirement: that identifiers deliver you to objects > (where feasible). Requirement: that identifiers > deliver you to object metadata. Desirable: each > object should wear its own identifier. Requirement: > that identifiers deliver you to statements of > commitment. The problem: URLs break for some objects > (that is, associations between URLs and objects are > not maintained), and we have no way to tell which > ones will or won't break. Why URLs break: because > objects are moved, removed, and replaced * > completely normal activities * and the provider in > each case demonstrates insufficient commitment to > update indirection tables, or to plan identifier > assignment carefully. Persistence is in the mission > of few organizations. Conventional hypothesis: use > indirect names (PURLs, URNs, Handles) instead of > URLs; what worked for DNS should work for digital > object references. Wrong. Indirection is > spectacularly successful and elegant in DNS, but > it's a side issue in the provision of digital object > persistence. This document clearly identifies > issues around provider service commitments as the > key problem that needs solving. The construction of > ARKs seeks to address this in a couple of ways. It > separates the role of Name Assigning Authority (i.e. > who initially assigns the identifier) from that of > the Name Mapping Authority (i.e. who is able to map > the identifier to the data object at any particular > time). It also defines a simple standard > relationship between three things: the data object, > the metadata for the object, and a commitment > statement from the provider as to what aspects of > persistence are guaranteed. ARK is a technology that > we have not really considered up to this point. My > question for discussion is what, if anything, is > missing or wrong about the problem definition > provided in this document? If we agree that it > provides a crisp definition of what we need, that in > itself will be a major step forward. Please provide > your thoughts. Donald > > --------------------------------------------------------------- > Donald Hobern (dhobern(a)gbif.org) > Programme Officer for Data Access and Database > Interoperability > Global Biodiversity Information Facility Secretariat > > Universitetsparken 15, DK-2100 Copenhagen, Denmark > Tel: +45-35321483 Mobile: +45-28751483 Fax: > +45-35321480 > --------------------------------------------------------------- > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

1 0

Re: What do we mean by GUID?
by Nozomi Ytow 12 Oct '05

12 Oct '05

Matt Jones wrote: > I think you may be taking a more literal definition of the word > 'identifier' than is often used. I don't think so. Our difference comes from scope of 'identity'. I prefer to use equivalence of data rather than identity of objects when we talking about proxy of data object. This distinction between equivalence and identity is essential to manage versioning (in philosophical term, time). > That they call the surrogate an 'identifier' does not imply that it is > equivalent to the whole tuple, only that it is a proxy or surrogate for > the tuple. I believe this is the sense in which we have been using the > term 'identifier' in these GUID discussions. Does it mean that key-by-key instead of bit-for-bit equivalence? It would be what is called as indiscernibilty in rough set theory. > By definition, the provider should have no capability to change the bits > behind an identifer -- this eliminates the persistence and replicability > properties. Any changes or corrections to the bits must be at least > accompanied by a version increment in the ID or we lose all of the > advantages of having the ID. The GUID (including version) is unnecessary to be issued until someone outside of the provider to access to the data. However, it clears what you meant by valid. I would say 'unique representation' instead of 'vlaid interpretation'. > I need the GUID because I should not have to download a 1GB > hyperspectral image to compare it against my own collection to see if I > already have it. If size is an issue, a (good) hash code would work as a contents proxy. > Yes, it is assigned to a data object. However, different applications > that I can conceive would want to use differently grained objects. Ah! It is why you said 'interpretation'. I don't think GUID is a practical idea if we require to assign it to different representations from the same set of data; here set impilies that the data object transferred to portal may be generated from multiple data objects in provider. It may be feasible if we restrict to limited number representations, i.e. ABCDC, TCS. > > It may be better to use other words such as globally disambiguateor > > or distinguisher, because we do not mean identity by identifier. > I think we do mean identity. The identifier is a label that can be used > as a handle to reference the object. Suppose you have two data objects having the same GUID. Their (key) contens may be identical (I'd like to say equivalent to avoid confusion), but they don't have the same identity. Talking identity of two or more objects is illogical. If there are two ore more, then they have different identity. If it is identity, then there is only one thing. I would say, if two data objects have the same GUID, they should be equivalent (or, key contents should be identical). 'Equlvalent' may imply 'interpretation' also. Cheers, James -- Dr. Nozomi "James" Ytow Institute of Biological Sciences / Gene research center University of Tsukuba Tsukuba, Ibaraki 305-8572 Japan

1 0

Re: What do we mean by GUID?
by Nozomi Ytow 12 Oct '05

12 Oct '05

Matt Jones wrote: > The term GUID is one we started using in SEEK when looking for a > solution to the identity and resolution problems that we saw looming for > the Taxonomic COncept Standard. Dave Thau's presentation on this > (linked on the GUID wiki) defines this pretty well and explores the issues. Here we see a tipical trouble with identifier and identity. Do you mean identity of an object (a unique thing, so we don't need identifier because it is the thing) or equivalence of data (there can be multiple data objects having the same value)? Where we need GUID we can't rely on identity, in my understanding. > "globally unique" means simply that an identifier that is issued can > only have one valid interpretation across all possible systems. What do you mean by valid? Suppose a data object in data provider's database. A GBIF portal has its copy when last a user accessed to the data object. The data provider changes its contents for some reason afther the last access through the GBIF portal. What is the valid interpretation of these data objects? Tha provider's one? > Regardless of the mechanism used to resolve the identifier, the object > that the id 'identifies' will be bit-for-bit identical. So you mean equivalence, not identity. If it is bit-for-bit equivalence, why do you need GUID? The contents IS the GUID you defined. > There are some tricky issues > dealing with granularity of the identifier for digital data (does the > identifier point at a tuple in an entity, or at a whole entity, or at > multiple entities). Do you mean your bit-for-bit GUID requires scope disamibugater also? Isn't it assigned to a data object, i.e. unit to be handled as a chunk? It may be better to use other words such as globally disambiguateor or distinguisher, because we do not mean identity by identifier. Cheers, James

1 0

Re: What do we mean by GUID?
by Peter Dawyndt 12 Oct '05

12 Oct '05

Dear Matt, > There are some tricky issues > dealing with granularity of the identifier for digital data (does the > identifier point at a tuple in an entity, or at a whole entity, or at > multiple entities). In addition you still have the very thorny issue of > what is data and what is metadata. I'll write another note regarding > this issue. the Object Model formulated by the Object Data Management Group (ODMG; /www.odmg.org) which is the "de facto" standard for object oriented design has formalized this issue with the separation between literals (entities carrying no identifier) and first class objects (entities carrying identity). A first class object is composed of other first class objects or literals, while literals themselves are atomic. How this granularity should be used for a particular application is completely application-dependent, eg. if a certain application requires that the instances of a given object (that were considered as literals before) should be individually identified, then they must be regarded as first class objects on their own. It is worth to delve into this formal standard, before making attempts to reinvent the wheel. Kind regards, Peter Further reading: Catell R. & Barry D. (1997). The Object Database Stanard: ODMG 2.0. Morgan Kaufmann Publishers

1 0

Re: Topic 1: What do we mean by "GUID"?
by Peter Dawyndt 12 Oct '05

12 Oct '05

----------------------------------------------------------- Dr. Peter Dawyndt Laboratorium voor Microbiologie Universiteit Gent Ledeganckstraat 35 B9000 Gent, Belgie Tel.: (32)9.264.51.32 Fax.: (32)9.264.50.92 Email: Peter.Dawyndt(a)UGent.be ----------------------------------------------------------- Dear Matt, > But nevertheless, > the LSID spec provides for both distributed and centralized authority > resolution, and so is a superset of the capabilities in DOI and ARK. DOI uses the Handle System technology (developed independently by CNRI), which in essence is nothing but an interface of a resolution service. DOI uses an implementation of the Handle System which already incorporates a federate scheme for identifier resolution. So, I think it is incorrect to state that DOI does not offer distributed authority resolution. Local resolution proxies are bound to resolve every DOI, also the ones that are outside of their registration scope. Cheers, Peter

1 0

Re: Topic 1: What do we mean by "GUID"?
by Roderic Page 12 Oct '05

12 Oct '05

I think this is a very nice statement of the issues. My own view is that ARK is interesting, but I'm not sure ARK is the best way forward. Persistence is a (perhaps the) key issue, and it is a social one not a technological one, as the DOI people make very clear. DOIs only work because the publishing industry has invested in the infrastructure to support them. In some ways, DOIs and ARK are very similar. If I use the DOI resolver to resolve a DOI http://dx.doi.org/10.1086/303303 \--------/ \-----/ \----/ | | | | Name Name Name mapping Assigning Authority Authority Number (NAAN) Hostport (NMAH) then I have a URL very like an ARK, where the authority assigning the name (such as a publisher, in this case the University of Chicago) is different from the authority makes the identifier actionable (doi.org). One could imagine that if DOI.org were to fall over, one could substitute another authority, such as doi.reborn.org. Indeed some publishers almost do essentially this, for example http://www.journals.uchicago.edu/cgi-bin/resolve?id=doi:10.1086/303303 (although this will only resolve local DOIs). ARK simply makes this possibility explicit. LSIDs are more strongly tied to the DNS (the uniqueness of an LSID is partly guaranteed by using Internet domain names), although they do have limited support for foreign authorities (other providers that can serve metadata for objects that those providers don't actually own). ARK also adds the ability to retrieve a statement of commitment. I'm less impressed by this, as a statement is all very well, but will service providers actually honour it? I guess this is an issue of trust. I suspect that user's rating of service providers will be much more accurate than a rating provided by a service provider. One issue not on this list is who generates GUIDs? ARKs and DOIs require some degree of centralisation because both require unique identifiers for organisations providing data (e.g., 10.10086 identifies the University of Chicago Press). This in itself requires some degree of service commitment. LSIDs are decentralised, in that the unique identifier for an organisation is provided by the DNS. If, for example, GBIF took on the role of providing unique identifiers for organisations, but then closed due to funding issues (heaven forbid), then we have a problem. If the DNS goes belly up, then we will have much more pressing issues to worry about... Regards Rod On 11 Oct 2005, at 15:37, Donald Hobern wrote: > > [ I will be trying to provide some structure to discussions in this > mailing list by raising specific topics and looking for comments. > Please keep the Topic number in responses ] > > Topic 1: What do we mean by GUID? > > The most fundamental thing that we need to establish as we consider a > GUID implementation is a definition for “GUID” in this context. We > have been using a number of terms to describe the identifiers we need > (unique, resolvable, persistent, etc.). > > I’ve been spending some time following up on Rod Page’s recommendation > that we consider the use of Archival Resource Keys (ARK) from the > California Digital Library (see > http://wiki.gbif.org/guidwiki/wikka.php?wakka=ARK). The CDL web site > includes an excellent overview of this GUID model, which also serves > as an excellent introduction to the issues involved. I would urge you > all to read this document – it’s only nine pages long!): > > http://www.cdlib.org/inside/diglib/ark/arkcdl.pdf > > This document arrives at the following problem definition for > persistent, actionable identifiers: > > 1 The goal: long-term actionable identifiers. > a Requirement: that identifiers deliver you to objects (where > feasible). > b Requirement: that identifiers deliver you to object metadata. > c Desirable: each object should wear its own identifier. > d Requirement: that identifiers deliver you to statements of > commitment. > 2 The problem: URLs break for some objects (that is, associations > between URLs and objects are not maintained), and we have no way to > tell which ones will or won’t break. > 3 Why URLs break: because objects are moved, removed, and replaced – > completely normal activities – and the provider in each case > demonstrates insufficient commitment to update indirection tables, or > to plan identifier assignment carefully. Persistence is in the mission > of few organizations. > 4 Conventional hypothesis: use indirect names (PURLs, URNs, Handles) > instead of URLs; what worked for DNS should work for digital object > references. Wrong. Indirection is spectacularly successful and > elegant in DNS, but it’s a side issue in the provision of digital > object persistence. > > This document clearly identifies issues around provider service > commitments as the key problem that needs solving. The construction > of ARKs seeks to address this in a couple of ways. It separates the > role of Name Assigning Authority (i.e. who initially assigns the > identifier) from that of the Name Mapping Authority (i.e. who is able > to map the identifier to the data object at any particular time). It > also defines a simple standard relationship between three things: the > data object, the metadata for the object, and a commitment statement > from the provider as to what aspects of persistence are guaranteed. > > ARK is a technology that we have not really considered up to this > point. My question for discussion is what, if anything, is missing or > wrong about the problem definition provided in this document? If we > agree that it provides a crisp definition of what we need, that in > itself will be a major step forward. > > Please provide your thoughts. > > Donald > > --------------------------------------------------------------- > Donald Hobern (dhobern(a)gbif.org) > Programme Officer for Data Access and Database Interoperability > Global Biodiversity Information Facility Secretariat > Universitetsparken 15, DK-2100 Copenhagen, Denmark > Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 > --------------------------------------------------------------- > > Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page(a)bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names at http://darwin.zoology.gla.ac.uk/~rpage/portal/

1 0

Re: What do we mean by GUID?
by Chuck Miller 12 Oct '05

12 Oct '05

I have been pondering this question of what exactly is meant by a GUID since Donald's first call for input. First, is it correct that GUID stands for Globally Unique Identifier? Second, What do we mean by Globally? What do we mean by Unique? What do we mean by Identifier? Or, specifically what are we identifying? I believe we are far from consensus on all three of those definitions, even the meaning of globally. And, I believe we will be going around in circles on LSIDs, ARNs, and such until we get the expectation more clearly defined. What I hear in most of the discussions so far are descriptions of a GLID - Globally Locatable IDentifier. In the Internet world, GLIDs started with the URL - Universal Resource Locator which has evolved to the URI - Universal Resource Identifier concept. Another form of URI is the URN - Uniform Resource Name which enables a persistent name, independent of server location. This is the kind of thing I think we want and are discussing in this GUID thread. I think we should draw a distinction between GUID and GLID. An identifier of a thing can be globally unique without stating its location. But, again, it raises the question of what the definition of unique is. An ISBN number identifies a book "uniquely", but there may be millions of "unique" copies of it. Similarly, duplicate sheets of a collected plant specimen are all from the same "unique" organism and may each even be referred to by the same "unique" collector and number. But, each sheet itself is also unique. We need a clear definition. An identifier of a place can also be globally unique, like a URL. But, being able to go to that place requires a global infrastructure to handle the addressing. Where it gets really messy is when we want an identifier of a thing that is unique but can move around to different places, like a URN. The addressing has to work like an administrative assistant who keeps tabs on where the staff is currently located so she can direct phone calls to them. Without the administrative assistant, people who move around can't be contacted. It looks like a lot of what LSID, ARN, and such seem to about is "administrative assistant" addressing schemes, how to navigate to the entity through layers of address abstraction. But, in each case it raises the issue of who/where is the administrative assistant, on top of the question of the addressing scheme itself. Shouldn't we get these definitions and expectations nailed down first? Then look at solutions? Chuck Miller Chief Information Officer Missouri Botanical Garden 4344 Shaw Boulevard Saint Louis, Missouri 63119 Phone: 1-314-577-9419 Cell: 1-314-614-6952

1 0

Re: Topic 1: What do we mean by "GUID"?
by Peter Dawyndt 12 Oct '05

12 Oct '05

Dear Patricia, I do not understand your point that the standards that were brought forward in this discussion group would make a distinction between "identification" and "localisation" as you call them. Even the most basic frameworks (like DNS,PURL,URI,URN) already make use of the principle redirection, which is the underlying technology to implement the resolution of the identifiers. More advanced digital identification frameworks (like DOI,LSID,ARK) offer designs of more extensive redirection schemes that granular resolution of objects, multiple resolution, persistence, context-dependent resolution, intellectual property, federated resolution. All of these merely can be considered as extensions on the basic principle of separation between the (preferably dumb) identifiers and its resolution (= localisation). Kind regards, Peter ----------------------------------------------------------- Dr. Peter Dawyndt Laboratorium voor Microbiologie Universiteit Gent Ledeganckstraat 35 B9000 Gent, Belgie Tel.: (32)9.264.51.32 Fax.: (32)9.264.50.92 Email: Peter.Dawyndt(a)UGent.be ----------------------------------------------------------- On Tue, 11 Oct 2005, Patricia Mergen wrote: > Dear Donald and colleagues from the GUID group > > Please find some comments here below > > There are two concepts which may be kept separated: > Identify an item (object or representations of the > object) which should be unique and stable which can be > understood as a GUID. > Localisation of an object or its representation which > may and often is not stable. > > Many of the tools and systems suggested so far often > mix up these two concepts and intend to identify and > localise at the same time. Problems than occur often > because localisation is not stable and apparently not > workable as a GUID. > > Maybe for solving the problem, we could try for > GBIF/TDWG to keep these two concepts separated and > look for a system which is most appropriate to > identify uniquely and in a stable way the unit level > data. This can be an Accession number with no meaning > like those used for Sequence data. > Localisation of the object can be dealt with as being > information about the object that can change in time > like any other. > > > Best regards > > Patricia Mergen > --- Donald Hobern <dhobern(a)GBIF.ORG> wrote: > >> [ I will be trying to provide some structure to >> discussions in this mailing >> list by raising specific topics and looking for >> comments. Please keep the >> Topic number in responses ] >> >> >> >> Topic 1: What do we mean by GUID? >> >> >> >> The most fundamental thing that we need to establish >> as we consider a GUID >> implementation is a definition for "GUID" in this >> context. We have been >> using a number of terms to describe the identifiers >> we need (unique, >> resolvable, persistent, etc.). >> >> >> >> I've been spending some time following up on Rod >> Page's recommendation that >> we consider the use of Archival Resource Keys (ARK) >> from the California >> Digital Library (see >> http://wiki.gbif.org/guidwiki/wikka.php?wakka=ARK). >> The CDL web site includes an excellent overview of >> this GUID model, which >> also serves as an excellent introduction to the >> issues involved. I would >> urge you all to read this document - it's only nine >> pages long!): >> >> >> >> http://www.cdlib.org/inside/diglib/ark/arkcdl.pdf >> >> >> >> This document arrives at the following problem >> definition for persistent, >> actionable identifiers: >> >> >> >> 1. The goal: long-term actionable identifiers. >> >> a. Requirement: that identifiers deliver you to >> objects (where >> feasible). >> b. Requirement: that identifiers deliver you to >> object metadata. >> c. Desirable: each object should wear its own >> identifier. >> d. Requirement: that identifiers deliver you to >> statements of >> commitment. >> >> 2. The problem: URLs break for some objects >> (that is, associations >> between URLs and objects are not maintained), and we >> have no way to tell >> which ones will or won't break. >> 3. Why URLs break: because objects are moved, >> removed, and replaced - >> completely normal activities - and the provider in >> each case demonstrates >> insufficient commitment to update indirection >> tables, or to plan identifier >> assignment carefully. Persistence is in the mission >> of few organizations. >> 4. Conventional hypothesis: use indirect names >> (PURLs, URNs, Handles) >> instead of URLs; what worked for DNS should work for >> digital object >> references. Wrong. Indirection is spectacularly >> successful and elegant in >> DNS, but it's a side issue in the provision of >> digital object persistence. >> >> >> >> This document clearly identifies issues around >> provider service commitments >> as the key problem that needs solving. The >> construction of ARKs seeks to >> address this in a couple of ways. It separates the >> role of Name Assigning >> Authority (i.e. who initially assigns the >> identifier) from that of the Name >> Mapping Authority (i.e. who is able to map the >> identifier to the data object >> at any particular time). It also defines a simple >> standard relationship >> between three things: the data object, the metadata >> for the object, and a >> commitment statement from the provider as to what >> aspects of persistence are >> guaranteed. >> >> >> >> ARK is a technology that we have not really >> considered up to this point. My >> question for discussion is what, if anything, is >> missing or wrong about the >> problem definition provided in this document? If we >> agree that it provides >> a crisp definition of what we need, that in itself >> will be a major step >> forward. >> >> >> >> Please provide your thoughts. >> >> >> >> Donald >> >> > --------------------------------------------------------------- >> Donald Hobern (dhobern(a)gbif.org) >> Programme Officer for Data Access and Database >> Interoperability >> Global Biodiversity Information Facility Secretariat >> Universitetsparken 15, DK-2100 Copenhagen, Denmark >> Tel: +45-35321483 Mobile: +45-28751483 Fax: >> +45-35321480 >> > --------------------------------------------------------------- >> >> >> >> > > > > > __________________________________ > Start your day with Yahoo! - Make it your home page! > http://www.yahoo.com/r/hs >

1 0

Re: What do we mean by GUID?
by Matt Jones 12 Oct '05

12 Oct '05

Nozomi Ytow wrote: > Matt Jones wrote: > > >>The term GUID is one we started using in SEEK when looking for a >>solution to the identity and resolution problems that we saw looming for >>the Taxonomic COncept Standard. Dave Thau's presentation on this >>(linked on the GUID wiki) defines this pretty well and explores the issues. > > > Here we see a tipical trouble with identifier and identity. Do you > mean identity of an object (a unique thing, so we don't need > identifier because it is the thing) or equivalence of data (there can > be multiple data objects having the same value)? Where we need GUID > we can't rely on identity, in my understanding. I think you may be taking a more literal definition of the word 'identifier' than is often used. For example, in an ER model people frequently use a numeric value as a surrogate for a compound primary key and call that numeric value the 'identifier'. What they mean is that the numeric value can be used as a proxy for the compund key values, and that either of these uniquely points to a single tuple in the entity. That they call the surrogate an 'identifier' does not imply that it is equivalent to the whole tuple, only that it is a proxy or surrogate for the tuple. I believe this is the sense in which we have been using the term 'identifier' in these GUID discussions. > > > >>"globally unique" means simply that an identifier that is issued can >>only have one valid interpretation across all possible systems. > > > What do you mean by valid? Suppose a data object in data provider's > database. A GBIF portal has its copy when last a user accessed to the > data object. The data provider changes its contents for some reason > afther the last access through the GBIF portal. What is the > valid interpretation of these data objects? Tha provider's one? By definition, the provider should have no capability to change the bits behind an identifer -- this eliminates the persistence and replicability properties. Any changes or corrections to the bits must be at least accompanied by a version increment in the ID or we lose all of the advantages of having the ID. > > >>Regardless of the mechanism used to resolve the identifier, the object >>that the id 'identifies' will be bit-for-bit identical. > > > So you mean equivalence, not identity. If it is bit-for-bit > equivalence, why do you need GUID? The contents IS the GUID > you defined. I need the GUID because I should not have to download a 1GB hyperspectral image to compare it against my own collection to see if I already have it. The GUID serves as a convenient handle or proxy for the content, which is very useful in many situations, not the least of which is collections management for digital data. > > > >>There are some tricky issues >>dealing with granularity of the identifier for digital data (does the >>identifier point at a tuple in an entity, or at a whole entity, or at >>multiple entities). > > > Do you mean your bit-for-bit GUID requires scope disamibugater also? > Isn't it assigned to a data object, i.e. unit to be handled as a > chunk? Yes, it is assigned to a data object. However, different applications that I can conceive would want to use differently grained objects. As Peter pointed out, the choice of what level you assign an identifier is application-dependent, and we have many applications in mind as far as I can see. So we have the conundrum -- which applications represent our use-cases for deciding the granularity at which we assign identifiers? Specimen-collection management applications? Ecological data management applications? Taxonomic name resolition? Time-series analysis of taxonomic observation data across worldwide sites? Species-prediction modeling based on specimen collection data? Species-prediction modeling based on ecological survey data? The list goes on and on, and each may have different application requirements for the granularity of the identifiers. > > > It may be better to use other words such as globally disambiguateor > or distinguisher, because we do not mean identity by identifier. I think we do mean identity. The identifier is a label that can be used as a handle to reference the object. Matt ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Matt Jones jones(a)nceas.ucsb.edu National Center for Ecological Analysis and Synthesis (NCEAS) UC Santa Barbara http://www.nceas.ucsb.edu/ecoinformatics ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

1 0