September 2006 - tdwg-tag - lists.tdwg.org

Re: [tdwg-tag] Re: [Tdwg-guid] Jena examples?
by Kevin Richards 26 Sep '06

26 Sep '06

My only thought is that it seems a bit like a hack and may be too restrictive when trying to categorise classes. Ie it looks like you intend to have ALL RDF classes under the namespace http://rs.tdwg.org/ontology/ (correct me if I am wrong). This will result in a huge list of classes at the one level, and hence, again diminishing the human readability of the ontology. I wouldnt know, but it sounds like it also might cause ontology management headaches later on? Kevin >>> Roger Hyam <roger(a)tdwg.org> 09/26/06 8:49 PM >>> Hi Everyone, In the not very comforting words of software vendors these are "known issues" and will be resolved in the next release ;) But seriously.The namespaces in the TCS names vocabulary do not resolve because we didn't have a policy at that time. The use if entity references was 'borrowed' from an example (probably Protege output) and I wouldn't mind doing away with it. I have been thinking long and hard about the namespace issues in the last few weeks and believe I have a solution that I will propose at TDWG St Louis. It would be good to have face to face discussions about it and make a decision there. To briefly summarize: The issue is getting a namespace convention that will work across technologies. Suppose we want to serve data in a technology that "isn't very good at namespaces". As an example - if we were to have separate namespaces for TaxonNames, TaxonConcepts, Specimens, Metadata, GeospatialStuff, Collections and we wanted to validate a document using XML Schema that contained all these things it would require 6 independent schemas each with it's own target namespace. If you have ever tried to debug something like this you will know what total madness it is. We can't just abandon XML Schema because it would rule out not only our existing technologies but GML and probably others... It may also be desirable to express our ontology in things that aren't even XML. The only solution I can think is that for the TDWG Ontology we should have a single formal namespace of: http://rs.tdwg.org/ontology/ Within the ontology we have a convention for concepts that goes like this. A class would be: http://rs.tdwg.org/ontology/tdwg123_MyClass where 123 is the internal id of the class and MyClass is the class name A property in MyClass would be: http://rs.tdwg.org/ontology/tdwg123_myProperty where 123 is the *class* id not the property id and myProperty is the property name. An instance would be http://rs.tdwg.org/ontology/tdwg123_789 where 123 is the *class* id and 789 is the instance id (there is nothing stable about an instance that we could use as an identifier unless we force a label property and make it immutable). In a way this is using the part before the _ as a pseudo namespace. I think this hits the balance between something that is technology independent and something that will produce reasonably human readable documents. It is radical which is why I thought it would be good to talk about it. Any one got an alternative? We have to have a solution for this by the end of the St Louis meeting as it is critical path for ontology work. Most grateful for you patience and any thoughts you have. Roger Sally Hinchcliffe wrote: > Hi Steve /all > > We took that syntax straight from Roger's RDF/TCS examples. I think > Roger was going to do more work on tidying up those sorts of loose > ends. I have to admit that my knowledge of RDF and particularly RDFS > is pretty superficial > > We can switch to either the shorter format or the safer fully > qualified URI - what do people think would be better? > > Sally > > > >> By the way, the IPNI example you cite has an error: >> >> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> >> >> Many RDF/XML parsers will see &tn; as an entity which cannot be >> resolved. Since I don't have a copy of the ontology (and >> http://tdwg.org/2006/03/12/TaxonNames does not resolve), I can only take >> a guess that it should look something like: >> >> <tn:nomenclaturalCode rdf:resource="tn:botanical" /> >> >> However, using XML namespace prefixes in resource references inside >> RDF/XML documents tends to cause problems because not all RDF/XML >> parsers are smart enough to dereference the namespace prefix and build a >> fully-qualified resource URI. A safer form of the above would be the >> fully qualified resource URI which looks like: >> >> <tn:nomenclaturalCode rdf:resource="http://tdwg.org/2006/03/12/TaxonNames/botanical" /> >> >> >> -Steve >> >> > *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk > > > _______________________________________________ > TDWG-GUID mailing list > TDWG-GUID(a)mailman.nhm.ku.edu > http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 ------------------------------------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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: [Tdwg-guid] [tdwg-tag] Re: Jena examples?
by Kevin Richards 26 Sep '06

26 Sep '06

My only thought is that it seems a bit like a hack and may be too restrictive when trying to categorise classes. Ie it looks like you intend to have ALL RDF classes under the namespace http://rs.tdwg.org/ontology/ (correct me if I am wrong). This will result in a huge list of classes at the one level, and hence, again diminishing the human readability of the ontology. I wouldnt know, but it sounds like it also might cause ontology management headaches later on? Kevin >>> Roger Hyam <roger(a)tdwg.org> 09/26/06 8:49 PM >>> Hi Everyone, In the not very comforting words of software vendors these are "known issues" and will be resolved in the next release ;) But seriously.The namespaces in the TCS names vocabulary do not resolve because we didn't have a policy at that time. The use if entity references was 'borrowed' from an example (probably Protege output) and I wouldn't mind doing away with it. I have been thinking long and hard about the namespace issues in the last few weeks and believe I have a solution that I will propose at TDWG St Louis. It would be good to have face to face discussions about it and make a decision there. To briefly summarize: The issue is getting a namespace convention that will work across technologies. Suppose we want to serve data in a technology that "isn't very good at namespaces". As an example - if we were to have separate namespaces for TaxonNames, TaxonConcepts, Specimens, Metadata, GeospatialStuff, Collections and we wanted to validate a document using XML Schema that contained all these things it would require 6 independent schemas each with it's own target namespace. If you have ever tried to debug something like this you will know what total madness it is. We can't just abandon XML Schema because it would rule out not only our existing technologies but GML and probably others... It may also be desirable to express our ontology in things that aren't even XML. The only solution I can think is that for the TDWG Ontology we should have a single formal namespace of: http://rs.tdwg.org/ontology/ Within the ontology we have a convention for concepts that goes like this. A class would be: http://rs.tdwg.org/ontology/tdwg123_MyClass where 123 is the internal id of the class and MyClass is the class name A property in MyClass would be: http://rs.tdwg.org/ontology/tdwg123_myProperty where 123 is the *class* id not the property id and myProperty is the property name. An instance would be http://rs.tdwg.org/ontology/tdwg123_789 where 123 is the *class* id and 789 is the instance id (there is nothing stable about an instance that we could use as an identifier unless we force a label property and make it immutable). In a way this is using the part before the _ as a pseudo namespace. I think this hits the balance between something that is technology independent and something that will produce reasonably human readable documents. It is radical which is why I thought it would be good to talk about it. Any one got an alternative? We have to have a solution for this by the end of the St Louis meeting as it is critical path for ontology work. Most grateful for you patience and any thoughts you have. Roger Sally Hinchcliffe wrote: > Hi Steve /all > > We took that syntax straight from Roger's RDF/TCS examples. I think > Roger was going to do more work on tidying up those sorts of loose > ends. I have to admit that my knowledge of RDF and particularly RDFS > is pretty superficial > > We can switch to either the shorter format or the safer fully > qualified URI - what do people think would be better? > > Sally > > > >> By the way, the IPNI example you cite has an error: >> >> <tn:nomenclaturalCode rdf:resource="&tn;#botanical" /> >> >> Many RDF/XML parsers will see &tn; as an entity which cannot be >> resolved. Since I don't have a copy of the ontology (and >> http://tdwg.org/2006/03/12/TaxonNames does not resolve), I can only take >> a guess that it should look something like: >> >> <tn:nomenclaturalCode rdf:resource="tn:botanical" /> >> >> However, using XML namespace prefixes in resource references inside >> RDF/XML documents tends to cause problems because not all RDF/XML >> parsers are smart enough to dereference the namespace prefix and build a >> fully-qualified resource URI. A safer form of the above would be the >> fully qualified resource URI which looks like: >> >> <tn:nomenclaturalCode rdf:resource="http://tdwg.org/2006/03/12/TaxonNames/botanical" /> >> >> >> -Steve >> >> > *** Sally Hinchcliffe > *** Computer section, Royal Botanic Gardens, Kew > *** tel: +44 (0)20 8332 5708 > *** S.Hinchcliffe(a)rbgkew.org.uk > > > _______________________________________________ > TDWG-GUID mailing list > TDWG-GUID(a)mailman.nhm.ku.edu > http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 ------------------------------------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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

[tdwg-tapir] Schema modification: r557 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 25 Sep '06

25 Sep '06

Author: renato Date: 2006-09-25 19:44:58 +0200 (Mon, 25 Sep 2006) New Revision: 557 Modified: trunk/protocol/tapir.xsd Log: Changed dct:bibliographicCitation, dc:rights and dc:subject to be optional elements. Modified: trunk/protocol/tapir.xsd =================================================================== --- trunk/protocol/tapir.xsd 2006-09-25 17:33:48 UTC (rev 556) +++ trunk/protocol/tapir.xsd 2006-09-25 17:44:58 UTC (rev 557) @@ -1522,7 +1522,7 @@ <xsd:documentation></xsd:documentation> </xsd:annotation> </xsd:element> - <xsd:element ref="dc:subject"> + <xsd:element ref="dc:subject" minOccurs="0"> <xsd:annotation> <xsd:documentation>Subject and Keywords.Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic @@ -1531,7 +1531,7 @@ classification scheme</xsd:documentation> </xsd:annotation> </xsd:element> - <xsd:element ref="dct:bibliographicCitation"> + <xsd:element ref="dct:bibliographicCitation" minOccurs="0"> <xsd:annotation> <xsd:documentation>Recommended practice is to include sufficient bibliographic detail to identify the resource as @@ -1539,7 +1539,7 @@ citation is in a standard form.</xsd:documentation> </xsd:annotation> </xsd:element> - <xsd:element ref="dc:rights"> + <xsd:element ref="dc:rights" minOccurs="0"> <xsd:annotation> <xsd:documentation>Information about who can access the resource or an indication of its security status.</xsd:documentation>

1 0

[tdwg-tapir] Schema modification: r556 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 25 Sep '06

25 Sep '06

Author: renato Date: 2006-09-25 19:33:48 +0200 (Mon, 25 Sep 2006) New Revision: 556 Modified: trunk/protocol/tapir.xsd Log: Language handling is now uniform across the protocol by using only the xml:lang attribute: * Removed global "lang" attribute definition. * Changed entityInformationType to reference xml:lang. * Included optional attribute xml:lang in metadataResultType so that a default language can be assigned to an entire document. Modified: trunk/protocol/tapir.xsd =================================================================== --- trunk/protocol/tapir.xsd 2006-09-11 09:20:56 UTC (rev 555) +++ trunk/protocol/tapir.xsd 2006-09-25 17:33:48 UTC (rev 556) @@ -66,16 +66,6 @@ base="xsd:string"/> </xsd:simpleType>  -  -  - <xsd:attribute name="lang" type="xsd:language"> - <xsd:annotation> - <xsd:documentation>Attribute for language identification. This attribute was globally - declared to be referenced by others, and therefore simulate the same way of using - xml:lang (in case it could be necessary to switch to xml:lang in the future).</xsd:documentation> - </xsd:annotation> - </xsd:attribute> -    <xsd:complexType name="externalResourceType"> @@ -1581,6 +1571,7 @@ </xsd:element> <xsd:element ref="custom" minOccurs="0"/> </xsd:sequence> + <xsd:attribute ref="xml:lang" use="optional"/> </xsd:complexType> <xsd:complexType name="relatedEntityInformationType"> <xsd:annotation> @@ -1676,7 +1667,7 @@ </xsd:element> <xsd:element ref="custom" minOccurs="0"/> </xsd:sequence> - <xsd:attribute ref="lang"/> + <xsd:attribute ref="xml:lang" use="optional"/> </xsd:complexType>  <xsd:element name="inventory" type="inventoryResultType" />

1 0

TAG meetings at St Louis
by Roger Hyam 25 Sep '06

25 Sep '06

Folks, I have had positive responses from a few people off list about arranging a get together to discuss high level issues (or just to touch base) at St Louis so I will try and arrange something within the schedule. Please let me know if there is anything you are particularly keen to include. All the best, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

2 1

[Tdwg-guid] Zoobank LSID Service
by peter.hollas＠thomson.com 25 Sep '06

25 Sep '06

Hi everyone, I am in the process of putting together the LSID service component of Zoobank.org, after a few initial hiccups and difficulties I have a basic service up and running in the development environment. Now I have arrived at the contentious issue of what data/metadata to return and in which flavour. I have a few questions... 1. What format should I return the metadata response in? From discussions with Roger it seems appropriate to go with RDF/TCS for the metadata reponse. Would this be a good way to go, and does anyone have any static examples of such a response? 2. If a Data service were implemented, should the response simply be the LSID or the taxon name as we don't currently hold any holotype photos etc. 2. Is there any standard scheme for LSID discovery? i.e. Would it be a good/bad idea to extend the LSID service to allow machine queries of LSIDs by taxon name rather than discovering them through the web interface? Any comments and suggestions are very welcome! Regards, Peter. Peter Hollas MSc BSc(hons) (Peter.Hollas(a)thomson.com) Software Engineer / Systems Administrator Thomson Zoological Innovation Centre York Science Park Heslington York YO10 5DG Tel: 01904-435113 Fax: 01904-435114

6 7

[Fwd: [seek-kr-sms] Modeling large scale ontologies in OWL: Unmet needs (fwd)]
by Bob Morris 22 Sep '06

22 Sep '06

Several of you have seen this interesting piece at its point of origin -------- Original Message -------- Subject: [seek-kr-sms] Modeling large scale ontologies in OWL: Unmet needs (fwd) Date: Thu, 21 Sep 2006 09:23:43 -0700 (PDT) From: Shawn Bowers <sbowers(a)ucdavis.edu> To: seek-kr-sms(a)ecoinformatics.org This is a good explanation of a current problem in OWL, and relevant to SEEK KR/SMS. This problem haso been addressed in OWL 1.1 via qualified cardinality restrictions. Interestingly, I believe OBOE was recently criticized for using the same property name with two distinct domains (the "hasSubject" property), however, this email argues that this is often a useful approach. -shawn ---------- Forwarded message ---------- Date: Wed, 20 Sep 2006 16:25:33 +0200 From: David Decraene <David(a)landcglobal.com> To: public-semweb-lifesci(a)w3.org Subject: Modeling large scale ontologies in OWL: Unmet needs Resent-Date: Thu, 21 Sep 2006 04:57:52 +0000 Resent-From: public-semweb-lifesci(a)w3.org I would like to bring to discussion/debate what I believe is a flaw in the design of the OWL web ontology language, at least if OWL will also serve a purpose in representing large scale ontologies. I'll start the discussion by listing some general examples of OWL 'properties' from the OWL tutorials: HasFinger, HasSpouse, HasTopping, HasVintageYear, HasBrother, HasParent, HasUncle, HasMaker, HasSugar, etc ... We have a problem with this, seeing that these are not properties, but concatenated Property - Target combinations. For a large scale (formal) ontology, imagine the amount of duplication would occur if we would treat every parthood relation as such; HasFinger, HasToe, HasNail, HasHair, HasSkin, HasVein, HasCell, HasBone, HasMuscle, etc... In large scale ontologies, one link should suffice, HasPart, and whether the part is a finger, toe, nail, muscle or anything else is not a task for the property to describe, but for the target, e.g. the ISA hierarchy where the respective parts are situated in. Now this might seem trivial, and it might seem that OWL allows the second approach as well, but the fact is that OWL propagates this line of thought in how properties should be constructed and restricted: Some of the existing expressivity of OWL (mainly: assigning cardinalities) can not be applied if we decide to generalize property types (formal modeling) to represent the nature of the relation, e.g. without a description of what the target is (which is a task for the target hierarchy). Lost expressivity: cardinality. In OWL optional properties can be used by setting mincardinality to 0: <Hand> Has6thFinger mincardinality 0 See how in the above example we do NOT state a target. As a matter of fact the above named property only has a meaning when the range is specified, in this case the range might be <6th finger>. So we can use optional properties, but only if we create a unique property for every property - target combination. In formal ontology you could express this relation on a general level of parthood: <Hand> HasPart <6thfinger>, cardinality 0. This is not possible in OWL. In OWL absence of properties can be modeled by setting cardinality to 0: <Undiagnosed hyperbilirubinemia> IsDiagnosisParticipant cardinality 0 <Untreated hyperbilirubinemia> IsTreatmentParticipant cardinality 0 Again in these examples we do NOT state the target, and again these above stated examples might be referring to anything, the only way we (and a reasoner) are able to figure that the properties are about <Diagnosis> and <Treatment> is if we set the range of those properties as such. In formal ontology you would express this relation on a general level of participation: <Undiagnosed hyperbilirubinemia> IsParticipantOf <Diagnosis> Cardinality 0 <Untreated hyperbilirubinemia> IsParticipantOf <Treatment> Cardinality 0 Conclusion: OWL offers great expressivity, but only IF we use the above mentioned approach of proliferating redundant properties at a large scale. This is not a luxury we have in (formal) modeling of large scale ontologies. As an example, the core domain of LinkBase (our inhouse formal, medicine-oriented ontology) exists of about 700.000 concepts (classes) which are related to each other with more than 700.000 relation instantiations. The OWL approach would lead to hundred thousands of properties, which in many ways would duplicate the classhierarchy. It would be great to receive some feedback on this matter. David Decraene PH.D. BioMedical sciences/Ontology modeller. Language and Computing _______________________________________________ Seek-kr-sms mailing list Seek-kr-sms(a)ecoinformatics.org http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/seek-kr-sms -- Robert A. Morris Professor of Computer Science UMASS-Boston ram(a)cs.umb.edu http://www.cs.umb.edu/efg http://www.cs.umb.edu/~ram phone (+1)617 287 6466

2 1

TAG at the 2006 TDWG meeting in St Louis.
by Roger Hyam 21 Sep '06

21 Sep '06

Fellow TAG Members, As I am sure you are aware the 2006 TDWG meeting is between 15 and 22 October in St Louis, Missouri. http://tdwg2006.tdwg.org/ A number of us will be attending the meeting and participating in various ways. Just about every paper that will be presented will have some relevance to the TAG and so I have not attempted to schedule a specific TAG session although I will be presenting the TAG road map and proposing a method of managing the TDWG Ontology. Jessie will be proposing the TDWG Core ontology. I am sure we will find a great deal to talk about! It might be useful if we could identify a list of points that it would be good to discuss as a group during break out sessions. This list may develop through time depending on what is presented at the meeting. We don't want things on the list that are covered in formal sessions and we can't assume that everyone will be able to attend any break out session but it may be useful to have semi-formal meetings over coffee or beer. What do you think? Would this be useful? Shall I set up a wiki page for Birds-of-a-feather TAG sessions? All the best, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Another reason why RDF is cool
by Roderic Page 20 Sep '06

20 Sep '06

I know that there is some scepticism about RDF, so I thought I'd relate an experience I had yesterday at The Natural History Museum in London. A colleague of mine has often complained about how hard it is to get his data (and data others have) into a useful form for the web, and that efforts such as the Semantic Web only seem to make this harder. So, as an experiment, I attempted to get some information about an ant image into a local triple store. This involved putting some triples in a table using EditGrid (an online spreadsheet), grabbing the XML, converting it to RDF, and importing that into the triple store. See here for details: http://semant.blogspot.com/2006/09/adding-triples-using-editgrid.html. The bottom line is that it was trivially easy to go from a spreadsheet to a triple store, and hence add new information about this ant. Writing it up in the blog took as long as the actual work. This particular example concerns one image harvested from the web. Things like adding distribution records in bulk would be even easier. So, my question is this: is there anything other than RDF that can make this as straightforward as it is? If so, I'd love to hear it... Regards Rod ------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page(a)bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

5 4

Re: [Tdwg-guid] IODP paleontology meeting and LSID
by Kevin Richards 20 Sep '06

20 Sep '06

Excellent. IODP sounds like an interesting project. I will just confirm that Index Fungorum is using the TCS-RDF schema. You can see an example by following this url: http://194.203.77.68/authority/metadata/?lsid=urn:lsid:indexfungorum.org:na… It is in the middle of being changed so doesnt resolve using the standard process at present - but is not far away. If you have LSID Launchpad installed: - browse to lsidres:config/general.htm - go to Edit Authorities - add an authority for indexfungorum.org, putting http://194.203.77.68/authority/ in the host box. then enter lsidres:urn:lsid:indexfungorum.org:names:213649 into your browser. This should display some nicely formatted RDF metadata. I will also dig out my notes for the tutorial I will give at TDWG and sen dthem to you. Kevin >>> Roger Hyam <roger(a)tdwg.org> 20/09/2006 1:24 a.m. >>> Hi Robert, I think some of this falls into my camp so I will answer what I can. I am sure others will set me right. The IPNI and IF have both demonstrated LSID resolvers and I believe Zoobank are keen to move in that direction. The RDF vocabulary of TCS used by IPNI and IF is pretty stable but needs to be integrated into the core TDWG ontology which will no doubt be discussed at TDWG in St Louis in October. I hope I can demonstrate a system for bringing unity here. I certainly believe that TDWG should be able to provide the taxonomic and nomenclatural semantics for IODP. The big question is a service going from <SomeNameString> to <List of LSIDs of Possible Names> to <List of Possible Taxa>. Because of cross nomenclatural code homonyms (your problem name string could be an animal, vegetable or virus) this is not solved by individual nomenclators alone there needs to be an indexing service to provide the look up table. uBio or GBIF look like good candidates for supplying this kind of services but there is no reason why there couldn't be many - depending on who has the best algorithm this week. Anyone else want to add to this? Roger Robert Huber wrote: > Dear all, > > I was invited to attend the IODP Paleontology meeting on taxonomic > dictionaries and control lists end of september in Houston, USA. > The IODP (Integrated Ocean Drilling Program)is one of the most > important international earth science projects. http://iodp.org. > > IODP is currently evaluating new technologies for its data and > information management. And one hot topic for its paleontology > and biostratigraphy work is ..having control on taxonomic names.. > I think LSIDs could be very interseting for IODP if they could use > some kind of a 'reverse lookup', resolving LSIDs for names. > > I was asked to give a short presentation on GUIDS/LSID and I > thought maybe one of you already has some interesting material to > show? Any help is welcome! > > Btw. are there are any exciting news since summer? I am especially > interested in: > -how is the RDF/TCS thing evolving -> standardised metadata? > -how have the nomenclators been proceeding? I heard e.g. about the > ZooBank prototype any LSID plans for that yet? > -DarwinCore and GBIF.. is there a way to resolve LSID from names? > > best regards, > 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(a)wdc-mare.org, robert.huber(a)stratigraphy.net > > _______________________________________________ > TDWG-GUID mailing list > TDWG-GUID(a)mailman.nhm.ku.edu > http://mailman.nhm.ku.edu/mailman/listinfo/tdwg-guid > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 ------------------------------------- _______________________________________________ TDWG-GUID mailing list TDWG-GUID(a)mailman.nhm.ku.edu http://mailman.nhm.ku.edu/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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3 2