April 2006 - tdwg-tag - lists.tdwg.org

PublicationBank survey results and some things to discuss
by Robert Huber 12 Apr '06

12 Apr '06

Dear all, Following the discussion on PublicationBank and after the results of the survey, I must confess I still have some difficulties to see what exactly PublicationBank will be and how it could be implemented. Therefore I would just like to throw the survey results and some of my thoughts/ideas here and on the WIKI. I hope this will stimulate the discussion.. Current status of bibliographic data Based on the survey I sent around, it can be said that there are many ways how bib data is treated by participating dbs. I received 7 responses to the survey. For about 50%, bib modules are not or incomplete normalized, but the majority stores the complete set of bibliographic information I asked for (or even more). However, some institutions use abbreviations(e.g. Brummit) only as bibliographic information. About 50% store authors names as strings and 50% store last name, first name separately. Journal and other sources are stored mostly as both, abbreviation and full journal name. The results give a good impression of the difficulties a operating PublicationBank might expect. In some way PublicationBank will serve GUIDs and to do this it will need to know e.g. Author, Year and source/ journal to find the appropriate GUID. So the question is can this information easily be extracted from the existing dbs to formulate a query by participating institutions? The other reason why I cretaed the survey was to find out whether the existing dbs can be used as initial sources contributing their entries to PublicationBank to have an initial set of citations. The good point is that most institutions store the complete set of bib info, however it might be a bit difficult to e.g. extract the volume or issue information when the db is not normalized and the info is stored as a string. Same difficulties may occur for author names, this depends on how the string is stored (Last Name, Initial, Last Name, Initial would be difficult..). Important is that both, abbreviations as well as complete citations are stored in the dbs. In summary it can be said that it will probably not be easy to create a initial citation pool for PublicationBank because the current status of bib data is too heterogenous. It will also be difficult for some of the dbs to extract the necessary info from their dbs to be able to effectively use PublicationBank. But as I said this depends on the detailled way their data is stored. Some might need to put some additional efforts on their dbs, but most surely could rightaway start to query PublicationBank. -- What should PublicationBank be: 1) A service provider for existing taxonomic databases to ease the management of bibliographic data. It allows client databases to check their existing bib entries against PublicationBank and to retrieve a GUID. 2) An external, common bibliographic management system for existing taxonomic databases. It allows client databases to concentrate on taxonomic information, thus to leave all bib related data management at PublicationBank. Client dbs would internally use only GUIDs, no bibliographic module needed anymore. 3) to be _the_ bibliographic ressource for biodiversity relevant publications 1) and 2) included but major(curatorial/librarian) additional efforts are made to analyze, find and store relevant publications. -- What is "relevant" bibliographic data 1) Gets relevant on demand -The literature/citations which is already stored (and will be stored in the future) in taxonomic database using PublicationBank see above scenarios 19 and 2) 2) Is "per se" relevant - Any literature which treats biodiversity/ taxonomy etc. relevant topics -- What gets an GUID? 1) Abbreviations (such as Brummit & Powell) 2) Copmplete citations 3) Both -- Granularity of biblographic data (Roger Hyam): 1)LSID for the Journal/Book 2)LSID for the volume 3)LSID for the part 4)LSID for the article 5)LSID for the actual description on page 15. I assume all except 5 are usually treated by bibliographic databases? -- Where to get GUIDs from? 1) CrossRef / Journals (DOIs) 2) Citation Databases (PubMed.. ISI, Georef) 3) Library digitization efforts (Animal base, Google books, ) 4) Assign our own PublicationBank LSID (e.g. as preliminary GUIDs) ... -- Which ressources are already there? 1) CrossRef and other bibliographic GUID resolver services 2) IPNI and uBIOS 'author abbreviation resolver' ...know more? some ressources could help but do not use GUIDs (AnimalBase etc), we need to encourage these initiatives to use GUIDs -- Are there initiatives/products which could help or take over the whole thing? 1) Biodiversity Heritage Library Project (http://www.bhl.si.edu/) 2) Natures Connotea project (http://www.connotea.org/) -- Which other people need to be involved? 1) Librarians -- What will be the components of PublicationBank and how will they interact todo best regards and happy Eastern! Robert Dr. Robert Huber WDC-MARE / PANGAEA - www.pangaea.de, www.wdc-mare.org Stratigraphy.net - www.stratigraphy.net _____________________________________________ MARUM - Institute for Marine Environmental Sciences (location) University Bremen Leobener Strasse POP 330 440 28359 Bremen Phone ++49 421 218-65593, Fax ++49 421 218-65505 e-mail rhuber@@wdc-mare.org, robert.huber(a)stratigraphy.net

1 0

[tdwg-tapir] TAPIR searches and entities
by "Döring, Markus" 10 Apr '06

10 Apr '06

Hello, I had a talk with Gregor and the others this week to find out whether TAPIR is suitable for SDD. Apart from the known recusive issue we were concerned about one major search problem I would like to introduce you to: Imagine a simple concept "ontology" with a specimen linked to identifications with a taxon-name and an identifier (person). If I want to do a combined search on the identifier AND the taxon name I actually have 2 ways of asking the query. 1) use the same identification object to do the AND. In SQL this would be: SELECT * FROM specimen s JOIN identification i ON xxx WHERE i.taxon_name = "Abies alba" AND i.identifier="Markus" 2) dont require the identifier to have done the identification of the required name, but to be an independent constraint. In SQL you would use an alias of that table: SELECT * FROM specimen s JOIN identification i1 ON xxx JOIN identification i2 ON xxx WHERE i1.taxon_name = "Abies alba" AND i2.identifier="Markus" This gives different results. And it is a common query in SDD when searching on characters. As far as I can see TAPIR cannot handle this, as a TAPIR request doesnt know about the relations between concept. The entities, classes whatever you would like to call it. A loose list of independent concepts really doesnt seem to work. We might need to know about the class relations/multiplicity at least on a high level. In general this could be taken from an XML Schema as well as OWL, RDFS or alike. Or we could prescribe a TAPIR service what to do in such cases. If a complex AND query is received we could prescribe to resolve that query in way #1 (i think its the more common intention). But then noone would be able to ask questions of type2. Maybe we could discuss this further in the TAG meeting, Session 4: Integration of Existing Technologies with a Core Ontology? I do not have an answer yet to that question, but I wanted to spread the problem before the TAG meeting. Looking forward to meet you all in Edinburgh, Markus

4 3

GUID(LSID)-2 Workshop
by Lee Belbin 05 Apr '06

05 Apr '06

Hi Folks The second GUID workshop is going to be hosted by eSI in Edinburgh June 10-12. As the details emerge, I'll add them to the Wiki- http://wiki.gbif.org/guidwiki/wikka.php?wakka=GUID2Workshop The current game plan is to derive a set of recommendations from the tasks within the Infrastructure and Prototyping Working Groups. It would be good if the Task Coordinators could circulate any recommendations (as dot points) before June 3. This gives us a week for consideration. The second workshop has 4 tasks- 1. Report findings 2. Refine recommendations 3. (Briefly) justify the recommendations (so that future readers could follow the logic) and 4. Design an implementation plan. I've been going through the tasks on the Wiki and note that 9 still do not have a coordinator. A few have a coordinator, but either there hasn't been any activity, or the Wiki hasn't been updated. It would be good if the load could be spread as I know that everyone is busy with their day job. If you know of someone who could advance any of the tasks, please let them loose. Which of these tasks is a real priority and which ones should be dropped or reduced? Infrastructure Working group # Task Coordinator - ---- ----------- 2. LSIDLongTermArchival NONE 3. GUIDRegistrationAuthority NONE 4. GUIDOrphanDatasets NONE 7. GUIDAnnotationAndLinkOut NONE 8. GUIDOutreach NONE 10. LSIDSpecificationReview Ricardo Pereira Prototyping Working Group 1. LSIDResolverForTaxonNamesIPNI Roger Hyam 2. LSIDResolverForSpecimens Steve Perry 4. LSIDResolverForObservations NONE? 7. LSIDResolverMorphbank Greg Riccardi 8. LSIDScalabilityTesting NONE 9. LSIDBasedIntegrationAntsDemo NONE 10. LSIDSEEKTaxonResolutionServer NONE If there is anything that I may be able to do to help, please let me know. Lee Lee Belbin Manager, TDWG Infrastructure Project Email: lee(a)tdwg.org Phone: +61(0)419 374 133

1 0

Re: LSID Software Gap Analysis
by Lee Belbin 05 Apr '06

05 Apr '06

Hi Bob I'm in the process of drafting an e-mail about GUID-2. So far, it looks like the invites are in my hands with Donald and Ricardo playing dead. And I do have you on the list at this stage Bob. I've really appreciated your contributions. I would like to finalise the invitees before April 15 if I can, as that leaves 8 weeks for people to prepare. Cheers, Lee Lee Belbin Manager, TDWG Infrastructure Project Email: lee(a)tdwg.org Phone: +61(0)419 374 133 _____ From: Taxonomic Databases Working Group GUID Project [mailto:TDWG-GUID@LISTSERV.NHM.KU.EDU] On Behalf Of Bob Morris Sent: Wednesday, 5 April 2006 7:56 AM To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: LSID Software Gap Analysis Ricardo. I need to make plans for June. When will I know if I am invited to GUID2? Thanks Bob On 4/4/06, Ricardo Scachetti Pereira < <mailto:ricardo@tdwg.org> ricardo(a)tdwg.org> wrote: Hi all, I wanted to invite you to help with the discussion and outcomes of one of the task groups formed during GUID-1 workshop, the LSIDSoftwareGapAnalysis. (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDSoftwareGapAnalysis <http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDSoftwareGapAnalysis> ). The goal of this group is to perform a gap analysis of LSID software. That is, we want to evaluate what the current situation in terms of available LSID software is, what would be an ideal situation and how to get from former to the later. In more simple terms, we are interested in performing the following tasks: * To describe and evaluate existing LSID software; * To identify missing components, or components that need to be rewritten or refactored; and * To devise a plan to implement, rewrite or refactor these components; We then plan on execute that plan above, probably after GUID2Workshop. I believe now is a good time to start this process because many other GUID task groups have gained invaluable experience in implemented LSID resolvers or are in the process of setting one up. We would like to tap into that experience to identify limitations on the current LSID software packages and identify new components that need to be developed. If you have set up an LSID resolver or have experience with the matter, we would like to know from you: * Besides the existing LSID software, what components did you have to develop to make your LSID resolver work? * What tasks were more time consuming in setting up your LSID resolver? * Have you identified any new components that would have helped you to set up your LSID resolver? Please describe it. * Have you found any components that were hard or ackward to use? What modifications would you propose? * Have you found any problems or bugs in the existing components? Please report them. Please, respond either directly to me, to the list, or add your comments to the respective wiki page (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDSoftwareGapAnalysis). Also, as part of the gap analysis, I started an inventory of LSID software at http://wiki.gbif.org/guidwiki/wikka.php?wakka=LsidSoftwareInventory. Feel free to make chances and additions. Thanks a lot, Ricardo

1 0

Re: LSID Software Gap Analysis
by Roger Hyam 05 Apr '06

05 Apr '06

Hi Kevin, You only really need to use libraries to produce RDF responses to LSID calls if you want to support multiple serializations. There is always the simple template approach. The actual XML serialization of these things is far simpler than your average web page. The getMetadata call behind this lsid: urn:lsid:hyam.net:bsbidemo:123 http://linnaeus.zoology.gla.ac.uk/~rpage/lsid/tester/?q=urn%3Alsid%3Ahyam.n… Is implemented in 122 lines of code (with a loads of whitespace) and no XML libraries or any funny business - would run on any cheap ISP space with PHP support. I wouldn't call it production quality but it could be polished. I am afraid my motto is hack it first then only improve it when you know why it doesn't work - a version of extreme programming I guess. Just my 2 cents worth. Roger Kevin Richards wrote: > Yes I aggree with that Ricardo - "gap" analysis was not the best > choice of words. > > I didnt really have problems using RDF with the Java LSID stack as the > download came with examples of how to use RDF. The biggest problem > here is trying to work out how to correctly create an RDF document > from the index fungorum database I am connecting to (so really more of > a training issue). > > The next problem was when trying to create RDF documents within > Microsoft .NET development projects (this was also during setup of to > the IndexFungorum LSID resolver). There is limited code available for > facilitating the creation of RDF documents for the Microsoft platform > (not a huge issue, as I could just use java code to create them, but > this has platform dependent issues later on). > My thoughts really were to make sure that code and tools are available > to help everyone create RDF documents from their datasets, ensuring > the adoption of the RDF techonology is as easy as possible, and has no > obvious barriers. As Ben pointed out there are quite a lot of tools, > and Java code, for working with RDF, but I think it would be useful if > everyone thought about how they would get their data from the database > to an RDF document to make sure there are no missing components to aid > this process. > > Kevin > > > >>> ricardo(a)TDWG.ORG 5/04/2006 9:42 a.m. >>> > Kevin, > > That is an excellent point, thanks for bringing it up!! > > Yes, I believe we should include RDF into the analysis. We just need > to be careful about the wording, I guess. > > We clearly don't want to perform a gap analysis of all the existing > RDF software. That would be too big of a task for the GUID group. > > In my opinion, we should evaluate: > 1) How well the current LSID server software supports the generation of > metadata responses in RDF; and > 2) What capabilities the LSID client provides for ingestion of RDF. > > Besides that, we can also try to compile a list of RDF toolkits and > try to get evaluations of them, without performing a complete gap > analysis. Some people was asking for links about RDF tools on the > TDWG-TAG mailing list and on the GUID list as well. Take a look: > > http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/2006-March/000063.h… > http://listserv.nhm.ku.edu/cgi-bin/wa.exe?A2=ind0602&L=TDWG-GUID&P=R6382 > <http://listserv.nhm.ku.edu/cgi-bin/wa.exe?A2=ind0602&L=TDWG-GUID&P=R6382> > http://listserv.nhm.ku.edu/cgi-bin/wa.exe?A2=ind0602&L=TDWG-GUID&P=R6104 > <http://listserv.nhm.ku.edu/cgi-bin/wa.exe?A2=ind0602&L=TDWG-GUID&P=R6104> > > So when you mention that it has been difficult to generate RDF, are > you talking about the Java toolkit that you used to set up Index > Fungorum LSID resolver or are you refering to the port of the client and > server stacks to .NET? > > Cheers, > > Ricardo > > > > > Kevin Richards wrote: > > > Ricardo > > > > Do you think this analysis should include a gap analysis of RDF > > software as well , or would it be best to keep this separate? > > I think this is probably a more contentious issue - ie some doubts > > about RDF over XML. I have found setting up an LSID > > resolver/authority reasonably straight forward but trying to implement > > the services using RDF has been a steep learning curve (and limited > > software/tools to help). > > I'll add more later. > > > > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Re: LSID Software Gap Analysis
by Kevin Richards 05 Apr '06

05 Apr '06

No. Thanks for the tip. Kevin >>> vieglais(a)KU.EDU 5/04/2006 10:10 a.m. >>> Hi Kevin, Just curious, did you look at the redland rdf api? Dave V. http://librdf.org/ Kevin Richards said the following on 4/5/2006 10:05 AM: ... > The next problem was when trying to create RDF documents within > Microsoft .NET development projects (this was also during setup of to > the IndexFungorum LSID resolver). There is limited code available for > facilitating the creation of RDF documents for the Microsoft platform > (not a huge issue, as I could just use java code to create them, but > this has platform dependent issues later on). ... ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Software Gap Analysis
by Dave Vieglais 05 Apr '06

05 Apr '06

Hi Kevin, Just curious, did you look at the redland rdf api? Dave V. http://librdf.org/ Kevin Richards said the following on 4/5/2006 10:05 AM: ... > The next problem was when trying to create RDF documents within > Microsoft .NET development projects (this was also during setup of to > the IndexFungorum LSID resolver). There is limited code available for > facilitating the creation of RDF documents for the Microsoft platform > (not a huge issue, as I could just use java code to create them, but > this has platform dependent issues later on). ...

1 0

Re: LSID Software Gap Analysis
by Kevin Richards 05 Apr '06

05 Apr '06

Yes I aggree with that Ricardo - "gap" analysis was not the best choice of words. I didnt really have problems using RDF with the Java LSID stack as the download came with examples of how to use RDF. The biggest problem here is trying to work out how to correctly create an RDF document from the index fungorum database I am connecting to (so really more of a training issue). The next problem was when trying to create RDF documents within Microsoft .NET development projects (this was also during setup of to the IndexFungorum LSID resolver). There is limited code available for facilitating the creation of RDF documents for the Microsoft platform (not a huge issue, as I could just use java code to create them, but this has platform dependent issues later on). My thoughts really were to make sure that code and tools are available to help everyone create RDF documents from their datasets, ensuring the adoption of the RDF techonology is as easy as possible, and has no obvious barriers. As Ben pointed out there are quite a lot of tools, and Java code, for working with RDF, but I think it would be useful if everyone thought about how they would get their data from the database to an RDF document to make sure there are no missing components to aid this process. Kevin >>> ricardo(a)TDWG.ORG 5/04/2006 9:42 a.m. >>> Kevin, That is an excellent point, thanks for bringing it up!! Yes, I believe we should include RDF into the analysis. We just need to be careful about the wording, I guess. We clearly don't want to perform a gap analysis of all the existing RDF software. That would be too big of a task for the GUID group. In my opinion, we should evaluate: 1) How well the current LSID server software supports the generation of metadata responses in RDF; and 2) What capabilities the LSID client provides for ingestion of RDF. Besides that, we can also try to compile a list of RDF toolkits and try to get evaluations of them, without performing a complete gap analysis. Some people was asking for links about RDF tools on the TDWG-TAG mailing list and on the GUID list as well. Take a look: http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/2006-March/000063.h… http://listserv.nhm.ku.edu/cgi-bin/wa.exe?A2=ind0602&L=TDWG-GUID&P=R6382 http://listserv.nhm.ku.edu/cgi-bin/wa.exe?A2=ind0602&L=TDWG-GUID&P=R6104 So when you mention that it has been difficult to generate RDF, are you talking about the Java toolkit that you used to set up Index Fungorum LSID resolver or are you refering to the port of the client and server stacks to .NET? Cheers, Ricardo Kevin Richards wrote: > Ricardo > > Do you think this analysis should include a gap analysis of RDF > software as well , or would it be best to keep this separate? > I think this is probably a more contentious issue - ie some doubts > about RDF over XML. I have found setting up an LSID > resolver/authority reasonably straight forward but trying to implement > the services using RDF has been a steep learning curve (and limited > software/tools to help). > I'll add more later. > > 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: LSID Software Gap Analysis
by Kevin Richards 05 Apr '06

05 Apr '06

Ricardo Do you think this analysis should include a gap analysis of RDF software as well , or would it be best to keep this separate? I think this is probably a more contentious issue - ie some doubts about RDF over XML. I have found setting up an LSID resolver/authority reasonably straight forward but trying to implement the services using RDF has been a steep learning curve (and limited software/tools to help). I'll add more later. Kevin >>> ricardo(a)TDWG.ORG 5/04/2006 6:49 a.m. >>> Hi all, I wanted to invite you to help with the discussion and outcomes of one of the task groups formed during GUID-1 workshop, the LSIDSoftwareGapAnalysis. (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDSoftwareGapAnalysis). The goal of this group is to perform a gap analysis of LSID software. That is, we want to evaluate what the current situation in terms of available LSID software is, what would be an ideal situation and how to get from former to the later. In more simple terms, we are interested in performing the following tasks: * To describe and evaluate existing LSID software; * To identify missing components, or components that need to be rewritten or refactored; and * To devise a plan to implement, rewrite or refactor these components; We then plan on execute that plan above, probably after GUID2Workshop. I believe now is a good time to start this process because many other GUID task groups have gained invaluable experience in implemented LSID resolvers or are in the process of setting one up. We would like to tap into that experience to identify limitations on the current LSID software packages and identify new components that need to be developed. If you have set up an LSID resolver or have experience with the matter, we would like to know from you: * Besides the existing LSID software, what components did you have to develop to make your LSID resolver work? * What tasks were more time consuming in setting up your LSID resolver? * Have you identified any new components that would have helped you to set up your LSID resolver? Please describe it. * Have you found any components that were hard or ackward to use? What modifications would you propose? * Have you found any problems or bugs in the existing components? Please report them. Please, respond either directly to me, to the list, or add your comments to the respective wiki page (http://wiki.gbif.org/guidwiki/wikka.php?wakka=LSIDSoftwareGapAnalysis). Also, as part of the gap analysis, I started an inventory of LSID software at http://wiki.gbif.org/guidwiki/wikka.php?wakka=LsidSoftwareInventory. Feel free to make chances and additions. Thanks a lot, Ricardo ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 Software Gap Analysis
by Ricardo Scachetti Pereira 04 Apr '06

04 Apr '06

Kevin, That is an excellent point, thanks for bringing it up!! Yes, I believe we should include RDF into the analysis. We just need to be careful about the wording, I guess. We clearly don't want to perform a gap analysis of all the existing RDF software. That would be too big of a task for the GUID group. In my opinion, we should evaluate: 1) How well the current LSID server software supports the generation of metadata responses in RDF; and 2) What capabilities the LSID client provides for ingestion of RDF. Besides that, we can also try to compile a list of RDF toolkits and try to get evaluations of them, without performing a complete gap analysis. Some people was asking for links about RDF tools on the TDWG-TAG mailing list and on the GUID list as well. Take a look: http://lists.tdwg.org/pipermail/tdwg-tag_lists.tdwg.org/2006-March/000063.h… http://listserv.nhm.ku.edu/cgi-bin/wa.exe?A2=ind0602&L=TDWG-GUID&P=R6382 http://listserv.nhm.ku.edu/cgi-bin/wa.exe?A2=ind0602&L=TDWG-GUID&P=R6104 So when you mention that it has been difficult to generate RDF, are you talking about the Java toolkit that you used to set up Index Fungorum LSID resolver or are you refering to the port of the client and server stacks to .NET? Cheers, Ricardo Kevin Richards wrote: > Ricardo > > Do you think this analysis should include a gap analysis of RDF > software as well , or would it be best to keep this separate? > I think this is probably a more contentious issue - ie some doubts > about RDF over XML. I have found setting up an LSID > resolver/authority reasonably straight forward but trying to implement > the services using RDF has been a steep learning curve (and limited > software/tools to help). > I'll add more later. > > Kevin >

1 0