March 2006 - tdwg-tag - lists.tdwg.org

Index Fungorum LSID Authority
by Kevin Richards 09 Mar '06

09 Mar '06

I have finished setting up an LSID authority for Index Fungorum names. For more details about this task, see the wiki at http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverForTaxonNamesIF An example lsid is urn:lsid:indexfungorum.org:Names:213645. More LSIDs can be found by searching the indexfungorum names on the IF web site http://www.indexfungorum.org. The authority currently serves up exactly the same basic xml that is served by the IF web service (see http://www.indexfungorum.org/Names/IndexFungorumLSIDs.htm). The same xml is returned for both the metadata and the data at this stage - the LSID data will change later to something that we decide is the "unchangeable set of bytes" for a particular taxon name. As the return format is not RDF, this means that the metadata and data returned is not viewable by using IE Launchpad. However if you use launchpad it saves the metadata to the cache directory and you can view this file. The plugin for Firefox seems a little more verbose and allows you to save the data and metadata to a location of your choice when downloading the LSID info. Go to http://sourceforge.net/project/showfiles.php?group_id=130827 for Firefox plugin. The next step will be to return a more usefule format - RDF based on the TCS schema seems to be the desired option. I'm not sure how to approach this if anyone has any suggestions (ie the RDF version of TCS)? As it is a prototype, I could add "dummy" RDF predicates for the TCS elements required for an IF name, eg "http://www.tdwg.org/schemas/tcs/1.01/ScientificName/Simple", or create real temprary ones such as "urn:lsid:indexfungorum.org:predicates:123" specifically for IF. Anyone with more RDF experience have any suggestions? Kevin Richards ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: LSID conformance test tool
by Ricardo Scachetti Pereira 09 Mar '06

09 Mar '06

Bob, These are really good points. Thanks for bringing them up! I've created a new workgroup task on our wiki at http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDConformanceTesting. I tried to summarize your comments there. Please take a look and feel free change the wording if you'd like. I would like to comment on one of the issues you brought up: > > The only specific a priori concern about built in assumptions that > comes to mind is the one that pervaded early TDWG LSID discussion, > namely, that LSID Resolution Services might be conflated with LSID > Resolution Discovery Services and that the former might get DNS > notions inappropriately ingrained in them merely because such notions > are ingrained in the only currentlResolution Discovery Service scheme > ever mentioned by anybody, the DDDS/DNS scheme of Section 8.3 of the > LSID spec. [In particular, a resolution client like Launchpad which is > standalone must, ipso facto, have some Resolution Discovery Service > imbedded in it]. > > As in any enterprise, it's a little likely that the cultural norms of > TDWG membership will also creep in, but it is very difficult to > characterize that in ways that would inform conformance software. > Operative words are likely to include "systematist", "taxonomist", > "museum", and "kingdom".(*) To me, this means---ultimately---having a > clear separation between tests of \intended/ special things about TDWG > blessed LSID resolvers and tests of things that are identified as > about all LSIDs, in case one can find such things. This all augurs for > tools that are at least in part meaningful when applied against > resolution services that have nothing to do with TDWG. It is likely that we will end up creating a number of additional requirements for use of LSIDs in our community. That's actually the goal of the infrastructure working group. If you look at their wiki page (http://wiki.gbif.org/guidwiki/wikka.php?wakka=InfrastructureWorkingGroup) you will know what I mean. Some of these new requirements will sure have an impact on conformance testing. It would probably be nice to check server conformance to these additional requirements besides testing strict standard conformance. In any case, these assumptions should be clearly stated and separated, and the test tool should be modular enough to accomodate that. Regards, Ricardo

1 0

Re: Index Fungorum LSID Authority
by Kennedy, Jessie 09 Mar '06

09 Mar '06

Hi Kevin I think there are a few initial stabs at RDF versions of TCS out there, in addition to Roger's, Donald has been working on a simple one for some of TCS and Rob Gales has also been working on one. As part of the work being done on TCS we will issue one, so will look at the different versions and then publish one but as we're only working on prototypes for the time being you could use any. If Roger publishes the one he's working on next week I'd use that and then we'll announce any updates through the lists. Jessie ________________________________ From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU] On Behalf Of Roger Hyam Sent: 09 March 2006 09:43 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: Index Fungorum LSID Authority Hi Kevin, I am working on an RDF version of TCS TaxonNames but not showing it to anyone just yet! I'll let you know when I have something worth talking about - next week some time I suspect. I hope this will be a kick off point for talking about it in the TCS community so it won't be stable but I hope it will be something for demonstration purposes. We could consider using the accepted_formats parameter of getMetadata to offer a two flavours of metadata in the mean time. (Possible RDF by default and 'xmlSchema' for the XML Schema based form.) If we did this we would still need to have conventions in place such as whether to always include the schema location in the XML or not. Great to know you have got it working. Roger Kevin Richards wrote: I have finished setting up an LSID authority for Index Fungorum names. For more details about this task, see the wiki at http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverForTaxonNamesI F An example lsid is urn:lsid:indexfungorum.org:Names:213645. More LSIDs can be found by searching the indexfungorum names on the IF web site http://www.indexfungorum.org <http://www.indexfungorum.org/Names/IndexFungorumLSIDs.htm> . The authority currently serves up exactly the same basic xml that is served by the IF web service (see http://www.indexfungorum.org/Names/IndexFungorumLSIDs.htm). The same xml is returned for both the metadata and the data at this stage - the LSID data will change later to something that we decide is the "unchangeable set of bytes" for a particular taxon name. As the return format is not RDF, this means that the metadata and data returned is not viewable by using IE Launchpad. However if you use launchpad it saves the metadata to the cache directory and you can view this file. The plugin for Firefox seems a little more verbose and allows you to save the data and metadata to a location of your choice when downloading the LSID info. Go to http://sourceforge.net/project/showfiles.php?group_id=130827 for Firefox plugin. The next step will be to return a more usefule format - RDF based on the TCS schema seems to be the desired option. I'm not sure how to approach this if anyone has any suggestions (ie the RDF version of TCS)? As it is a prototype, I could add "dummy" RDF predicates for the TCS elements required for an IF name, eg "http://www.tdwg.org/schemas/tcs/1.01/ScientificName/Simple <http://www.tdwg.org/schemas/tcs/1.01/ScientificName/Simple> ", or create real temprary ones such as "urn:lsid:indexfungorum.org:predicates:123" specifically for IF. Anyone with more RDF experience have any suggestions? Kevin Richards ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++ 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++ -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 ------------------------------------- This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

1 0

Re: Index Fungorum LSID Authority
by Roger Hyam 09 Mar '06

09 Mar '06

Hi Kevin, I am working on an RDF version of TCS TaxonNames but not showing it to anyone just yet! I'll let you know when I have something worth talking about - next week some time I suspect. I hope this will be a kick off point for talking about it in the TCS community so it won't be stable but I hope it will be something for demonstration purposes. We could consider using the accepted_formats parameter of getMetadata to offer a two flavours of metadata in the mean time. (Possible RDF by default and 'xmlSchema' for the XML Schema based form.) If we did this we would still need to have conventions in place such as whether to always include the schema location in the XML or not. Great to know you have got it working. Roger Kevin Richards wrote: > I have finished setting up an LSID authority for Index Fungorum > names. For more details about this task, see the wiki at > http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverForTaxonNamesIF > An example lsid is urn:lsid:indexfungorum.org:Names:213645. More > LSIDs can be found by searching the indexfungorum names on the IF web > site http://www.indexfungorum.org > <http://www.indexfungorum.org/Names/IndexFungorumLSIDs.htm>. > > The authority currently serves up exactly the same basic xml that is > served by the IF web service (see > http://www.indexfungorum.org/Names/IndexFungorumLSIDs.htm). The same > xml is returned for both the metadata and the data at this stage - the > LSID data will change later to something that we decide is the > "unchangeable set of bytes" for a particular taxon name. > As the return format is not RDF, this means that the metadata and data > returned is not viewable by using IE Launchpad. However if you use > launchpad it saves the metadata to the cache directory and you can > view this file. The plugin for Firefox seems a little more verbose > and allows you to save the data and metadata to a location of your > choice when downloading the LSID info. Go to > http://sourceforge.net/project/showfiles.php?group_id=130827 for > Firefox plugin. > > The next step will be to return a more usefule format - RDF based on > the TCS schema seems to be the desired option. I'm not sure how to > approach this if anyone has any suggestions (ie the RDF version of > TCS)? As it is a prototype, I could add "dummy" RDF predicates for > the TCS elements required for an IF name, eg > "http://www.tdwg.org/schemas/tcs/1.01/ScientificName/Simple > <http://www.tdwg.org/schemas/tcs/1.01/ScientificName/Simple>", or > create real temprary ones such as > "urn:lsid:indexfungorum.org:predicates:123" specifically for IF. > Anyone with more RDF experience have any suggestions? > > Kevin Richards > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

LSID conformance test tool
by Ricardo Scachetti Pereira 09 Mar '06

09 Mar '06

Hi all, There's been a number of new LSID resolvers (prototypes) poping up here and there due to the recent adoption of LSID specification by the Biodiversity Informatics community (see http://wiki.gbif.org/guidwiki and http://wiki.gbif.org/guidwiki/wikka.php?wakka=PrototypingWorkingGroup for more details). Since then I found myself spending quite sometime trying to explore the details of each implementation and also troubleshooting some of the resolvers. Although there is a number of tools available for testing, such as both IE and Mozilla Launchpads and the Biopathways web resolver, I often find myself trying to get more info out of the resolvers using ad-hoc techniques, such as hacking urls in the web browser address box. I thought it would be nice to have a more automated tool that would tell us all about each new resolver that pops up out there. I think developers setting up their own resolvers would benefit of such tool as well. Initially, the idea as to develop a kind of LSID resolver debug tool, but it quickly evolved into some kind of LSID standard conformance test. So before I start doing this on my own, I would be grateful if you could share your thoughts regarding the development of an automated conformance testing tool for LSID resolvers, such as requirements, past and ongoing related activities, or any ideas on the matter. What I have in mind right now is the following: * This conformance tool would take one or more LSIDs and would try and resolve them. It would then output a report about the resolver and warning and error messages when the server deviates from the standard. * The tool would output a full report about the LSID authority, including: 1. LSID syntax break up: authority id, namespace, id, version (trivial); 2. Information about the authority DNS SRV record. If none is found, it would use the Launchpad http fallback mechanism to move on (it would issue a warning regarding that fact, though); 3. Information about the WSDL found at /authority/ path (WSDL and human readable report if possible) 4. Information about the getAvailableServices() call (list of available services, WSDLs and again, a human readable report if possible) 5. Information on calls to all available (data and metadata) services, with links to the results. 6. What else? * The tool could also test for (http) error codes by providing data that is known to be invalid (something like Unit Tests). * Would it be nice to have a client conformance test tool? I'm just not sure yet how this tool would keep track of calls made by the same client. The other issue I'm struggling at the moment is the question of how to implement it. The first thing that came to my mind was to hack one of the existing clients. Now I'm not sure whether to use IE Launchpad and thus make this available as a desktop client or to use the Perl or Java client stacks to implement the tool as a web application. Anyway, thoughts are really appreciated. Best regards, Ricardo PS. Sorry about the cross post. This message is being sent to both the LSID developers and the TDWG/GBIF GUID mailing lists, as I believe it will interest both communities.

1 0

Re: Index Fungorum LSID Authority [ Scanned for viruses ]
by Paul Kirk 09 Mar '06

09 Mar '06

Well done Kevin. Guess I'll have to download and install Launchpad and give it a try. The 'unchangeable set of bytes' is, for the present, the [NAME OF FUNGUS] field, although we might string on the [AUTHOR] and [YEAR OF PUBLICATION]. For the moment the first field is the only one which is unchanging for each LSID. In haste, Paul -----Original Message----- From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU]On Behalf Of Kevin Richards Sent: 09 March 2006 01:16 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Index Fungorum LSID Authority [ Scanned for viruses ] I have finished setting up an LSID authority for Index Fungorum names. For more details about this task, see the wiki at http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDResolverForTaxonNamesIF An example lsid is urn:lsid:indexfungorum.org:Names:213645. More LSIDs can be found by searching the indexfungorum names on the IF web site http://www.indexfungorum.org <http://www.indexfungorum.org/Names/IndexFungorumLSIDs.htm> . The authority currently serves up exactly the same basic xml that is served by the IF web service (see http://www.indexfungorum.org/Names/IndexFungorumLSIDs.htm). The same xml is returned for both the metadata and the data at this stage - the LSID data will change later to something that we decide is the "unchangeable set of bytes" for a particular taxon name. As the return format is not RDF, this means that the metadata and data returned is not viewable by using IE Launchpad. However if you use launchpad it saves the metadata to the cache directory and you can view this file. The plugin for Firefox seems a little more verbose and allows you to save the data and metadata to a location of your choice when downloading the LSID info. Go to http://sourceforge.net/project/showfiles.php?group_id=130827 for Firefox plugin. The next step will be to return a more usefule format - RDF based on the TCS schema seems to be the desired option. I'm not sure how to approach this if anyone has any suggestions (ie the RDF version of TCS)? As it is a prototype, I could add "dummy" RDF predicates for the TCS elements required for an IF name, eg "http://www.tdwg.org/schemas/tcs/1.01/ScientificName/Simple <http://www.tdwg.org/schemas/tcs/1.01/ScientificName/Simple> ", or create real temprary ones such as "urn:lsid:indexfungorum.org:predicates:123" specifically for IF. Anyone with more RDF experience have any suggestions? Kevin Richards ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: LSID conformance test tool
by Bob Morris 09 Mar '06

09 Mar '06

I'm not sure what you mean by "hack one of the existing clients", but it is always good to have two independent testbeds, preferably coded in different programming languages. Otherwise, you run the risk of memorializing as correct whatever a single one accepts. Further, don't assume that two randomly chosen clients selected as a base are independent. They may be using common assumptions, e.g. common rdf parsers. It was quite a while before the SDD team realized that XML Spy was accepting as correct some schema syntax that wasn't. We didn't discover this until we began building tools that depended on having valid schemas. That's a smaller set of tools than one might imagine (which could be at the root of some justly deserved criticism of XML-Schema: its use is sometimes more advice than consent). We now tend to run everything through at least two parsers. (Three actually, because XML Spy, amazingly, uses different parsers in its Text view and in its Schema view!). As a small aid to parties with no ability or inclination to invoke standalone XML validating parsers, we wrote a simple wrapper around Apache Xerces that let it be invoked by anybody, even those who would rather push mouse buttons and use gui file browsers than invoke a single keystroke in a shell command window... The only specific a priori concern about built in assumptions that comes to mind is the one that pervaded early TDWG LSID discussion, namely, that LSID Resolution Services might be conflated with LSID Resolution Discovery Services and that the former might get DNS notions inappropriately ingrained in them merely because such notions are ingrained in the only currentlResolution Discovery Service scheme ever mentioned by anybody, the DDDS/DNS scheme of Section 8.3 of the LSID spec. [In particular, a resolution client like Launchpad which is standalone must, ipso facto, have some Resolution Discovery Service imbedded in it]. As in any enterprise, it's a little likely that the cultural norms of TDWG membership will also creep in, but it is very difficult to characterize that in ways that would inform conformance software. Operative words are likely to include "systematist", "taxonomist", "museum", and "kingdom".(*) To me, this means---ultimately---having a clear separation between tests of \intended/ special things about TDWG blessed LSID resolvers and tests of things that are identified as about all LSIDs, in case one can find such things. This all augurs for tools that are at least in part meaningful when applied against resolution services that have nothing to do with TDWG. Ideally, conformance test software would cleverly sneak in functionality that tests whether the resolution service author has actually read the LSID spec. Hah, hah, just serious. Bob (*)Probably because of TDWG's history, those four words, seem to me to enter in a lot of conversations that also include the phrase ("Oh, we didn't think of that case"). I don't mean to denigrate any practitioners of any of these venues and intend no offense. I mean only to remind that any system architect comes with baggage from the environment in which they usually work and it is a quite difficult thing to recognize if and when that is in the way. But for conformance software it is critical. Of course I have the advantage of knowing close to no biology, so naturally there are never hidden assumptions in biodiversity informations systems I design. [That sentence was sarcastic]. On 3/9/06, Ricardo Scachetti Pereira <ricardo(a)tdwg.org> wrote: > > Hi all, > > There's been a number of new LSID resolvers (prototypes) poping up > here and there due to the recent adoption of LSID specification by the > Biodiversity Informatics community (see http://wiki.gbif.org/guidwiki > and > http://wiki.gbif.org/guidwiki/wikka.php?wakka=PrototypingWorkingGroup > for more details). > > Since then I found myself spending quite sometime trying to explore > the details of each implementation and also troubleshooting some of the > resolvers. Although there is a number of tools available for testing, > such as both IE and Mozilla Launchpads and the Biopathways web resolver, > I often find myself trying to get more info out of the resolvers using > ad-hoc techniques, such as hacking urls in the web browser address box. > > I thought it would be nice to have a more automated tool that would > tell us all about each new resolver that pops up out there. I think > developers setting up their own resolvers would benefit of such tool as > well. > > Initially, the idea as to develop a kind of LSID resolver debug > tool, but it quickly evolved into some kind of LSID standard conformance > test. > [...] So before I start doing this on my own, I would be grateful if you > could share your thoughts regarding the development of an automated > conformance testing tool for LSID resolvers, such as requirements, past > and ongoing related activities, or any ideas on the matter. > [...] > > The other issue I'm struggling at the moment is the question of how > to implement it. The first thing that came to my mind was to hack one of > the existing clients. Now I'm not sure whether to use IE Launchpad and > thus make this available as a desktop client or to use the Perl or Java > client stacks to implement the tool as a web application. I'm not sure what you mean by "hack one of the existing clients", but it is always good to have two independent testbeds, preferably coded in different programming languages. Otherwise, you run the risk of memorializing as correct whatever a single one accepts. Further, don't assume that two randomly chosen clients selected as a base are independent. They may be using common assumptions, e.g. common rdf parsers. It was quite a while before the SDD team realized that XML Spy was accepting as correct some schema syntax that wasn't. We didn't discover this until we began building tools that depended on having valid schema. That's a smaller set of tools than one might imagine (which could be at the root of some justly deserved criticism of XML-Schema: its use is sometimes more advice than consent). We now tend to run everything through at least two parsers. (Three actually, because XML Spy, amazingly, uses different parsers in its Text view and in its Schema view!). As a small aid to parties with no ability or inclination to invoke standalone XML validating parsers, we wrote a simple wrapper around Apache Xerces that let it be invoked by anybody, even those who would rather push mouse buttons and use gui file browsers than invoke a single keystroke in a shell command window... The only specific a priori concern about built in assumptions that comes to mind is the one that pervaded early TDWG LSID discussion, namely, that LSID Resolution Services might be conflated with LSID Resolution Discovery Services and that the former might get DNS notions inappropriately ingrained in them merely because such notions are ingrained in the only currentlResolution Discovery Service scheme ever mentioned by anybody, the DDDS/DNS scheme of Section 8.3 of the LSID spec. As in any enterprise, it's a little likely that the cultural norms of TDWG membership will also creep in, but it is very difficult to characterize that in ways that would inform conformance software. Operative words are likely to include "systematist", "taxonomist", "museum", and "kingdom". To me, this means---ultimately---having a clear separation between tests of \intended/ special things about TDWG blessed LSID resolvers and tests of things that are identified as about all LSIDs, in case one can find such things. This all augurs for tools that are at least in part meaningful when applied against resolution services that have nothing to do with TDWG. Ideally, conformance test software would cleverly sneak in functionality that tests whether the resolution service author has actually read the LSID spec. Hah, hah, just serious. Bob Anyway, thoughts are really appreciated. > > Best regards, > > Ricardo > > > PS. Sorry about the cross post. This message is being sent to both the > LSID developers and the TDWG/GBIF GUID mailing lists, as I believe it > will interest both communities. >

1 0

Position of GBIF in architecture and centralization of services.
by Roger Hyam 07 Mar '06

07 Mar '06

I have added two agreed issues to the TAG wiki on the basis of the discussions over the past few days. I won't add this to the end of the current threads as they are way off their original topics. I hope they will lay some ghosts to rest so we don't have to drag them up again to often - provided we all agree on them that is! The new points I believe we can agree on are: *The standards architecture developed and promoted by TDWG must be entirely separate from the GBIF data portal.* Although GBIF is involved in administering the TDWG Infrastructure Project which, in turn, has recommended the establishment of the TAG this in no way implies that any technical architecture proposed by the TAG will or should give the needs of the GBIF data portal any more weight than any other individual or group within the TDWG. Any proposals made by the TAG will be accompanied by technical justifications. It should therefore be clear if proposals are being made merely to facilitate the short term work of the GBIF data portal and not for the long term benefit of all. *Centralization of services* The TDWG architecture should not rely on any third party providing a particular piece of infrastructure indefinitely. This effectively rules out the architecture being based on any centralized data warehouse or indexing service beyond the hosting of standards files by TDWG itself - possibly as part of its collaborative infrastructure. You can read all agreed issues here: http://www.tdwg.hyam.net/twiki/bin/view/TAG/TagDiscussionRoadMap I believe this closes issues of whether we are building a global system or just specifying standards that could be used to collaboratively build a global system should people feel the need to do it. Speak now for forever hold your peace! All the best, Roger I -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

3 5

Re: Call for Participation: LSID Working Groups
by Kennedy, Jessie 07 Mar '06

07 Mar '06

Hi Ricardo I thought you weren't going to send out dates yet....... Jessie > -----Original Message----- > From: Taxonomic Databases Working Group GUID Project [mailto:TDWG- > GUID(a)LISTSERV.NHM.KU.EDU] On Behalf Of Ricardo Scachetti Pereira > Sent: 07 March 2006 11:53 > To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU > Subject: Call for Participation: LSID Working Groups > > TDWG/GBIF Call for Participation: > Life Sciences Identifiers (LSID) Working Groups > ------------------------------------------------------------------------ -- > - > > Background > ---------- > > The First Workshop on Globally Unique Identifiers for Biodiversity > Informatics (GUID-1) was held last month at NESCent (www.nescent.org) in > Durham, North Carolina, USA. The workshop was organized by the Taxonomic > Databases Working Group (http://www.tdwg.org/) and the Global > Biodiversity Information Facility (http://www.gbif.org/). > > GUID-1 recommended the use of Life Sciences Identifiers (LSID) in > biodiversity informatics and established two Working Groups to address > outstanding questions (see http://wiki.gbif.org/guidwiki/). Answers to > those questions will be reported to a second GUID meeting (GUID-2) to be > hosted by e-Science Institute (eSI) in Edinburgh scheduled for June 10-12 > 2006. > > > Participation > ------------- > > We have reached a significant point by establishing the infrastructure to > support widespread use of LSIDs in biodiversity informatics. We are > seeking anyone who is interested in participating in the two Working > Groups. Please send an expression of interest in leading or contributing > to any of the proposed tasks on the GUID wiki to guids(a)gbif.org. The > tasks are listed on the following web pages: > > http://wiki.gbif.org/guidwiki/wikka.php?wakka=InfrastructureWorkingGroup > > and > > http://wiki.gbif.org/guidwiki/wikka.php?wakka=PrototypingWorkingGroup > > If you can lead a task team, please edit the respective wiki page, > adding your name as task coordinator and start to outline the task. If > you want to be involved but not lead a task, contact the task leader if > there is one, or edit the respective wiki page by adding your name to > the task team and adding your contribution in the appropriate space. > > GUID-2 > ------ > > The second GUID meeting will be supported by the TDWG Infrastructure > Project funded by the Gordon and Betty Moore Foundation. Attendance at > GUID-2 will be by invitation, based on contributions against the tasks. > > GUID-2 will focus on working sessions and attendance will be limited. > Priority for support will be given to workgroup task leaders and others > actively participating on task developments. > > > Timeline > -------- > > 17/Mar/2006: Definition of task leaders. Tasks not claimed will be > pruned, reassigned or set aside for later consideration. > > 24/Mar/2006: Definition of task teams, task outlines, and work plan. > > 31/Mar/2006: Definition of GUID-2 participants based on task > assignments. GBIF/TDWG will send formal invitations to participants. > > Mar/Apr/May/2006: Task development and discussion of outstanding issues, > following work plan. > > May/2006: Finalization of prototypes, summary of discussions, draft of > recommendations for each task. Preparation to present summary at GUID-2 > Workshop. > > June/2006 - GUID-2 Workshop. > > > Contacts > -------- > > For further information, please send messages to guids(a)gbif.org, or > contact any of the following- > > * Lee Belbin, Australia - Project Manager (lee(a)tdwg.org) > * Donald Hobern, Denmark - Programmer Officer for Data Access and > Database Interoperability (dhobern(a)gbif.org) > * Ricardo Pereira, Brazil - Software Engineer (ricardo(a)tdwg.org) > * Roger Hyam, United Kingdom - Technical Architect (roger(a)tdwg.org) This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

1 0

Re: Call for Participation: LSID Working Groups
by Ricardo Scachetti Pereira 07 Mar '06

07 Mar '06

Hi folks, Just to clarify this last message, there is a slight chance (like 5%) that we change the dates of GUID-2 to June 9-11, instead of June 10-12. For that reason, Jessie would have preferred me not to specify the dates for GUID-2 just yet. In any case, we will inform you of the final (100% certain) GUID-2 meeting dates when we send out the invitations to participants by the end of this month. Sorry for any inconvenience this might have caused you. Best regards, Ricardo Kennedy, Jessie wrote: >Hi Ricardo > >I thought you weren't going to send out dates yet....... > >Jessie > > > >>-----Original Message----- >>From: Taxonomic Databases Working Group GUID Project [mailto:TDWG- >>GUID(a)LISTSERV.NHM.KU.EDU] On Behalf Of Ricardo Scachetti Pereira >>Sent: 07 March 2006 11:53 >>To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU >>Subject: Call for Participation: LSID Working Groups >> >>TDWG/GBIF Call for Participation: >>Life Sciences Identifiers (LSID) Working Groups >> >> >>

1 0