June 2007 - tdwg-tag - lists.tdwg.org

[tdwg-tapir] tapir metadata issues
by Wouter Addink 18 Jul '07

18 Jul '07

Hi, I am currently implementing Tapir metadata responses and have some issues. -indexing preferences frequency in the documentation states @Frequency (starting with uppercase), the schema uses @frequency. I assume I have to implement @frequency. -dc:language is mandatory. What to do with data that is not language specific? Example: we are going to use Tapir for sharing lists of scientific names. Should the language be Latin in that case? We think about using specifying English (eng) as default in that case. The recommendation is to use IANA Language subtags. Probably better to recommend the languages from ethnologue.org (3-letter abbreviations). This because the data can be in much more languages then the IANA Languages, for instance common names in extinct languages. This is different from the xml:lang attribute, which is primarily for application development. -the example for an accesspoint is http://example.net/tapir.cgi I think this may be misleading, it would perhaps be better to use http://example.net/tapir.cgi/yourdatasource as example. Wouter

4 20

[tdwg-guid] Is the http proxy of an LSID a GUID as well?
by Ricardo Pereira 18 Jun '07

18 Jun '07

Hi Bob, Personally, I would hold on to pure LSIDs and avoid using the http proxy as a GUID as much as possible, just to make sure my clients are robust enough. However, the semantics of the proxy software and the RDF returned when the identifier is resolved allow clients to assume the http proxy is in fact a GUID. Below is an example of RDF that you get back when you resolve the proxy LSID. <rdf:RDF> <rdf:Description rdf:about="urn:lsid:ubio.org:namebank:11815"> <dc:identifier>urn:lsid:ubio.org:namebank:11815</dc:identifier> <owl:sameAs rdf:resource="http://lsid.tdwg.org/urn:lsid:ubio.org:namebank:11815" /> ... In the case above, the LSID in its pure for is used as an identifier in *rdf:about* and *<dc:identifier>* (the namespace dc stands for Dublin Core.) However, the *<owl:sameAs>* statement asserts that both the LSID and its http proxy are equivalent and interchangeable. The proxy (the software at http://lsid.tdwg.org, for example) is the agent that actually implements that equivalence between the identifiers, without however asserting anything about resolvability of the proxied LSID. In my opinion, you can only assume that the proxy software will be able to resolve a given identifier as long as the proxy software itself and the LSID authority are operational. The proxy software cannot be deemed as an authority of that LSID. I think that this was your original concern, wasn't it? In summary, there is no problem assuming that a proxy version of an LSID is a GUID. But there are operational implications of using either form. It will all depend on whether the client is aware of the LSID spec and its particular implementation. For example, if your client isn't aware of LSID spec, then you have no choice other than storing and using the proxy version to get back to the object associated with the ID. The client may use the pure LSID as a URI for internal calculations, such as graph merging and querying, but it won't be able to resolve it directly. On the other hand, if your client is aware of the LSID spec, you have more options. You know how to get from an LSID to a proxy version and back. You can use it in your advantage, or not. You may want to store both versions so that your client is more robust to link rot, and so on. Cheers, Ricardo Bob Morris wrote: > Is the http proxy a GUID?

2 1

[tdwg-guid] Globally unique vs. globally locatable
by Ricardo Pereira 16 Jun '07

16 Jun '07

Hi folks, Here is another issue from that discussion thread that I'm splitting: (simply) globally unique vs. globally locatable. As Chuck said: 1. An identifier that is simply globally unique - that is, the id is never duplicated and always refers to the same thing. So, you can use it as a unique reference in a paper, like an ISBN/ISSN number. But more importantly, it also can be used in data files/serialized XML to enable computers to quickly compare import/export records for merge/update, which is an important function to many, many biodiversity data projects. But, this id does not itself tell you where it can be found. Its location must come from another source. 2. An identifier that is globally locatable via the Internet - that is, the id is never duplicated and always locates the same thing (with a further definition needed of what the thing is). The globally locatable identifier needs to be locatable by a web browser (HTTP) but more importantly also by web services which may want to use a different protocol. I would argue that, without loss of generality, any identifying scheme considered by this group (LSID, DOI, Handles, ARK and any HTTP URL based scheme) fulfill both use cases. Since we are interested in sharing data, the 2nd use case is far more important for us than the first. For that reason, I would suggest that any other scheme that provide globally unique but non-locatable identifiers (i.e. that fulfill use case #1 but not #2) would be irrelevant to this group. Such a scheme would still be important for cases other than sharing data, but that discussion would be outside of the scope of this group. If you are interested in discussing the best way to make your local identifiers globally unique (which was the issue that started this discussion I suppose), that's the subject of another (very relevant) thread. For now the only thing I'll say about that is that there are guidelines for making local identifiers globally unique in each identifying scheme. In the particular case of LSIDs you may find information about that in the following documents: * The LSID Specification - http://www.omg.org/cgi-bin/doc?dtc/04-05-01) * LSID Best Practices (Naming conventions) - http://www-128.ibm.com/developerworks/opensource/library/os-lsidbp/ * LSID Namespaces discussion - http://wiki.tdwg.org/twiki/bin/view/GUID/LSIDResolverNamespaces In any case, rest assured that we will sum up all those guidelines into a section of the Bratislava Declaration ;) Cheers, Ricardo

2 1

RE: [tdwg-guid] First step in implementing LSIDs
by Richard Pyle 14 Jun '07

14 Jun '07

Thanks, Jerry -- that's pretty much what I figured, and seems to make perfect sense to me. In my own case, as I am now in the process of completely overhauling our internal database structure and table cross-linking, I have arrived at essentially the same conclusion. For what it's worth, I have one sequentially-generated integer series that serves the purpose of providing primary key values for essentially every table in our system (only exceptions being a few enumerations with unambiguously finite value sets). Like you, I am now thinking of maintaining those integers for internal (performance) purposes only, and restricting what I expose publicly to GUIDs (I'm leaning toward following your lead of using UUIDs for this). Aloha, Rich > -----Original Message----- > From: Jerry Cooper [mailto:cooperj@landcareresearch.co.nz] > Sent: Tuesday, June 12, 2007 1:20 PM > To: Richard Pyle; 'Bob Morris'; Kevin Richards > Cc: 'Gregor Hagedorn'; tdwg-guid(a)lists.tdwg.org > Subject: RE: [tdwg-guid] First step in implementing LSIDs > > Richard, > > In your analysis you had ... > > [GloballyUniquePrefixStuff]+[LocallyUniqueIDentifier] > > It is probably worth saying why our LUID is a semantically > opaque GUID. And, yes we do consciously realise that we are > 'hedging our bets' as you put it. > > In our internal databases over the last few years we have > gone through various mechanisms for providing primary > key/foreign relationships. I recall numerous discussions > around the practical utility of counters versus semantically > opaque unique keys. Ultimately we decided that data we want > to make publicly available should carry a GUID - even if it > isn't used internally as part of a table relationship PK/FK. > What you see on the end of our LSIDs are those public GUIDs. > We did that prior to TDWG discussions around the adoption of > LSIDs and GUID resolution mechanisms. It allowed us to get on > with the job! > > Jerry > > > >>> "Richard Pyle" <deepreef(a)bishopmuseum.org> 13/06/2007 > 10:46:18 a.m. > >>> >>> > > At one point last week I had visions on catching up on this > whole thread and commenting on all sorts of things -- but I > don't think there is any hope of that in the forseeable > future, so I'll just jump right in on the current discussion. > > It seems to me that a lot of the recent discussion has been > confused by an unclear disctinction between the needs of > GUIDs as identifiers, and the means to resolve those GUIDs to > data and metadata. > > As someone earlier pointed out, if all we need are > identifiers (without immediate concern for the resolution > mechanism), then UUIDs will suffice. > So, let's start there: > > 0F9D60F1-59C7-495D-A37E-09C23770DD18 > > Wonderful identifier, with utterly no information about what > it represents, or what it would resolve to. When I type that > text string into a web browser, I get nothing. So, we can > either always rely on the GUID existing in some > non-GUID-embedded context where the resolution mechanism is > self-evident (maintained by the provider or the consumer of > the GUID), or we can embed resolution "meta-information" > within the GUID itself. These actually aren't fundamentally > different, but for the sake of argument, let's assume that > the former is unacceptable for our purposes. I can think of > at least four obvious examples of the latter: > > DOI:10.1234/0F9D60F1-59C7-495D-A37E-09C23770DD18 > > hdl:1234/0F9D60F1-59C7-495D-A37E-09C23770DD18 > > URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E- > 09C23770DD18 > > http://lsid.landcareresearch.co.nz/guid/0F9D60F1-59C7-495D-A37 > E-09C23770DD18 > > (Note that except for the LSID, these are my own creations.) > > The first example (DOI) doesn't actually solve the problem, > because merely appending "DOI:10.1234/" in front of my UUID > does not, by itself make it resolvable. For example, if I > type Rod's earlier example of > "doi:10.1206/0003-0082(2005)485[0001:PNAICA]2.0.CO;2" into my > browser, I get squat. That means that either I (as a human), > or the software application that I write, needs some "insider > information" to resolve the GUID. I don't see how this is any > different from option numbers 2 or 3. Sure, you could argue > that there is only one DOI system, or only one Handle system > (in the same general sense that there is only one DNS > system), so the amount of information required to resolve the > GUID is relatively small and universally known. But it seems > to me this is mostly true of LSIDs as well. In fact, if I > simply install the LSID Launchpad plug-in for my browser, I > *can* type the LSID in and get metadata back automatically > (as long as I chop the "URN:" part -- which seems like an > unnecessary step). The main difference among the first three > that I see is that in this blink-of-an-eye-moment in history, > there happen to be a lot of people using DOIs (and Handles?), > whereas LSIDs have not (yet?) caught on as widely. > > So, that leaves the fourth option (HTTP URL): the obvious > advantage of which is that resolution is a snap using current > browser protocols and technologies (no plug-ins required), > and development support is much better (given how widely used > HTTP is); and the apparent disadvantages being some social > concern of link-rot and/or uncertainty about the permanency > of the owner of the domain. > > Most of this has already been addressed in this thread. What > I haven't seen addressed (maybe I missed it?) is the > decreasing opacity of the GUID as you go through the sequence > above from UUID to URL. The decreasing opacity, as far as I > understand it, is directly tied to the increasing reliance on > embedded "meta-information" within the GUID itself to allow > the GUID to be self-resolving. > > We all know that the value of a GUID is a function of its > permanency, and we all agree that the weakest link in the > chain of permanency is the social contract part. To me, one > of the greatest values of maintaining opacity of GUIDs is to > help facilitate (encourage) the social contract for permanency. > Or, put another way, to decrease the opportunity/temptation > for breaking the social contract for permanency. > > Using the examples above, if the domain name > "landcareresearch.co.nz" is ever abandoned or changed or > otherwise broken, the URL will die, but the LSID will > continue to function (if I understand the LSID protocol > correctly). In the case of HTTP, the domain name relies on > current DNS mapping, whereas the LSID does not. > > So, my overall point here is that we seem to have two topics > that are being > conflated: GUIDs as identifiers per se, and resolution > mechanisms for the GUIDs. The more reliably and simply the > GUIDs are in terms of being self-resolving, the less opaque > the become, and the more concern people have (justifiably or > not) that permanency will be jeopardized. > > This leads me to the second part of this post, which I've > already hinted at earlier. > > Most GUID schemes seem to follow the basic pattern of: > > [GloballyUniquePrefixStuff]+[LocallyUniqueIDentifier] > > Generally, the "GUPS" part is somehow attached to the issuer, > and the "LUID" > part is unique only within the context of the "GUPS". Also, > any self-embedded resolution information is contained within > the "GUPS". > > In the example at the beginning of this message, I started > with a UUID, which by itself is globally unique. I carried > this through to to other examples, such that the "LUID" > portion of each example was actually by itself a GUID. > Obviously, there is no guarantee of that for the "LUID" part > of DOIs, Handles, LSIDs or URLs...but I keep asking myself > why we as a community (i.e., TDWG) don't come out with some > sort of "best practice" (if not recommendation, or even > outright standard) that those of us who have not yet begun to > issue GUIDs (but soon will) all make an effort to use > something like UUIDs for the "object identifier" ("LUID") > portion of the GUIDS we issue. > > My original thought was to register a Handle prefix to modify > my LUID, such that "987654321" becomes "1234/987654321", > which could then become > "URN:LSID:bishopmuseum.org:1234:987654321" (or perhaps > "URN:LSID:bishopmuseum.org:guid:1234/987654321", or even > "URN:LSID:bishopmuseum.org:Names:1234/987654321"), which > could then become > "http://guid.bishopmuseum.org/?URN:LSID:bishopmuseum.org:1234: > 987654321" (or maybe just > "http://guid.bishopmuseum.org/?1234:987654321"). > > But now I'm thinking maybe it's best to abandon the Handle > part, and just issue UUIDs as my local identifiers, which can > then be embedded in as many other GUID-resolution layers as I > wish. This seems to be more or less what Kevin Richards has > done for his LSIDs converted to URLs: > > http://lsid.landcareresearch.co.nz/lsid/URN:LSID:landcareresea > rch.co.nz:Name > s:0F9D60F1-59C7-495D-A37E-09C23770DD18 > > In any case, my point is that it seems to make sense to me > that we can all hedge our bets on which resolution mechanism > emerges victoriously by starting off with a resolution-less > UUID (or some other GUID serving a pure "identifier" role) at > the core of our locally-issued GUIDs, and then represent > those core identifiers through different resolution-level > GUIDs however we see fit. > > I would very-much appreciate it if someone could explain to > me what I am missing. > > Aloha, > Rich > > > > -----Original Message----- > > From: tdwg-guid-bounces(a)lists.tdwg.org > > [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Bob Morris > > Sent: Tuesday, June 12, 2007 11:02 AM > > To: Kevin Richards > > Cc: tdwg-guid(a)lists.tdwg.org; Gregor Hagedorn > > Subject: Re: [tdwg-guid] First step in implementing LSIDs > > > > Is the http proxy a GUID? > > > > What vouches for an assertion that a given proxy actually > resolves the > > associated LSID? > > > > > > > > On 6/12/07, Kevin Richards <RichardsK(a)landcareresearch.co.nz> wrote: > > > > > > > > > The main use of the LSID http proxy would be when you have an RDF > > > document or a triple store full of data that has BOTH the > > LSID and the > > > http version (as described on the wiki page > > > > > http://wiki.tdwg.org/twiki/bin/view/GUID/LsidHttpProxyUsageRec > > ommendation). > > > > > > If ALL you had was the LSID > > > > > "URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E > > -09C23770DD18" > > > and no other data at all, and you want to resolve it > using the http > > > proxy, then yes you are a bit stuck (as far as I know). > > Unless we set > > > up an LSID http proxy repository that can be queried and > > returns the > > > http proxy url for an LSID? Or you could just use the > "hard coded" > > > http proxy resolver at http:/lsid.tdwg.org/[lsid]. > > > > > > Kevin > > > > > > >>> "Gregor Hagedorn" <G.Hagedorn(a)BBA.DE> 12/06/2007 > > 7:17:35 p.m. >>> > > > > > > > For those wanting another LSID http proxy example, I > have changed > > > > our LSID resolver here at Landcare to serve up the proxy > > compliant RDF. > > > > > > > > Eg > > > > > > > > > > http://lsid.landcareresearch.co.nz/lsid/URN:LSID:landcareresearch.co.n > > > z:Names:0F9D60F1-59C7-495D-A37E-09C23770DD18 > > > > > > > > returns the metadata for the lsid > > > > > > > > > > URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770 > > > DD18 > > > > > > > > I took me about an hour to change the RDF generator and setup a > > > > redirection web directory on our web server (Microsoft IIS). > > > > > > I have an object with > > > > > > > > > URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770 > > > DD18 > > > > > > I think the problem is that, without me telling my software > > something > > > I have gathered from this email, my software has no means to know > > > about what you describe as easy. > > > > > > Unless it has an LSID resolver, in which case it would > not need the > > > http method. > > > > > > This is what the proposal to always use alternating http and LSID > > > guids in any object we communicate about is saying. Whenever you > > > publish > > > > > > URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770 > > > DD18 > > > you > > > also have to provide the http version of it. > > > > > > Gregor---------------------------------------------------------- > > > Gregor Hagedorn (G.Hagedorn(a)bba.de) > > > Institute for Plant Virology, Microbiology, and Biosafety Federal > > > Research Center for Agriculture and Forestry (BBA) > > > Königin-Luise-Str. 19 Tel: +49-30-8304-2220 > > > 14195 Berlin, Germany Fax: +49-30-8304-2203 > > > > > > _______________________________________________ > > > tdwg-guid mailing list > > > tdwg-guid(a)lists.tdwg.org > > > http://lists.tdwg.org/mailman/listinfo/tdwg-guid > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > ++++++++++++++ > > > 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 > > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > ++++++++++++++ > > > > > > > > > _______________________________________________ > > > tdwg-guid mailing list > > > tdwg-guid(a)lists.tdwg.org > > > http://lists.tdwg.org/mailman/listinfo/tdwg-guid > > > > > > > > _______________________________________________ > > tdwg-guid mailing list > > tdwg-guid(a)lists.tdwg.org > > http://lists.tdwg.org/mailman/listinfo/tdwg-guid > > > _______________________________________________ > tdwg-guid mailing list > tdwg-guid(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-guid > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++++++ > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++++++ > >

2 1

Re: [tdwg-guid] Globally unique vs. globally locatable
by Jerry Cooper 13 Jun '07

13 Jun '07

All, Here's a use case that's been going around in my head for a few years now and it raises some issues to which satisfactory solutions haven't occured to me yet. I believe there is a different emphasis in the use of GUIDs around names/taxon concepts than there are around such things as collections, observations or items of literature. This use case is about the use of resolveable GUIDs in any registration system for new organism names (or nomenclatural novelties in general). There are a number of current name registration models, either extant or proposed, that seem have a centralised model in mind. I don't like that. What I would like to see is a distributed network of 'name issuing authorities' wth some overarching governance structure managed by the code bodies. In this scenario a use case might be this ... 1) Any organisation can set itself as an issuer of new names. 2) It gets agreement from an authoritative body, designated by the code bodies, that it is a recognised issuer. 3) It hosts a web site/service that allows its community to enter data on new names (+whatever additional servics it desires) 4) It issues GUIDs associated with new names. 5) It provides a web service to resolve those GUIDs to an agreed, and unchanging metadata document on the name. 6) It provides a mechanism (push/pull) for anybody, but especially aggregators, to resolve these metadata 7) It has a contract with the code body that ,should it cease to be an issuer, then it transfers responsibility for it's service to another issuer (or perhaps an approved global aggregator service). So what about LSIDs in this scenario? It appears to satisfy the technical requirements. However some issues come to mind and I'm sure those who know more about this than me have answers. I'd be interested in hearing them. Some isues are: a) in the mycological world at least there appear to be a number of organisations who would like to sign up to this model - but can't jump the technical hurdle of providing an LSID resolution service. They can provide metadata, GUIDs and could provide a 'resolution' service to a global aggregator (in this case IndexFungoruum) by email attachments if necessary. The LSID technical hurdle should not stall such a system. b) the LSID contains a namespace which effectively 'brands' the issuer. This is where I really don't like the fact that the GUID relies on a sub-string which contains a namespace. In the case of new names the original issuer is an important fact, but it should be part of the metadata document - not the GUID. c) what happens when an issuer 'goes under' and is required to transfer responsibility to another designated authority? LSIDs wraps the resolution mechanism into the GUID. So either the ownership of the namespace gets transferred or another GUID is issued for essentialy the same object. Neither option sounds attractive. This yet another reason why we, Landcare Research, have chosen not to rely on LSIDs for name object GUIDs, and so our LSIDs contain a GUID within a GUID. Jerry >>> Ricardo Pereira <ricardo(a)tdwg.org> 14/06/2007 4:52 a.m. >>> Hi folks, Here is another issue from that discussion thread that I'm splitting: (simply) globally unique vs. globally locatable. As Chuck said: 1. An identifier that is simply globally unique - that is, the id is never duplicated and always refers to the same thing. So, you can use it as a unique reference in a paper, like an ISBN/ISSN number. But more importantly, it also can be used in data files/serialized XML to enable computers to quickly compare import/export records for merge/update, which is an important function to many, many biodiversity data projects. But, this id does not itself tell you where it can be found. Its location must come from another source. 2. An identifier that is globally locatable via the Internet - that is, the id is never duplicated and always locates the same thing (with a further definition needed of what the thing is). The globally locatable identifier needs to be locatable by a web browser (HTTP) but more importantly also by web services which may want to use a different protocol. I would argue that, without loss of generality, any identifying scheme considered by this group (LSID, DOI, Handles, ARK and any HTTP URL based scheme) fulfill both use cases. Since we are interested in sharing data, the 2nd use case is far more important for us than the first. For that reason, I would suggest that any other scheme that provide globally unique but non-locatable identifiers (i.e. that fulfill use case #1 but not #2) would be irrelevant to this group. Such a scheme would still be important for cases other than sharing data, but that discussion would be outside of the scope of this group. If you are interested in discussing the best way to make your local identifiers globally unique (which was the issue that started this discussion I suppose), that's the subject of another (very relevant) thread. For now the only thing I'll say about that is that there are guidelines for making local identifiers globally unique in each identifying scheme. In the particular case of LSIDs you may find information about that in the following documents: * The LSID Specification - http://www.omg.org/cgi-bin/doc?dtc/04-05-01 ) * LSID Best Practices (Naming conventions) - http://www-128.ibm.com/developerworks/opensource/library/os-lsidbp/ * LSID Namespaces discussion - http://wiki.tdwg.org/twiki/bin/view/GUID/LSIDResolverNamespaces In any case, rest assured that we will sum up all those guidelines into a section of the Bratislava Declaration ;) Cheers, Ricardo _______________________________________________ tdwg-guid mailing list tdwg-guid(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-guid ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1

[tdwg-guid] GUID use cases
by Ricardo Pereira 13 Jun '07

13 Jun '07

Chuck, You are absolutely right, there are many conflated issues being cross threaded in our discussions. Let's separate them. Regarding use cases, we have developed several of them just before the first GUID meeting in 2006. Jessie made a comment back then that some use cases regarding taxon concepts were missing. There may be other cases missing. In any case they are at: http://wiki.tdwg.org/twiki/bin/view/GUID/GUIDUseCases If anyone want to discuss GUID use cases, please reply to this thread only. Thanks! Ricardo Chuck Miller wrote: > I agree with Rich, there seem to be two conflated issues being cross-threaded in all these discussions. > > 1. An identifier that is simply globally unique - that is, the id is never duplicated and always refers to the same thing. So, you can use it as a unique reference in a paper, like an ISBN/ISSN number. But more importantly, it also can be used in data files/serialized XML to enable computers to quickly compare import/export records for merge/update, which is an important function to many, many biodiversity data projects. But, this id does not itself tell you where it can be found. Its location must come from another source. > > 2. An identifier that is globally locatable via the Internet - that is, the id is never duplicated and always locates the same thing (with a further definition needed of what the thing is). The globally locatable identifier needs to be locatable by a web browser (HTTP) but more importantly also by web services which may want to use a different protocol. > > 1 can be included in 2 as Nick has demonstrated. > > I think we need some standard use cases against which we could test the options. I'm afraid this discussion in the abstract will be endless. > > Do we have clear use cases for the biodiversity data GUIDs? > > How well do relocatable identifiers work in the use cases involving the exchange/compare/import/export of millions of records from multiple sources? > > Chuck >

1 0

Re: [tdwg-guid] First step in implementing LSIDs
by Kevin Richards 13 Jun '07

13 Jun '07

The main use of the LSID http proxy would be when you have an RDF document or a triple store full of data that has BOTH the LSID and the http version (as described on the wiki page http://wiki.tdwg.org/twiki/bin/view/GUID/LsidHttpProxyUsageRecommendation). If ALL you had was the LSID "URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770DD18" and no other data at all, and you want to resolve it using the http proxy, then yes you are a bit stuck (as far as I know). Unless we set up an LSID http proxy repository that can be queried and returns the http proxy url for an LSID? Or you could just use the "hard coded" http proxy resolver at http:/lsid.tdwg.org/[lsid]. Kevin >>> "Gregor Hagedorn" <G.Hagedorn(a)BBA.DE> 12/06/2007 7:17:35 p.m. >>> > For those wanting another LSID http proxy example, I have changed our > LSID resolver here at Landcare to serve up the proxy compliant RDF. > > Eg > http://lsid.landcareresearch.co.nz/lsid/URN:LSID:landcareresearch.co.nz:Nam… > > returns the metadata for the lsid > URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770DD18 > > I took me about an hour to change the RDF generator and setup a > redirection web directory on our web server (Microsoft IIS). I have an object with URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770DD18 I think the problem is that, without me telling my software something I have gathered from this email, my software has no means to know about what you describe as easy. Unless it has an LSID resolver, in which case it would not need the http method. This is what the proposal to always use alternating http and LSID guids in any object we communicate about is saying. Whenever you publish URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770DD18 you also have to provide the http version of it. Gregor---------------------------------------------------------- Gregor Hagedorn (G.Hagedorn(a)bba.de) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Königin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203 _______________________________________________ tdwg-guid mailing list tdwg-guid(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-guid ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

5 5

RE: [tdwg-guid] First step in implementing LSIDs
by Jerry Cooper 12 Jun '07

12 Jun '07

Richard, In your analysis you had ... [GloballyUniquePrefixStuff]+[LocallyUniqueIDentifier] It is probably worth saying why our LUID is a semantically opaque GUID. And, yes we do consciously realise that we are 'hedging our bets' as you put it. In our internal databases over the last few years we have gone through various mechanisms for providing primary key/foreign relationships. I recall numerous discussions around the practical utility of counters versus semantically opaque unique keys. Ultimately we decided that data we want to make publicly available should carry a GUID - even if it isn't used internally as part of a table relationship PK/FK. What you see on the end of our LSIDs are those public GUIDs. We did that prior to TDWG discussions around the adoption of LSIDs and GUID resolution mechanisms. It allowed us to get on with the job! Jerry >>> "Richard Pyle" <deepreef(a)bishopmuseum.org> 13/06/2007 10:46:18 a.m. >>> At one point last week I had visions on catching up on this whole thread and commenting on all sorts of things -- but I don't think there is any hope of that in the forseeable future, so I'll just jump right in on the current discussion. It seems to me that a lot of the recent discussion has been confused by an unclear disctinction between the needs of GUIDs as identifiers, and the means to resolve those GUIDs to data and metadata. As someone earlier pointed out, if all we need are identifiers (without immediate concern for the resolution mechanism), then UUIDs will suffice. So, let's start there: 0F9D60F1-59C7-495D-A37E-09C23770DD18 Wonderful identifier, with utterly no information about what it represents, or what it would resolve to. When I type that text string into a web browser, I get nothing. So, we can either always rely on the GUID existing in some non-GUID-embedded context where the resolution mechanism is self-evident (maintained by the provider or the consumer of the GUID), or we can embed resolution "meta-information" within the GUID itself. These actually aren't fundamentally different, but for the sake of argument, let's assume that the former is unacceptable for our purposes. I can think of at least four obvious examples of the latter: DOI:10.1234/0F9D60F1-59C7-495D-A37E-09C23770DD18 hdl:1234/0F9D60F1-59C7-495D-A37E-09C23770DD18 URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770DD18 http://lsid.landcareresearch.co.nz/guid/0F9D60F1-59C7-495D-A37E-09C23770DD18 (Note that except for the LSID, these are my own creations.) The first example (DOI) doesn't actually solve the problem, because merely appending "DOI:10.1234/" in front of my UUID does not, by itself make it resolvable. For example, if I type Rod's earlier example of "doi:10.1206/0003-0082(2005)485[0001:PNAICA]2.0.CO;2" into my browser, I get squat. That means that either I (as a human), or the software application that I write, needs some "insider information" to resolve the GUID. I don't see how this is any different from option numbers 2 or 3. Sure, you could argue that there is only one DOI system, or only one Handle system (in the same general sense that there is only one DNS system), so the amount of information required to resolve the GUID is relatively small and universally known. But it seems to me this is mostly true of LSIDs as well. In fact, if I simply install the LSID Launchpad plug-in for my browser, I *can* type the LSID in and get metadata back automatically (as long as I chop the "URN:" part -- which seems like an unnecessary step). The main difference among the first three that I see is that in this blink-of-an-eye-moment in history, there happen to be a lot of people using DOIs (and Handles?), whereas LSIDs have not (yet?) caught on as widely. So, that leaves the fourth option (HTTP URL): the obvious advantage of which is that resolution is a snap using current browser protocols and technologies (no plug-ins required), and development support is much better (given how widely used HTTP is); and the apparent disadvantages being some social concern of link-rot and/or uncertainty about the permanency of the owner of the domain. Most of this has already been addressed in this thread. What I haven't seen addressed (maybe I missed it?) is the decreasing opacity of the GUID as you go through the sequence above from UUID to URL. The decreasing opacity, as far as I understand it, is directly tied to the increasing reliance on embedded "meta-information" within the GUID itself to allow the GUID to be self-resolving. We all know that the value of a GUID is a function of its permanency, and we all agree that the weakest link in the chain of permanency is the social contract part. To me, one of the greatest values of maintaining opacity of GUIDs is to help facilitate (encourage) the social contract for permanency. Or, put another way, to decrease the opportunity/temptation for breaking the social contract for permanency. Using the examples above, if the domain name "landcareresearch.co.nz" is ever abandoned or changed or otherwise broken, the URL will die, but the LSID will continue to function (if I understand the LSID protocol correctly). In the case of HTTP, the domain name relies on current DNS mapping, whereas the LSID does not. So, my overall point here is that we seem to have two topics that are being conflated: GUIDs as identifiers per se, and resolution mechanisms for the GUIDs. The more reliably and simply the GUIDs are in terms of being self-resolving, the less opaque the become, and the more concern people have (justifiably or not) that permanency will be jeopardized. This leads me to the second part of this post, which I've already hinted at earlier. Most GUID schemes seem to follow the basic pattern of: [GloballyUniquePrefixStuff]+[LocallyUniqueIDentifier] Generally, the "GUPS" part is somehow attached to the issuer, and the "LUID" part is unique only within the context of the "GUPS". Also, any self-embedded resolution information is contained within the "GUPS". In the example at the beginning of this message, I started with a UUID, which by itself is globally unique. I carried this through to to other examples, such that the "LUID" portion of each example was actually by itself a GUID. Obviously, there is no guarantee of that for the "LUID" part of DOIs, Handles, LSIDs or URLs...but I keep asking myself why we as a community (i.e., TDWG) don't come out with some sort of "best practice" (if not recommendation, or even outright standard) that those of us who have not yet begun to issue GUIDs (but soon will) all make an effort to use something like UUIDs for the "object identifier" ("LUID") portion of the GUIDS we issue. My original thought was to register a Handle prefix to modify my LUID, such that "987654321" becomes "1234/987654321", which could then become "URN:LSID:bishopmuseum.org:1234:987654321" (or perhaps "URN:LSID:bishopmuseum.org:guid:1234/987654321", or even "URN:LSID:bishopmuseum.org:Names:1234/987654321"), which could then become "http://guid.bishopmuseum.org/?URN:LSID:bishopmuseum.org:1234:987654321" (or maybe just "http://guid.bishopmuseum.org/?1234:987654321"). But now I'm thinking maybe it's best to abandon the Handle part, and just issue UUIDs as my local identifiers, which can then be embedded in as many other GUID-resolution layers as I wish. This seems to be more or less what Kevin Richards has done for his LSIDs converted to URLs: http://lsid.landcareresearch.co.nz/lsid/URN:LSID:landcareresearch.co.nz:Name s:0F9D60F1-59C7-495D-A37E-09C23770DD18 In any case, my point is that it seems to make sense to me that we can all hedge our bets on which resolution mechanism emerges victoriously by starting off with a resolution-less UUID (or some other GUID serving a pure "identifier" role) at the core of our locally-issued GUIDs, and then represent those core identifiers through different resolution-level GUIDs however we see fit. I would very-much appreciate it if someone could explain to me what I am missing. Aloha, Rich > -----Original Message----- > From: tdwg-guid-bounces(a)lists.tdwg.org > [mailto:tdwg-guid-bounces@lists.tdwg.org] On Behalf Of Bob Morris > Sent: Tuesday, June 12, 2007 11:02 AM > To: Kevin Richards > Cc: tdwg-guid(a)lists.tdwg.org; Gregor Hagedorn > Subject: Re: [tdwg-guid] First step in implementing LSIDs > > Is the http proxy a GUID? > > What vouches for an assertion that a given proxy actually > resolves the associated LSID? > > > > On 6/12/07, Kevin Richards <RichardsK(a)landcareresearch.co.nz> wrote: > > > > > > The main use of the LSID http proxy would be when you have an RDF > > document or a triple store full of data that has BOTH the > LSID and the > > http version (as described on the wiki page > > > http://wiki.tdwg.org/twiki/bin/view/GUID/LsidHttpProxyUsageRec > ommendation). > > > > If ALL you had was the LSID > > > "URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E > -09C23770DD18" > > and no other data at all, and you want to resolve it using the http > > proxy, then yes you are a bit stuck (as far as I know). > Unless we set > > up an LSID http proxy repository that can be queried and > returns the > > http proxy url for an LSID? Or you could just use the "hard coded" > > http proxy resolver at http:/lsid.tdwg.org/[lsid]. > > > > Kevin > > > > >>> "Gregor Hagedorn" <G.Hagedorn(a)BBA.DE> 12/06/2007 > 7:17:35 p.m. >>> > > > > > For those wanting another LSID http proxy example, I have changed > > > our LSID resolver here at Landcare to serve up the proxy > compliant RDF. > > > > > > Eg > > > > > > http://lsid.landcareresearch.co.nz/lsid/URN:LSID:landcareresearch.co.n > > z:Names:0F9D60F1-59C7-495D-A37E-09C23770DD18 > > > > > > returns the metadata for the lsid > > > > > > URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770 > > DD18 > > > > > > I took me about an hour to change the RDF generator and setup a > > > redirection web directory on our web server (Microsoft IIS). > > > > I have an object with > > > > > URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770 > > DD18 > > > > I think the problem is that, without me telling my software > something > > I have gathered from this email, my software has no means to know > > about what you describe as easy. > > > > Unless it has an LSID resolver, in which case it would not need the > > http method. > > > > This is what the proposal to always use alternating http and LSID > > guids in any object we communicate about is saying. Whenever you > > publish > > > URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770 > > DD18 > > you > > also have to provide the http version of it. > > > > Gregor---------------------------------------------------------- > > Gregor Hagedorn (G.Hagedorn(a)bba.de) > > Institute for Plant Virology, Microbiology, and Biosafety Federal > > Research Center for Agriculture and Forestry (BBA) > > Königin-Luise-Str. 19 Tel: +49-30-8304-2220 > > 14195 Berlin, Germany Fax: +49-30-8304-2203 > > > > _______________________________________________ > > tdwg-guid mailing list > > tdwg-guid(a)lists.tdwg.org > > http://lists.tdwg.org/mailman/listinfo/tdwg-guid > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++++++ > > 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 > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > ++++++++++++++ > > > > > > _______________________________________________ > > tdwg-guid mailing list > > tdwg-guid(a)lists.tdwg.org > > http://lists.tdwg.org/mailman/listinfo/tdwg-guid > > > > > _______________________________________________ > tdwg-guid mailing list > tdwg-guid(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-guid _______________________________________________ tdwg-guid mailing list tdwg-guid(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-guid ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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

TaxonOccurrence
by Bob Morris 12 Jun '07

12 Jun '07

Roger- 1. http://wiki.tdwg.org/twiki/bin/view/TAG/TaxonOccurrenceLsidVoc points at http://rs.tdwg.org/ontology/voc/TaxonOccurrence.rdf whose date there is 11 June 2007, but whose content specifies that its Modified Data is 5 Jan 2007. 2. Assuming ...voc/TaxonOccurrence.rdf is the correct vocabulary, I would note that I don't see how this rdf would allow the coding of non-occurrence, which is a very important point in the Observations group (and the wider Observations community). If there is a recommended practice for that with this rdf, perhaps it should go on the wiki. Bob

1 0

Re: [tdwg-guid] First step in implementing LSIDs
by Kevin Richards 12 Jun '07

12 Jun '07

For those wanting another LSID http proxy example, I have changed our LSID resolver here at Landcare to serve up the proxy compliant RDF. Eg http://lsid.landcareresearch.co.nz/lsid/URN:LSID:landcareresearch.co.nz:Nam… returns the metadata for the lsid URN:LSID:landcareresearch.co.nz:Names:0F9D60F1-59C7-495D-A37E-09C23770DD18 I took me about an hour to change the RDF generator and setup a redirection web directory on our web server (Microsoft IIS). Kevin ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

2 1