January 2006 - tdwg-tag - lists.tdwg.org

Re: identifiers for geologic samples
by Roderic Page 31 Jan '06

31 Jan '06

Well at the moment the "switchboard" for handles is the Corporation for National Research Initiatives (http://www.cnri.reston.va.us/) And they don't need to maintain maps for millions of GUIDs, all the need is maps for the authorities. When I set up a handle server here in Glasgow (OK, ""here" is now the Millenium Hotel in Durham, where I'm sampling a Red Oak), I was assigned handle 2254, which implies there are only a couple of thousand authorities (probably less less). I'm responsible for mapping all the GUIDs for this handle (e.g., ensuring that http://hdl.handle.net/2254/20971 resolves to an actual resource). For a local provider, essentially all you need to provide is a mapping between your local identifiers and the handles, and the most direct one is to use primary keys (e.g., TROPICOS numbers for taxonomic names). Regards Rod On 31 Jan 2006, at 22:33, Chuck Miller wrote: > Rod, > Great points. I agree with you. > > I just think the dilemma lies in the desire to make GUIDs locatable. > I think the Handle system presumes that somewhere a "switchboard" is > being maintained that maps the handles to a URL. Who has the funds > and resources to serve up this switchboard and most importantly > maintain it for millions of GUIDs? If those resources are available, > then using a centralized redirection system like Handle avoids the > complications you describe. But, without those central administrative > resources, then institutions will map their own GUIDs and to my mind > the simplest and most doable way to do that is just using a URL-based > approach, similar to LSID. It's a compromise to get things moving. > > Chuck > > -----Original Message----- > From: Roderic Page > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Sent: 2006/01/30 12:50 > Subject: Re: [TDWG-GUID] identifiers for geologic samples > > Dear Chuck, > > Nobody that I'm aware of is suggesting replacing the DNS (least of all > me). Any solution that gets implement anytime soon will of course use > the Internet. Handles use the Internet in their current implementation, > > indeed anytime you look up a DOI, or follow a link in a journal that's > marked "CrossRef", you use handles. > > It's just that: > > (a) I'm a little wary of including Internet addresses in GUIDs, more > because the implied link to a site may disappear if the site > dies/moves/changes name. Yes there are mechanisms to deal with this, > but having an Internet address has the potential to mislead. Imagine if > > records served by MOBOT start to get served by, say, the New York > Botanical Garden. What will users think of resolving an LSID with > mobot.org in the name and getting a different server. A generation > brought up with phishing scams (http://en.wikipedia.org/wiki/Phishing) > > and taught to check a URL is really what it says it is might get > nervous. > > (b) I'm not seriously arguing the DNS or the Internet are going away > anytime soon, however I think it is interesting that this is a concern > voiced by the people who are probably closest to us in mindset - > digital librarians. They care deeply about curation, have rare, old, > culturally valuable artefacts, and want systems that persist beyond > current fashions and/or technologies. Sound familiar? If so, let's ask > why have they gone for things like handles? > > Regards > > Rod > > On 28 Jan 2006, at 14:25, Chuck Miller wrote: > > > Although the Internet may change in the future and none of us have a > > crystal ball, some method for turning names (gbif.org) into network > > addresses (192.38.28.79) will be required. For the forseeable future > > > that method on the Internet will almost certainly be DNS. The cascade > > > of the global DNS server network is key to making the Internet work. > > > No matter what URL you put into your browser, the DNS network finds > > its way to the IP address of the server. Trillions of dollars of > > commerce now depend upon this global standard. I think the analogy is > > > more like the teletype machines and the ASCII codes they used. > > Although we have Unicode now, it still includes ASCII. In > > communications, the new must continue to support the old. This can > be > > > seen in the W3C projects that continue to build upon the previous > > standards. > > > > To replace the Internet's global DNS locator service with something > > unique to biodiversity seems like a complex, expensive and long-term > > proposition. For the sake of getting things done in a timely manner, > > > I think we need to keep things simple and leverage the pieces of the > > puzzle that already work. Implementing a GUID scheme is going to be > > tough enough without tackling a replacement for DNS. > > > > An issue that needs to be decided by the workshop is how much > > "abstraction" of a GUID is absolutely necessry if it must also be > > locatable through the Internet? That is, is a compromise needed to > > allow embedding of domain names in order to enable use of the DNS to > > locate GUIDs. Surely there is insufficient time, funds, and staff to > > > embark upon creation of a master switchboard (database) where the > > locations of millions of GUIDs are recorded and updated in > perpetuity. > > > > Chuck Miller > > Missouri Botanical Garden > > > > > > -----Original Message----- > > From: Roderic Page > > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > > Sent: 1/28/2006 2:58 AM > > Subject: Re: [TDWG-GUID] identifiers for geologic samples > > > > On 28 Jan 2006, at 01:02, Richard Pyle wrote: > > > > > The more I think about it, the more I think this is the sort of > > system > > > that > > > would work well for our field. A centralized issuer (which could > > issue > > > blocks of thousands or millions of numbers at a time), > > > > The major problem I see with this is that a central registry may be a > > rate limiting step because it has to allocate blocks, it would also > > decide for format of the last part of the identifier (which the > > provider might not find desirable), and it may well lead to lots of > > wasted identifiers (e.g., it allocates 100,000 to me, but I use 3 off > > them). > > > > Would it not be better to devolve this? You can still have a central > > registry. For example, Handles and DOIs work by having a central > > registry for the prefix (e.g., "1018") and the provider is > responsible > > for allocating the suffix locally. > > > > > > > I'm not sure how wise it would be to create a new syntax standard, > > > rather > > > than go with one of the ones we've discussed. But if (for example) > > > using > > > LSID, I personally think it would be preferable to establish a > highly > > > generic form, such as: > > > > > > urn:lsid:gbif.org:BioGUID:12345 > > > > Without wishing to preempt some of the things I'm going to present at > > the workshop, I'm going off LSIDs a little because of their reliance > on > > the Internet DNS. Apart from the hassle of mucking with the DNS > records > > to set them up (I suspect not every provider is going to find this > easy > > to do), it assumes that the Internet its present form is going to be > > here forever, and it also embeds information in the identifier (e.g., > > "gbif.org") that currently has meaning, but over time may loose > > meaning, or worse, be positively misleading (say if GBIF goes belly > up > > and somebody else serves the data). > > > > Handles (including DOIs) and ARK have no information in the > identifier > > (perhaps not strictly true for some DOIs, but that's by choice not > > design), and also in principle don't need the internet. In the future > > some other mode of information transport may come along, and they > could > > still be used. > > > > While it might be hard to imagine the Internet and the DNS going > away, > > if anybody has a 5 1/4" floppy lying around, they'll be aware of how > > hard it is to get information off it these days as 5 1/4" drives are > > scarce as hens teeth -- the only one in my department is in an old PC > > that is connected to the network. The digital library community seem > > particularly sensitive to these issues, which is perhaps why they use > > handles, DOIs, and ARK. > > > > Regards > > > > Rod > > > > > > > > > ----------------------------------------------------------------------- > > - > > ---------------------------------------- > > 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/ > > Find out what we know about a species at http://ispecies.org > > > > > > > > > > > > > > ___________________________________________________________ > > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with > > voicemail http://uk.messenger.yahoo.com > > > ----------------------------------------------------------------------- > - > > ---------------------------------------- > 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/ > Find out what we know about a species at http://ispecies.org > ------------------------------------------------------------------------ ---------------------------------------- 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/ Find out what we know about a species at http://ispecies.org

1 0

Re: Combined response
by Richard Pyle 31 Jan '06

31 Jan '06

Bob Morris wrote: > > I agree that it might, but I don't think it necessarily has to. Again, I > > point to IP addresses and DNS. They are obviously harmonized, but aren't > > locked up in administrative layers (or are they???) > > Yes, they are, big time. Both have a hierarchy of organizational > administrative control ending at IANA, the Internet Assigned Numbers > Authority, http://www.iana.org/. If an individual proposes to put a machine > onto the internet, they receive permission, an IP address, and a dns name from > the appropriate local authority managing the network to which they will > physically connect. Often that permission and issuance is done by software > on a network host on that network (usually a DHCP, dynamic host control > protocol, server. In turn, the network administrators will have received > permissions from the next administration up the chain to issue a specific > block of IP addresses, or specific form of names. I think the active phrase is "locked up". My point is that the system works -- right? Or does it only "work" because the en-users are so well insulated from the administrative process? Would IP work more effectively if it wasn't harmonized on a global scale, in a centralized sort of way? Rich

1 0

Re: LSID & resolution discovery service (was: identifiers for geologic samples)
by Bob Morris 31 Jan '06

31 Jan '06

I've expanded my arguments a little at http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSID --Bob On 1/31/06, Ricardo Scachetti Pereira <ricardo(a)tdwg.org> wrote: > > Bob and all, > > I wanted to discuss this characteristic of LSIDs that Bob brought up > in a recent post. > > Bob Morris wrote: > > > >From my understanding of the LSID spec, LSIDs do not rely on the DNS. > > Rather one particular mechanism for discovering resolution services > > depends on the DNS, and nothing in the LSID specification requires the > > use of that mechanism, convenient as it presently may be. Future > > resolution service discovery mechanisms can use the existing LSID as > > they please provided only they meet the specification of a resolution > > service discovery service. > > Now I'm intrigued. I was aware of the fact that the LSID spec left > open the implementation of the resolution discovery service, but I > wasn't aware of the implications. > > So, if there are more than one resolution discovery service in use > (say, the DNS-based one and some other proprietary ones) and if clients > are not aware of them all (they can't, discovery mechanism is left open > by the spec), there may be situations in which a client can have a > perfectly valid LSID but cannot get to the identified object. In other > words, although LSIDs are guaranteed to be globally unique, it does not > guaranteed that a client that possesses a LSID and no information about > it can retrieve data and metadata across different implementation of the > resolution discovery service. > > I'm surprised with this because all other technologies (ARK, Handle > System and DOI) are designed so resolutions is global as well. All the > other technologies consider resolution discovery as part of regular > resolution. > > If you read it again, the LSID spec acknowledges this situation in > the following paragraph: > > "The LSID Resolution Discovery service has only one method that takes > any LSID and returns a list of LSID Resolution > services that are responsible for the given LSID. The method may raise > an exception if it fails to find an appropriate LSID > Resolution service for the given LSID. This may occur particularly when > the authority identification field of the LSID is > less standardized (which may occur for local services known only to a > limited number of clients)." > > Does that property of LSID brings any implications for our group? > > Cheers, > > Ricardo > > > > > > Also, LSIDs are required by the spec to be semantically opaque. > > Though, this has some exceptions, and semantic opacity is narrowly > > defined, I would say that except for resolution service discovery > > services---and such services that use DNS are narrowly constrained by > > the spec---, those applications that ascribe meaning to parts of an > > LSID are probably guilty of violating the spec and perhaps don't > > deserve that much sympathy. > > > > cf Section 8 and Section 13.3 of > http://www.omg.org/docs/dtc/04-05-01.pdf > > > > I hope that those who argue against LSIDs on either of the above two > > grounds will place in the wiki (or point me to where it already is) > > how I am misreading the spec.If I am reading it correctly, I don't > > understand how the arguments Rod puts forth here would lead to > > rejection of LSID whatever other disadvantages it may have compared to > > alternatives. > > > > This is a familiar sounding point and maybe somebody answered me the > > last time I whined about it, long ago in a mailing list far, far away. > > My apologies if so. > > > > Bob Morris >

1 0

Re: identifiers for geologic samples
by Chuck Miller 31 Jan '06

31 Jan '06

Rod, Great points. I agree with you. I just think the dilemma lies in the desire to make GUIDs locatable. I think the Handle system presumes that somewhere a "switchboard" is being maintained that maps the handles to a URL. Who has the funds and resources to serve up this switchboard and most importantly maintain it for millions of GUIDs? If those resources are available, then using a centralized redirection system like Handle avoids the complications you describe. But, without those central administrative resources, then institutions will map their own GUIDs and to my mind the simplest and most doable way to do that is just using a URL-based approach, similar to LSID. It's a compromise to get things moving. Chuck -----Original Message----- From: Roderic Page To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Sent: 2006/01/30 12:50 Subject: Re: [TDWG-GUID] identifiers for geologic samples Dear Chuck, Nobody that I'm aware of is suggesting replacing the DNS (least of all me). Any solution that gets implement anytime soon will of course use the Internet. Handles use the Internet in their current implementation, indeed anytime you look up a DOI, or follow a link in a journal that's marked "CrossRef", you use handles. It's just that: (a) I'm a little wary of including Internet addresses in GUIDs, more because the implied link to a site may disappear if the site dies/moves/changes name. Yes there are mechanisms to deal with this, but having an Internet address has the potential to mislead. Imagine if records served by MOBOT start to get served by, say, the New York Botanical Garden. What will users think of resolving an LSID with mobot.org in the name and getting a different server. A generation brought up with phishing scams (http://en.wikipedia.org/wiki/Phishing) and taught to check a URL is really what it says it is might get nervous. (b) I'm not seriously arguing the DNS or the Internet are going away anytime soon, however I think it is interesting that this is a concern voiced by the people who are probably closest to us in mindset - digital librarians. They care deeply about curation, have rare, old, culturally valuable artefacts, and want systems that persist beyond current fashions and/or technologies. Sound familiar? If so, let's ask why have they gone for things like handles? Regards Rod On 28 Jan 2006, at 14:25, Chuck Miller wrote: > Although the Internet may change in the future and none of us have a > crystal ball, some method for turning names (gbif.org) into network > addresses (192.38.28.79) will be required. For the forseeable future > that method on the Internet will almost certainly be DNS. The cascade > of the global DNS server network is key to making the Internet work. > No matter what URL you put into your browser, the DNS network finds > its way to the IP address of the server. Trillions of dollars of > commerce now depend upon this global standard. I think the analogy is > more like the teletype machines and the ASCII codes they used. > Although we have Unicode now, it still includes ASCII. In > communications, the new must continue to support the old. This can be > seen in the W3C projects that continue to build upon the previous > standards. > > To replace the Internet's global DNS locator service with something > unique to biodiversity seems like a complex, expensive and long-term > proposition. For the sake of getting things done in a timely manner, > I think we need to keep things simple and leverage the pieces of the > puzzle that already work. Implementing a GUID scheme is going to be > tough enough without tackling a replacement for DNS. > > An issue that needs to be decided by the workshop is how much > "abstraction" of a GUID is absolutely necessry if it must also be > locatable through the Internet? That is, is a compromise needed to > allow embedding of domain names in order to enable use of the DNS to > locate GUIDs. Surely there is insufficient time, funds, and staff to > embark upon creation of a master switchboard (database) where the > locations of millions of GUIDs are recorded and updated in perpetuity. > > Chuck Miller > Missouri Botanical Garden > > > -----Original Message----- > From: Roderic Page > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Sent: 1/28/2006 2:58 AM > Subject: Re: [TDWG-GUID] identifiers for geologic samples > > On 28 Jan 2006, at 01:02, Richard Pyle wrote: > > > The more I think about it, the more I think this is the sort of > system > > that > > would work well for our field. A centralized issuer (which could > issue > > blocks of thousands or millions of numbers at a time), > > The major problem I see with this is that a central registry may be a > rate limiting step because it has to allocate blocks, it would also > decide for format of the last part of the identifier (which the > provider might not find desirable), and it may well lead to lots of > wasted identifiers (e.g., it allocates 100,000 to me, but I use 3 off > them). > > Would it not be better to devolve this? You can still have a central > registry. For example, Handles and DOIs work by having a central > registry for the prefix (e.g., "1018") and the provider is responsible > for allocating the suffix locally. > > > > I'm not sure how wise it would be to create a new syntax standard, > > rather > > than go with one of the ones we've discussed. But if (for example) > > using > > LSID, I personally think it would be preferable to establish a highly > > generic form, such as: > > > > urn:lsid:gbif.org:BioGUID:12345 > > Without wishing to preempt some of the things I'm going to present at > the workshop, I'm going off LSIDs a little because of their reliance on > the Internet DNS. Apart from the hassle of mucking with the DNS records > to set them up (I suspect not every provider is going to find this easy > to do), it assumes that the Internet its present form is going to be > here forever, and it also embeds information in the identifier (e.g., > "gbif.org") that currently has meaning, but over time may loose > meaning, or worse, be positively misleading (say if GBIF goes belly up > and somebody else serves the data). > > Handles (including DOIs) and ARK have no information in the identifier > (perhaps not strictly true for some DOIs, but that's by choice not > design), and also in principle don't need the internet. In the future > some other mode of information transport may come along, and they could > still be used. > > While it might be hard to imagine the Internet and the DNS going away, > if anybody has a 5 1/4" floppy lying around, they'll be aware of how > hard it is to get information off it these days as 5 1/4" drives are > scarce as hens teeth -- the only one in my department is in an old PC > that is connected to the network. The digital library community seem > particularly sensitive to these issues, which is perhaps why they use > handles, DOIs, and ARK. > > Regards > > Rod > > > > ----------------------------------------------------------------------- > - > ---------------------------------------- > 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/ > Find out what we know about a species at http://ispecies.org > > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with > voicemail http://uk.messenger.yahoo.com > ------------------------------------------------------------------------ ---------------------------------------- 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/ Find out what we know about a species at http://ispecies.org

1 0

Re: How GUIDs will be used
by Kevin Richards 31 Jan '06

31 Jan '06

I would say definitely a case for metadata - as GUIDs should be opaque and persistent - indicating relationships as part of the GUID itself would not be opaque at all. Best in the metadata - and if we use rdf then a relationship like 'derivedFrom'(?) Kevin >>> tdwg(a)ACHAPMAN.ORG 01/31/06 12:19 PM >>> It would appear to me that we need something built into the Metadata of the GUID to link objects that are essentially the same (but in fact always slightly different) Example: Chapman 541 is a collecting event off one tree with duplicate specimens sent to Kew and Canberra. If each gets a GUID and we are going to use GUIDs to identify the 'synonymy' of collection then the only way would be for guid1234 be the collecting event and guid1234-1, guid1234-2 or something similar would indicate that they were (in way) children of the collecting event guid1234. There is always need to identify the Kew collection and the Canberra collection separately for a whole number of reasons, but there is also a need to identify them as the same collecting event. The second way of doing it is to design a strict metadata standard that is attached to the GUID (a TDWG task I guess). One key (repeatable) field in that metadata would then be along the lines of "related_guids" and "relationship_type". We would of couse then need to come up with an ontology of relationship types. Using the metadata may be the cleanest (and in the long run easiest and most practical) way of handling the relationship between guids. It also allows for the later creation of a new guid related to the first where, for example, genetic material, pollen samples, etc. may be taken from one of the specimens. It is also a simple way of linking the offspring of an object, etc. Good luck with the meeting - I look forward to the outcomes. Cheers Arthur Chapman Australian Biodiversity Information Services Toowoomba, Australia >>>From Roderic Page <r.page(a)BIO.GLA.AC.UK> on 30 Jan 2006: > > > > We need to decide under which circumstances we want this to be a > > bidirectional implication, i.e. that: > > > > B) O1 == O2 --> I1 == I2 > > > > My 30 second reaction to this is that it assumes that the metadata > attached to I1 and I2 are the same, which may often not be the case. > For example, a paper may have several GUIDs attached to it, it is in > some sense the same object, but PubMed offers different metadata to > CrossRef (links to sequences, MeSH keywords, etc., versus strictly > bibliographic data), which is different to Google Scholar (links to > papers that cite the work), different to handles in DSpace repositories > (GUID for a freely available copy), and so on. > > Can we not, at least initially, have a mapping between GUIDs, and then > if somebody wants to take on the task of generating single GUIDs for a > set of related GUIDs, then they can undertake that? I suspect that, > realistically, such an undertaking would only be feasible (and indeed, > useful) if we first have GUIDs for the existing databases in place. > > Yes, a plethora of ids can be a pain (just look at the situation in > bioinformatics) -- that said, the abundance of identifiers in > bioinformatics reflects the desire of people to add value to existing > databases. > > So long as we can infer that I1 and I2 are both talking about O1, why > force I1==I2, when metadata(I1) and metadata(I2) may be different, and > both have value. > > I think we need to separate two goals: having unique, resolvable > identifiers for existing objects, and sorting out the issue of > multiple, possibly conflicting identifiers and metadata for the "same" > object. One is easier, one is harder, but I think the hard one needs > the easy one to be solved first. > > But then I'm probably simply being both naive and impatient, which is > not a good combination. > > Regards > > Rod > > ------------------------------------------------------------------------ > ---------------------------------------- > 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/ > Find out what we know about a species at http://ispecies.org > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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

LSID & resolution discovery service (was: identifiers for geologic samples)
by Ricardo Scachetti Pereira 31 Jan '06

31 Jan '06

Bob and all, I wanted to discuss this characteristic of LSIDs that Bob brought up in a recent post. Bob Morris wrote: > >From my understanding of the LSID spec, LSIDs do not rely on the DNS. > Rather one particular mechanism for discovering resolution services > depends on the DNS, and nothing in the LSID specification requires the > use of that mechanism, convenient as it presently may be. Future > resolution service discovery mechanisms can use the existing LSID as > they please provided only they meet the specification of a resolution > service discovery service. Now I'm intrigued. I was aware of the fact that the LSID spec left open the implementation of the resolution discovery service, but I wasn't aware of the implications. So, if there are more than one resolution discovery service in use (say, the DNS-based one and some other proprietary ones) and if clients are not aware of them all (they can't, discovery mechanism is left open by the spec), there may be situations in which a client can have a perfectly valid LSID but cannot get to the identified object. In other words, although LSIDs are guaranteed to be globally unique, it does not guaranteed that a client that possesses a LSID and no information about it can retrieve data and metadata across different implementation of the resolution discovery service. I'm surprised with this because all other technologies (ARK, Handle System and DOI) are designed so resolutions is global as well. All the other technologies consider resolution discovery as part of regular resolution. If you read it again, the LSID spec acknowledges this situation in the following paragraph: "The LSID Resolution Discovery service has only one method that takes any LSID and returns a list of LSID Resolution services that are responsible for the given LSID. The method may raise an exception if it fails to find an appropriate LSID Resolution service for the given LSID. This may occur particularly when the authority identification field of the LSID is less standardized (which may occur for local services known only to a limited number of clients)." Does that property of LSID brings any implications for our group? Cheers, Ricardo > > Also, LSIDs are required by the spec to be semantically opaque. > Though, this has some exceptions, and semantic opacity is narrowly > defined, I would say that except for resolution service discovery > services---and such services that use DNS are narrowly constrained by > the spec---, those applications that ascribe meaning to parts of an > LSID are probably guilty of violating the spec and perhaps don't > deserve that much sympathy. > > cf Section 8 and Section 13.3 of http://www.omg.org/docs/dtc/04-05-01.pdf > > I hope that those who argue against LSIDs on either of the above two > grounds will place in the wiki (or point me to where it already is) > how I am misreading the spec.If I am reading it correctly, I don't > understand how the arguments Rod puts forth here would lead to > rejection of LSID whatever other disadvantages it may have compared to > alternatives. > > This is a familiar sounding point and maybe somebody answered me the > last time I whined about it, long ago in a mailing list far, far away. > My apologies if so. > > Bob Morris

1 0

Re: Combined response
by Bob Morris 31 Jan '06

31 Jan '06

On 1/30/06, Richard Pyle <deepreef(a)bishopmuseum.org> wrote: > > Rod Page wrote: > > > The issue of centralisation and "taxonomic freedom" is a red herring > > (due to Rich and I talking past each other -- my fault). > > I share the blame. > > > My concern > > (and I know I'm doing a very poor job of explaining this) is that > > administrative layers and attempting to harmonise things centrally may > > ultimately prove to get in the way of getting things done. > > I agree that it might, but I don't think it necessarily has to. Again, I > point to IP addresses and DNS. They are obviously harmonized, but aren't > locked up in administrative layers (or are they???) Yes, they are, big time. Both have a hierarchy of organizational administrative control ending at IANA, the Internet Assigned Numbers Authority, http://www.iana.org/. If an individual proposes to put a machine onto the internet, they receive permission, an IP address, and a dns name from the appropriate local authority managing the network to which they will physically connect. Often that permission and issuance is done by software on a network host on that network (usually a DHCP, dynamic host control protocol, server. In turn, the network administrators will have received permissions from the next administration up the chain to issue a specific block of IP addresses, or specific form of names. IANA is under attack right now by a movement of governments led by the International Telecommunications Union which wants to centralize, by country, control of the mechanisms that are sketched above. There is a lesson here though. It is that most end-user beneficiaries of this complex arrangement find it needs nothing whatsoever on their part to get those benefits. That is probably a requirement of any good GUID issuance and resolution services also. (But it is not about GUID capabilities, rather about their support). >

1 0

Phishing
by Roderic Page 30 Jan '06

30 Jan '06

Shot myself in the foot. Of course, handles, DOIs, and LSIDs all end up being resolved to a URL other than the identifier the user typed in, so arguably the phishing analogy is bogus -- although at least with a handle or DOI there is no prior expectation of what the URL should be (which may or may not be a good thing). Must engage brain before typing... Regards Rod ------------------------------------------------------------------------ ---------------------------------------- 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/ Find out what we know about a species at http://ispecies.org

1 0

Re: identifiers for geologic samples
by Roderic Page 30 Jan '06

30 Jan '06

Dear Chuck, Nobody that I'm aware of is suggesting replacing the DNS (least of all me). Any solution that gets implement anytime soon will of course use the Internet. Handles use the Internet in their current implementation, indeed anytime you look up a DOI, or follow a link in a journal that's marked "CrossRef", you use handles. It's just that: (a) I'm a little wary of including Internet addresses in GUIDs, more because the implied link to a site may disappear if the site dies/moves/changes name. Yes there are mechanisms to deal with this, but having an Internet address has the potential to mislead. Imagine if records served by MOBOT start to get served by, say, the New York Botanical Garden. What will users think of resolving an LSID with mobot.org in the name and getting a different server. A generation brought up with phishing scams (http://en.wikipedia.org/wiki/Phishing) and taught to check a URL is really what it says it is might get nervous. (b) I'm not seriously arguing the DNS or the Internet are going away anytime soon, however I think it is interesting that this is a concern voiced by the people who are probably closest to us in mindset - digital librarians. They care deeply about curation, have rare, old, culturally valuable artefacts, and want systems that persist beyond current fashions and/or technologies. Sound familiar? If so, let's ask why have they gone for things like handles? Regards Rod On 28 Jan 2006, at 14:25, Chuck Miller wrote: > Although the Internet may change in the future and none of us have a > crystal ball, some method for turning names (gbif.org) into network > addresses (192.38.28.79) will be required. For the forseeable future > that method on the Internet will almost certainly be DNS. The cascade > of the global DNS server network is key to making the Internet work. > No matter what URL you put into your browser, the DNS network finds > its way to the IP address of the server. Trillions of dollars of > commerce now depend upon this global standard. I think the analogy is > more like the teletype machines and the ASCII codes they used. > Although we have Unicode now, it still includes ASCII. In > communications, the new must continue to support the old. This can be > seen in the W3C projects that continue to build upon the previous > standards. > > To replace the Internet's global DNS locator service with something > unique to biodiversity seems like a complex, expensive and long-term > proposition. For the sake of getting things done in a timely manner, > I think we need to keep things simple and leverage the pieces of the > puzzle that already work. Implementing a GUID scheme is going to be > tough enough without tackling a replacement for DNS. > > An issue that needs to be decided by the workshop is how much > "abstraction" of a GUID is absolutely necessry if it must also be > locatable through the Internet? That is, is a compromise needed to > allow embedding of domain names in order to enable use of the DNS to > locate GUIDs. Surely there is insufficient time, funds, and staff to > embark upon creation of a master switchboard (database) where the > locations of millions of GUIDs are recorded and updated in perpetuity. > > Chuck Miller > Missouri Botanical Garden > > > -----Original Message----- > From: Roderic Page > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Sent: 1/28/2006 2:58 AM > Subject: Re: [TDWG-GUID] identifiers for geologic samples > > On 28 Jan 2006, at 01:02, Richard Pyle wrote: > > > The more I think about it, the more I think this is the sort of > system > > that > > would work well for our field. A centralized issuer (which could > issue > > blocks of thousands or millions of numbers at a time), > > The major problem I see with this is that a central registry may be a > rate limiting step because it has to allocate blocks, it would also > decide for format of the last part of the identifier (which the > provider might not find desirable), and it may well lead to lots of > wasted identifiers (e.g., it allocates 100,000 to me, but I use 3 off > them). > > Would it not be better to devolve this? You can still have a central > registry. For example, Handles and DOIs work by having a central > registry for the prefix (e.g., "1018") and the provider is responsible > for allocating the suffix locally. > > > > I'm not sure how wise it would be to create a new syntax standard, > > rather > > than go with one of the ones we've discussed. But if (for example) > > using > > LSID, I personally think it would be preferable to establish a highly > > generic form, such as: > > > > urn:lsid:gbif.org:BioGUID:12345 > > Without wishing to preempt some of the things I'm going to present at > the workshop, I'm going off LSIDs a little because of their reliance on > the Internet DNS. Apart from the hassle of mucking with the DNS records > to set them up (I suspect not every provider is going to find this easy > to do), it assumes that the Internet its present form is going to be > here forever, and it also embeds information in the identifier (e.g., > "gbif.org") that currently has meaning, but over time may loose > meaning, or worse, be positively misleading (say if GBIF goes belly up > and somebody else serves the data). > > Handles (including DOIs) and ARK have no information in the identifier > (perhaps not strictly true for some DOIs, but that's by choice not > design), and also in principle don't need the internet. In the future > some other mode of information transport may come along, and they could > still be used. > > While it might be hard to imagine the Internet and the DNS going away, > if anybody has a 5 1/4" floppy lying around, they'll be aware of how > hard it is to get information off it these days as 5 1/4" drives are > scarce as hens teeth -- the only one in my department is in an old PC > that is connected to the network. The digital library community seem > particularly sensitive to these issues, which is perhaps why they use > handles, DOIs, and ARK. > > Regards > > Rod > > > > ----------------------------------------------------------------------- > - > ---------------------------------------- > 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/ > Find out what we know about a species at http://ispecies.org > > > > > > > ___________________________________________________________ > Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with > voicemail http://uk.messenger.yahoo.com > ------------------------------------------------------------------------ ---------------------------------------- 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/ Find out what we know about a species at http://ispecies.org

1 0

Re: How GUIDs will be used
by Dag Terje Endresen 30 Jan '06

30 Jan '06

Hi, I was also getting many stimulating ideas and questions after reading the ARK paper from California Digital Library last week and came up with the following Wiki page trying to capture some of my thoughts [http://wiki.gbif.org/guidwiki/wikka.php?wakka=GermplasmDatProviders] I am not (yet) so worried if more than one GUID resolve to the same object. There might be conflicting views on what objects are duplicates and legitimate arguments to assign distinct identities to objects considered dupplictes by others. As in Sally example on specimen 'Chapman 541' at Kew beeing different from the specimen in Canberra in the view of the holding institutes. Both specimns originate from the same collecting event and share the same original source. I think there will actually be conflicting opinions if they are duplicates or not from for example a conservationist view. The conservationist could say "We want to conserve the natural diversity not any artificial diversity introduced during the act of conservation". I believe the collecting events and the physical specimens are different levels of units. Similar to how a specimen unit is not the complete truth of the taxon unit it is assigned to; if saying so makes sense? We are in fact planning a global database/index hosted in Rome, IPGRI these days on the germplasm collecting events. We hope the worldwide institutes with specimens from the same collecting event would consider to reference this event as a unique unit distinct from the specimen itself. Having a GUID and a resolving mechanism on both the event and the specimens would of cource be helpful. A quick thought about Donalds coment on: >If identifier I1 refers to data object O1 and identifier I2 refers >to data object O2, our minimal requirement for GUIDs would be that: > >A) I1 == I2 --> O1 == O2 (for all relevant purposes) > >We need to decide under which circumstances we want this to be a >bidirectional implication, i.e. that: > > B) O1 == O2 --> I1 == I2 I was wondering on the same last week and as refelected on the wiki page I mentioned above. Would it be acceptable to the GUID model to provide more than one metadata statement on the same object (GUID). A simple cache index which only mirror the metadata would not intend to improve or change the metadata, differences only from update frequency (old index). But resolving the GUID to the index/portal (as well as the original data provider if available) might be preferable to the original data source for performance and persistence reasons? But what if another indexing portal modify the metadata to correct or add missing values. This can be georeferencing or similar efforts. I think I would like my specimen GUID to resolve to this extra information, but also to keep it separate from the metadata "officially" provided. So should this additional improved metadata be assigned a new GUID? Sorry if this is a stupid question, but I have been wondering about this question this week. What I am trying to get to is that there is a hierarchy of objects. The specimens belong to a taxon, belong to an original collecting event, belong to a holding institute... Metadata belong to an object, but should metadata sometimes be assigned its own GUID? I believe I am talking of metadata here and not digital objects on its own? Dag Terje Quoting Sally Hinchcliffe <S.Hinchcliffe(a)kew.org>: > Arthur wrote > > > To some extent I think Sally is right, what she suggests wouldn't > improve things with respect to duplicate specimens however- specimens > of the same collection sent to more than one (and some times many) > different institutions. > > > regarding duplicates, to my mind, there's a very strong connection > between the duplicate of 'Chapman 541' held at Kew and the one held > at Canberra (assuming there is such a thing). But they aren't the > same thing (and shouldn't have the same id) - a photograph of Kew's > duplicate would look nothing like a photograph of Canberra's > duplicate for example. I'm not sure whether GUIDs are going to help > us solve the problem of duplicates although I agree that it's > desirable. What _could_ have the same GUID is the collecting event > (Chapman taking a specimen) that gave rise to the two specimens ... > but who or what would issue or control _those_ GUIDs? > > Sally > *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk >

1 0