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

[tdwg-tapir] Schema modification: r520 - trunk/protocol/examples
by tdwg-tapir＠lists.tdwg.org 28 Apr '06

28 Apr '06

Author: javier Date: 2006-04-29 00:13:05 +0200 (Sat, 29 Apr 2006) New Revision: 520 Added: trunk/protocol/examples/schema_used_in_output_model.xsd trunk/protocol/examples/search_request.xml trunk/protocol/examples/search_response.xml Log: search example added Added: trunk/protocol/examples/schema_used_in_output_model.xsd =================================================================== --- trunk/protocol/examples/schema_used_in_output_model.xsd 2006-04-28 21:38:03 UTC (rev 519) +++ trunk/protocol/examples/schema_used_in_output_model.xsd 2006-04-28 22:13:05 UTC (rev 520) @@ -0,0 +1,36 @@ +<?xml version="1.0" encoding="UTF-8"?> +<xsd:schema targetNamespace="http://example.net/simple_specimen" xmlns:xsd="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" attributeFormDefault="unqualified"> + <xsd:element name="dataset"> + <xsd:complexType> + <xsd:sequence> + <xsd:element name="specimen" minOccurs="0" maxOccurs="unbounded"> + <xsd:complexType> + <xsd:sequence> + <xsd:element name="identification" maxOccurs="unbounded" minOccurs="0"> + <xsd:complexType> + <xsd:sequence> + <xsd:element name="name"> + <xsd:complexType> + <xsd:simpleContent> + <xsd:extension base="xsd:string"> + <xsd:attribute name="family" type="xsd:string" + /> + </xsd:extension> + </xsd:simpleContent> + </xsd:complexType> + </xsd:element> + <xsd:element name="identifier" type="xsd:string" minOccurs="0" + /> + </xsd:sequence> + <xsd:attribute name="date" type="xsd:string" use="optional"/> + </xsd:complexType> + </xsd:element> + </xsd:sequence> + <xsd:attribute name="catnum" type="xsd:int" use="required"/> + </xsd:complexType> + </xsd:element> + </xsd:sequence> + </xsd:complexType> + </xsd:element> +</xsd:schema> Added: trunk/protocol/examples/search_request.xml =================================================================== --- trunk/protocol/examples/search_request.xml 2006-04-28 21:38:03 UTC (rev 519) +++ trunk/protocol/examples/search_request.xml 2006-04-28 22:13:05 UTC (rev 520) @@ -0,0 +1,22 @@ +<?xml version="1.0" encoding="UTF-8"?> +<request xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="http://res.tdwg.org/tapir/1.0 + file:/Users/javi/workspace/tapirProtocol/protocol/tapir.xsd"> + <header> + <source accesspoint="http://url_from_client" sendtime="2005-11-11T12:23:56.023+01:00"/> + </header> + <search> + <outputModel + location="http://ww2.biocase.org/svn/tapir/trunk/protocol/examples/output_model1.xml"/> + <filter> + <like> + <concept id="dwc:/ScientificName"/> + <literal value="Luzu*"/> + </like> + </filter> + <orderBy> + <concept id="dwc:/Family"/> + <concept id="dwc:/ScientificName"/> + </orderBy> + </search> +</request> Added: trunk/protocol/examples/search_response.xml =================================================================== --- trunk/protocol/examples/search_response.xml 2006-04-28 21:38:03 UTC (rev 519) +++ trunk/protocol/examples/search_response.xml 2006-04-28 22:13:05 UTC (rev 520) @@ -0,0 +1,26 @@ +<?xml version="1.0" encoding="UTF-8"?> +<response xmlns="http://res.tdwg.org/tapir/1.0" + xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" + xsi:schemaLocation="http://res.tdwg.org/tapir/1.0 + http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + <header> + <source accesspoint="http://url_from_client" sendtime="2005-11-11T12:23:56.023+01:00"/> + </header> + <search> + <dataset xmlns="http://example.net/simple_specimen" + xsi:schemaLocation="http://example.net/simple_specimen + http://ww2.biocase.org/svn/tapir/trunk/protocol/examples/schema_used_in_out…"> + <specimen catnum="234"> + <identification> + <name>Luzula luzuloides</name> + </identification> + </specimen> + <specimen catnum="290"> + <identification> + <name>Luzula alpestris</name> + </identification> + </specimen> + </dataset> + <summary start="0" totalReturned="2"/> + </search> +</response>

1 0

[tdwg-tapir] Schema modification: r519 - trunk/protocol/examples
by tdwg-tapir＠lists.tdwg.org 28 Apr '06

28 Apr '06

Author: javier Date: 2006-04-28 23:38:03 +0200 (Fri, 28 Apr 2006) New Revision: 519 Modified: trunk/protocol/examples/wfs_gcp_output.xml Log: Modified: trunk/protocol/examples/wfs_gcp_output.xml =================================================================== --- trunk/protocol/examples/wfs_gcp_output.xml 2006-04-25 09:01:16 UTC (rev 518) +++ trunk/protocol/examples/wfs_gcp_output.xml 2006-04-28 21:38:03 UTC (rev 519) @@ -27,21 +27,21 @@ <xs:element name="accession" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0"> <xs:complexType> <xs:sequence> - <xs:element name="GermplasmID" type="xs:string" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0"/> - <xs:element name="FAOInstituteCode" type="xs:string" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0" /> - <xs:element name="CollectionName" type="xs:string" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0" /> - <xs:element name="FullScientificName" type="xs:string" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0" /> - <xs:element name="Genus" type="xs:string" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0" /> - <xs:element name="Species" type="xs:string" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0" /> - <xs:element name="CollectingPlace" type="xs:string" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0" /> - <xs:element name="CountryCode" type="xs:string" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0" /> - <xs:element name="LocationGML" targetNamespace="http://www.ipgri.org/schemas/gcp_passport_gml/1.0"> + <xs:element name="GermplasmID" type="xs:string" /> + <xs:element name="FAOInstituteCode" type="xs:string" /> + <xs:element name="CollectionName" type="xs:string" /> + <xs:element name="FullScientificName" type="xs:string" /> + <xs:element name="Genus" type="xs:string" /> + <xs:element name="Species" type="xs:string" /> + <xs:element name="CollectingPlace" type="xs:string" /> + <xs:element name="CountryCode" type="xs:string" /> + <xs:element name="LocationGML"> <xs:complexType> <xs:sequence> <xs:element name="Point" targetNamespace="http://www.opengis.net/gml"> <xs:complexType> <xs:sequence> - <xs:element name="coordinates" targetNamespace="http://www.opengis.net/gml"> + <xs:element name="coordinates"> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string">

1 0

Re: [tdwg-tapir] Summary of TAPIR
by "Döring, Markus" 28 Apr '06

28 Apr '06

Hi, no there isnt. Thats what we are hoping to achieve in during the documentation process. I will try to update the latest proposal page a little and pool all existing infos there. http://ww3.bgbm.org/protocolwiki/LatestProposal But there are up-to-date examples of nearly all operations present that should give you quite a good overview: http://ww3.bgbm.org/protocolwiki/ExampleTapirMessages To improve TAPIR we are currently thinking of how to best express "output models" and maybe use ontologies for that. Besides that TAPIR is fixed. Actually the metadata response was supposed to be reviewed for its practical usefullness - especially by GBIF/Donald. Maybe you want to take a look at it, Roger? search for <xsd:complexType name="metadataResultType"> within: http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd Thanks -- Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Sally Hinchcliffe Gesendet: Freitag, 28. April 2006 12:59 An: tdwg-tapir(a)lists.tdwg.org Betreff: Re: [tdwg-tapir] Summary of TAPIR I'd like this too ... I did look but couldn't find anything (might be my ignorance though) Sally > > Hi Guys, > > I am putting together the TAG-1 meeting report and so far I have too > little on TAPIR. My knowledge largely comes from the original proposal > that Markus and Renato did back in 2004 and it has come a long way since > then. I have followed some but not all of the debates and changes. > > Would it be possible for you to come up with a one page summary of TAPIR > as it is now. Just a high level summary of the protocol, the different > message types/operations and what they consists. Perhaps a paragraph on > the filtering and an indication of the current areas you are working on. > > A page like this on the protocol wiki would be really useful for a whole > bunch of people not just me. Please excuse me if this exists and I just > haven't found it. > > Many thanks, > > Roger > > -- > > ------------------------------------- > Roger Hyam > Technical Architect > Taxonomic Databases Working Group > ------------------------------------- > http://www.tdwg.org > roger(a)tdwg.org > +44 1578 722782 > ------------------------------------- > > > _______________________________________________ > tdwg-tapir mailing list > tdwg-tapir(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

2 1

[tdwg-tapir] Summary of TAPIR
by Roger Hyam 28 Apr '06

28 Apr '06

Hi Guys, I am putting together the TAG-1 meeting report and so far I have too little on TAPIR. My knowledge largely comes from the original proposal that Markus and Renato did back in 2004 and it has come a long way since then. I have followed some but not all of the debates and changes. Would it be possible for you to come up with a one page summary of TAPIR as it is now. Just a high level summary of the protocol, the different message types/operations and what they consists. Perhaps a paragraph on the filtering and an indication of the current areas you are working on. A page like this on the protocol wiki would be really useful for a whole bunch of people not just me. Please excuse me if this exists and I just haven't found it. Many thanks, Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

2 1

Re: [tdwg-tapir] TAPIR Charter
by Charles Copp 28 Apr '06

28 Apr '06

Thanks Lee Good editing job - I accept all your improvements! Charles

1 0

[tdwg-tapir] TAPIR Charter
by Charles Copp 27 Apr '06

27 Apr '06

Dear all Here is a "first cut" at a charter for the TAPIR subgroup. I have put Donald as Convener (because he has the cheque book) but please let me know of any changes you think should be made. I've put a copy on my web site at http://eim.metapath.org/TAPIRsubgroup.htm (if you dont want to read the word document!) Remember this is a first go and I have a bit of catching up to do with what you have been up to! best wishes Charles

1 0

CHRONOS, GNS LSID
by Robert Huber 27 Apr '06

27 Apr '06

Dear all, I found this message on the CHRONOS news pages: 'Taxonomic Synonymy efforts with GNS New Zealand': CHRONOS is implementing URNs (Uniform Resource Names) of taxon names as a means to connect multiple sources of taxonomic data. Initial tests include Neptune, the Mesozoic Planktonic Foraminifera Taxonomic Database, and FRED, the paleontological database of the Geoscience and Nuclear Sciences in New Zealand. Modeled after the Life Science Identifiers (LSID), taxonURNs are unique IDs. http://chronos.org:8080/chronosRSS/jsp/chronosRSS.jsp?mode=rss_2.0&url=55&id =chronos.rss I cc this message to Cinzia and Doug from CHRONOS.. hey, I hope you both are OK? It would be great if you could join the TDWG mailinglist and give us some more details on that effort.. 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@@wdc-mare.org, robert.huber(a)stratigraphy.net This list has been deprecated. Please note the new mailman address: TDWG-GUID(a)mailman.nhm.ku.edu

1 0

Re: Index Fungorum LSID server
by Roger Hyam 27 Apr '06

27 Apr '06

Hi Bob, I don't fully understand them. I don't think they are germane to the exchange. I would imagine that initial shared ontologies would not make such assertions but the consumers of data would be free to make them locally - if they understood them. If they are in shared ontologies the consumers who don't understand them are free to ignore them. This fits with the ontology management concept of agreeing simple things first. Roger Bob Morris wrote: > There are some restrictions on the use of inverseOf if one desires to > remain within OWL-DL. I don't understand them. > > 1. Is there someone reading this who does, and can explain whether > they are germaine to this exchange? > 2. Is it determined that an infrastructure constrained to OWL-DL is or > is not important? [If it is so determined, could someone please point > me at the discussion record?] > > Bob > > > On 4/25/06, *Roderic Page* <r.page(a)bio.gla.ac.uk > <mailto:r.page@bio.gla.ac.uk>> wrote: > > Maybe I'm missing something, but isn't the point of inverseOf that we > don't have to include the link, if follows from the property? > Hence, if > I say specimen x is a part of a taxon concept TC, then it follows that > TC includes x, but I don't need an actual triple saying that. > > Hence, surely the point of ontologies is to free us from making the > direct link? I've only advocated making the link within metadata for a > single provider so we can do something without relying on > ontologies at > this stage. > > In terms of the cost of adding triples, I don't think it will be too > large overall. For example if we have reciprocal links between > specimens and taxa within a source database (i.e., actual triples), I > suspect it won't add too much -- some taxa will have lots of > specimens, > but most will have very few (a power law kind of thing).. > > A good example of this is NCBI, where each sequence may have a link to > the PubMed record for the paper in which they were published, and > each > PubMed record may list all the sequences published in that paper. > > Given that the community hasn't actually built much yet, I'm not > worried about "splits". Let's make some stuff and see what happens -- > "suck it and see" is my maxim. > > Rod > > > On 25 Apr 2006, at 09:35, Roger Hyam wrote: > > > Hi Rod, > > > > (Here I have switched from using reciprocal - which is confusing to > > using the OWL terminology) > > > > I think my point is where do we draw the line in developing workable > > ontologies. What rules do we have as to formally defined > relationships? > > Some properties should have inverseOf > > ( http://www.w3.org/TR/2004/REC-owl-guide-20040210/#inverseOf) > > properties > > and some properties should not - but how do we decide which is > which? > > > > Unless we have rules to apply then every time we want to create > a new > > relationship the community will split over whether the inverseOf > > property should be defined or not. > > > > Any suggestions as to what the rules should be? > > > > Cheers, > > > > Roger > > > > > > Roderic Page wrote: > >> On 24 Apr 2006, at 16:42, Roger Hyam wrote: > >> > >>> > >>> The isBasionymOf property is an interesting one. This does > not exist > >>> in the current vocabulary because it is based on the schema > version > >>> of TCS. The thinking in TCS went that a name that is a > basionym does > >>> not 'know' that it is a basionym and therefore it would be > wrong to > >>> model this as a property of the object. There are many places > where > >>> this might be an issue. Does a specimen know that it is the > type of a > >>> name? Without the name it isn't a type. > >> > >> What about the relationship? From my perspective, it's useful > to know > >> that the original name for Eutypella ventricosa is Valsa > ventricosa, > >> and this is what I model using the predicate "hasBasionym". So > it's a > >> relationship, not a property of an object. > >> > >>> > >>> If you called an LSID for a specimen would you expect to be told > >>> that the specimen was the type of a name? If we use Concise > Bounded > >>> Descriptions ( http://swdev.nokia.com/uriqa/CBD.html) then we > won't > >>> know unless there is a triple with a subject of the specimen > and an > >>> object of the name (i.e. we have an isTypeSpecimenOf property or > >>> similar). But logically where does this stop? We can't add > reciprocal > >>> properties to the object definition for everything that anyone > may > >>> say of it. If I define a taxon with a list of specimens I wouldn't > >>> expect all the specimens to have reciprocal includedInTaxonConcept > >>> links back to my object. It would be impossible in an open system > >>> where some one else may own the record. > >> > >> No, we don't want reciprocal record for everything, but there are > >> cases where it is useful, especially WITHIN a single source. For > >> example, if I have access to all of IndexFungorum then I can run a > >> query that discovers all the names for which Valsa ventricosa > is the > >> basionym. But if I don't have a copy of IndexFungorum, and I'm > relying > >> on the metadata attached to a LSID, then if the metadata for Valsa > >> ventricosa has "isBasionnymOf" tags connecting it to all names for > >> which it is a basionym, I can discover those names. More > importantly, > >> I can infer whether two names are synonyms (e.g., if two names > share > >> Valsa ventricosa as a basionym, then those names are synonyms). > >> Without this, I'm stuck. I think what we need to consider is > whether > >> two names that are synonyms (or whatever relationship we are > >> interested in) are "reachable", that is given the metadata for the > >> names we can go from name A to B and visa versa. This is > related to > >> the concept of a "scutter" : > >> > >> "a scutter is simply a computer program that loads, parses, > interprets > >> and acts upon the contents of a Web of interconnected RDF/XML > >> documents. In this sense it is just a Semantic Web variant on > the old > >> theme of distributed Web indexing, sometimes called a 'harvester', > >> 'spider', or 'robot'. The links between RDF documents are > usually, but > >> not necessarily, expressed using RDF's 'rdfs:seeAlso' > property." (see > >> http://rdfweb.org/topic/Scutter <http://rdfweb.org/topic/Scutter>) > >> > >> So, I think we gain a lot of power if our metadata is sufficiently > >> linked to support a scutter. For example, given metadata for a > PubMed > >> publication, we could get to sequences, via that to taxa (including > >> names in numerous databases via LinkOut), to specimens, and so > on, all > >> via metadata. Indeed, one could let a scutter loose and > aggregate data > >> a la Google -- who needs GBIF anyway ;-). > >> > >> In fact, this would be a cool challenge. Start a scutter and > see what > >> can be retrieved. > >> > >>> > >>> I am thinking aloud here but we have to be very careful in adding > >>> things to vocabularies - even when they seem really useful. > >>> Ultimately if a client wants to know everything about a object > that a > >>> data source has it will have to ask the "Give me all the > things that > >>> refer to X" question. Either that or we have to guarantee that > all > >>> links are always reciprocal - which we can't. > >> > >> No, you don't have to guarantee links are reciprocal, but you > do want > >> some degree of reachability -- that I can get from one object to > >> another. If we aggregate everything into one central repository > (a la > >> Google indexing the web) then this isn't an issue, but it is if we > >> don't. I agree that for some things we don't want to have > reciprocal > >> links -- but I'd suggest we'd need to think seriously about > supporting > >> basic search. As you point out, we need to support the "Give > me all > >> the things that refer to X" question. > >> > >> Ultimately, I think we can't ignore search, or perhaps more > generally > >> "finability" (which depends on things being linked). See the > wonderful > >> book "Ambient Findability" by Peter Morville > >> (http://www.oreilly.com/catalog/ambient/) If we don't make our > stuff > >> findable, we are wasting our time. > >> > >> Rod > >> > >>> > >>> On the other hand things that are in people's data bases that are > >>> easy to pass should perhaps be represented in an ontology - if > they > >>> are useful. > >>> > >>> Well done for another LSID authority Kevin. > >>> > >>> All the best, > >>> > >>> Roger > >>> > >>> > >>> > >>> Kevin Richards wrote:Thanks for those comments Rod. > >>>> As you have seen this is an initial attempt. > >>>> > >>>> > >>>>>> The syntax > >>>>>> > >>>>>> <TaxonNames:hasBasionym> > >>>>>> <rdf:Description > >>>>>> rdf:about="urn:lsid:indexfungorum.org:Names:148860" /> > >>>>>> </TaxonNames:hasBasionym> > >>>>>> > >>>>>> strikes me as odd. > >>>>>> > >>>> This is due to an accidental omission of the RDF entity type > of the > >>>> basionym object. Will fix this. > >>>> > >>>> > >>>>>> I also suggest that urn:lsid:indexfungorum.org:Names:148860 > has a > >>>>>> complementary tag such as > >>>>>> > >>>>>> <TaxonNames:isBasionymOf rdf:resource = > >>>>>> "urn:lsid:indexfungorum.org:Names: 213649" /> > >>>>>> > >>>> Godd idea. The fields are based on the initial implementation of > >>>> TCS-RDF that Roger completed, and as he said, it is not a > complete > >>>> schema at this stage. BTW the reverse RDF pointers can be viewed > >>>> using > >>>> launchpad by going into the launchpad settings and turning on > 'Show > >>>> back > >>>> links'. > >>>> > >>>> > >>>> > >>>>>> The attribute > >>>>>> TaxonNames:nomenclaturalCode=" http://tdwg.org/2006/03/12/ > >>>>>> TaxonNames/ > >>>>>> NomenclaturalCode/#botanical" of the tag > <TaxonNames:TaxonName> is > >>>>>> problematic. Firstly, I don't know why this is an attribute > rather > >>>>>> > >>>> than > >>>> > >>>>>> just another tag, > >>>>>> > >>>> Due to my lack of understanding of RDF and when to use > attributes as > >>>> opposed to tags - I was blindly following an example. > >>>> > >>>> > >>>> > >>>>>> and the URI > >>>>>> > http://tdwg.org/2006/03/12/TaxonNames/NomenclaturalCode/#botanical > >>>>>> returns a 404. If this is just a made up URI then this is > bad -- > >>>>>> > >>>> EVERY > >>>> > >>>>>> URI in an RDF document must be real -- unlike XML schema > where any > >>>>>> > >>>> old > >>>> > >>>>>> rubbish can be used. > >>>>>> > >>>> Also due to the prototyping stage of this 'project'. Will be > fixed > >>>> by > >>>> online TDWG ontologies at some stage I assume? > >>>> > >>>> > >>>>>> <TaxonNames:publishedIn><i>Syll. fung.</i> (Abellini) > >>>>>> <b>1</b>: 148 (1882) (1882)</TaxonNames:publishedIn> > >>>>>> has formatting information (the <i></i> and <b></b> tags). > I think > >>>>>> > >>>> this > >>>> > >>>>>> is in principle a bad thing(TM) > >>>>>> > >>>> We debated this a little and decided to leave the field text the > >>>> same as > >>>> has been returned by other services of IndexFungorum. But > you have > >>>> a > >>>> good point and it is something we will need to discuss further in > >>>> future. > >>>> > >>>> 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 > <http://www.landcareresearch.co.nz> > >>>> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>>> ++++++++ > >>>> > >>>> > >>>> > >>> > >>> > >>> -- > >>> > >>> ------------------------------------- > >>> Roger Hyam > >>> Technical Architect > >>> Taxonomic Databases Working Group > >>> ------------------------------------- > >>> http://www.tdwg.org > >>> roger(a)tdwg.org <mailto:roger@tdwg.org> > >>> +44 1578 722782 > >>> ------------------------------------- > >>> > >>> > >> > ---------------------------------------------------------------------- > > >> ------------------------------------------ > >> > >> 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 <mailto:r.page@bio.gla.ac.uk> > >> web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > >> reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html > <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/ > <http://darwin.zoology.gla.ac.uk/%7Erpage/portal/> > >> Find out what we know about a species: http://ispecies.org > >> Rod's rants on phyloinformatics: http://iphylo.blogspot.com > >> > >> > >> > >> > >> > >> > >> ___________________________________________________________ > >> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide > with > >> voicemail http://uk.messenger.yahoo.com > >> > > > > > > -- > > > > ------------------------------------- > > Roger Hyam > > Technical Architect > > Taxonomic Databases Working Group > > ------------------------------------- > > http://www.tdwg.org > > roger(a)tdwg.org <mailto:roger@tdwg.org> > > +44 1578 722782 > > ------------------------------------- > > > > > ------------------------------------------------------------------------ > ---------------------------------------- > 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 <mailto:r.page@bio.gla.ac.uk> > web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html > <http://taxonomy.zoology.gla.ac.uk/rod/pubs.html> > > Subscribe to Systematic Biology through the Society of Systematic > Biologists Website: http://systematicbiology.org > <http://systematicbiology.org> > Search for taxon names: > http://darwin.zoology.gla.ac.uk/~rpage/portal/ > <http://darwin.zoology.gla.ac.uk/%7Erpage/portal/> > Find out what we know about a species: http://ispecies.org > Rod's rants on phyloinformatics: http://iphylo.blogspot.com > <http://iphylo.blogspot.com> > > > > > ___________________________________________________________ > Yahoo! For Good - Sponsor a London Marathon runner - > http://uk.promotions.yahoo.com/charity/london-marathon > <http://uk.promotions.yahoo.com/charity/london-marathon> > > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Re: Index Fungorum LSID server
by Bob Morris 26 Apr '06

26 Apr '06

There are some restrictions on the use of inverseOf if one desires to remain within OWL-DL. I don't understand them. 1. Is there someone reading this who does, and can explain whether they are germaine to this exchange? 2. Is it determined that an infrastructure constrained to OWL-DL is or is not important? [If it is so determined, could someone please point me at the discussion record?] Bob On 4/25/06, Roderic Page <r.page(a)bio.gla.ac.uk> wrote: > > Maybe I'm missing something, but isn't the point of inverseOf that we > don't have to include the link, if follows from the property? Hence, if > I say specimen x is a part of a taxon concept TC, then it follows that > TC includes x, but I don't need an actual triple saying that. > > Hence, surely the point of ontologies is to free us from making the > direct link? I've only advocated making the link within metadata for a > single provider so we can do something without relying on ontologies at > this stage. > > In terms of the cost of adding triples, I don't think it will be too > large overall. For example if we have reciprocal links between > specimens and taxa within a source database (i.e., actual triples), I > suspect it won't add too much -- some taxa will have lots of specimens, > but most will have very few (a power law kind of thing).. > > A good example of this is NCBI, where each sequence may have a link to > the PubMed record for the paper in which they were published, and each > PubMed record may list all the sequences published in that paper. > > Given that the community hasn't actually built much yet, I'm not > worried about "splits". Let's make some stuff and see what happens -- > "suck it and see" is my maxim. > > Rod > > > On 25 Apr 2006, at 09:35, Roger Hyam wrote: > > > Hi Rod, > > > > (Here I have switched from using reciprocal - which is confusing to > > using the OWL terminology) > > > > I think my point is where do we draw the line in developing workable > > ontologies. What rules do we have as to formally defined relationships? > > Some properties should have inverseOf > > ( http://www.w3.org/TR/2004/REC-owl-guide-20040210/#inverseOf) > > properties > > and some properties should not - but how do we decide which is which? > > > > Unless we have rules to apply then every time we want to create a new > > relationship the community will split over whether the inverseOf > > property should be defined or not. > > > > Any suggestions as to what the rules should be? > > > > Cheers, > > > > Roger > > > > > > Roderic Page wrote: > >> On 24 Apr 2006, at 16:42, Roger Hyam wrote: > >> > >>> > >>> The isBasionymOf property is an interesting one. This does not exist > >>> in the current vocabulary because it is based on the schema version > >>> of TCS. The thinking in TCS went that a name that is a basionym does > >>> not 'know' that it is a basionym and therefore it would be wrong to > >>> model this as a property of the object. There are many places where > >>> this might be an issue. Does a specimen know that it is the type of a > >>> name? Without the name it isn't a type. > >> > >> What about the relationship? From my perspective, it's useful to know > >> that the original name for Eutypella ventricosa is Valsa ventricosa, > >> and this is what I model using the predicate "hasBasionym". So it's a > >> relationship, not a property of an object. > >> > >>> > >>> If you called an LSID for a specimen would you expect to be told > >>> that the specimen was the type of a name? If we use Concise Bounded > >>> Descriptions ( http://swdev.nokia.com/uriqa/CBD.html) then we won't > >>> know unless there is a triple with a subject of the specimen and an > >>> object of the name (i.e. we have an isTypeSpecimenOf property or > >>> similar). But logically where does this stop? We can't add reciprocal > >>> properties to the object definition for everything that anyone may > >>> say of it. If I define a taxon with a list of specimens I wouldn't > >>> expect all the specimens to have reciprocal includedInTaxonConcept > >>> links back to my object. It would be impossible in an open system > >>> where some one else may own the record. > >> > >> No, we don't want reciprocal record for everything, but there are > >> cases where it is useful, especially WITHIN a single source. For > >> example, if I have access to all of IndexFungorum then I can run a > >> query that discovers all the names for which Valsa ventricosa is the > >> basionym. But if I don't have a copy of IndexFungorum, and I'm relying > >> on the metadata attached to a LSID, then if the metadata for Valsa > >> ventricosa has "isBasionnymOf" tags connecting it to all names for > >> which it is a basionym, I can discover those names. More importantly, > >> I can infer whether two names are synonyms (e.g., if two names share > >> Valsa ventricosa as a basionym, then those names are synonyms). > >> Without this, I'm stuck. I think what we need to consider is whether > >> two names that are synonyms (or whatever relationship we are > >> interested in) are "reachable", that is given the metadata for the > >> names we can go from name A to B and visa versa. This is related to > >> the concept of a "scutter" : > >> > >> "a scutter is simply a computer program that loads, parses, interprets > >> and acts upon the contents of a Web of interconnected RDF/XML > >> documents. In this sense it is just a Semantic Web variant on the old > >> theme of distributed Web indexing, sometimes called a 'harvester', > >> 'spider', or 'robot'. The links between RDF documents are usually, but > >> not necessarily, expressed using RDF's 'rdfs:seeAlso' property." (see > >> http://rdfweb.org/topic/Scutter) > >> > >> So, I think we gain a lot of power if our metadata is sufficiently > >> linked to support a scutter. For example, given metadata for a PubMed > >> publication, we could get to sequences, via that to taxa (including > >> names in numerous databases via LinkOut), to specimens, and so on, all > >> via metadata. Indeed, one could let a scutter loose and aggregate data > >> a la Google -- who needs GBIF anyway ;-). > >> > >> In fact, this would be a cool challenge. Start a scutter and see what > >> can be retrieved. > >> > >>> > >>> I am thinking aloud here but we have to be very careful in adding > >>> things to vocabularies - even when they seem really useful. > >>> Ultimately if a client wants to know everything about a object that a > >>> data source has it will have to ask the "Give me all the things that > >>> refer to X" question. Either that or we have to guarantee that all > >>> links are always reciprocal - which we can't. > >> > >> No, you don't have to guarantee links are reciprocal, but you do want > >> some degree of reachability -- that I can get from one object to > >> another. If we aggregate everything into one central repository (a la > >> Google indexing the web) then this isn't an issue, but it is if we > >> don't. I agree that for some things we don't want to have reciprocal > >> links -- but I'd suggest we'd need to think seriously about supporting > >> basic search. As you point out, we need to support the "Give me all > >> the things that refer to X" question. > >> > >> Ultimately, I think we can't ignore search, or perhaps more generally > >> "finability" (which depends on things being linked). See the wonderful > >> book "Ambient Findability" by Peter Morville > >> (http://www.oreilly.com/catalog/ambient/) If we don't make our stuff > >> findable, we are wasting our time. > >> > >> Rod > >> > >>> > >>> On the other hand things that are in people's data bases that are > >>> easy to pass should perhaps be represented in an ontology - if they > >>> are useful. > >>> > >>> Well done for another LSID authority Kevin. > >>> > >>> All the best, > >>> > >>> Roger > >>> > >>> > >>> > >>> Kevin Richards wrote:Thanks for those comments Rod. > >>>> As you have seen this is an initial attempt. > >>>> > >>>> > >>>>>> The syntax > >>>>>> > >>>>>> <TaxonNames:hasBasionym> > >>>>>> <rdf:Description > >>>>>> rdf:about="urn:lsid:indexfungorum.org:Names:148860" /> > >>>>>> </TaxonNames:hasBasionym> > >>>>>> > >>>>>> strikes me as odd. > >>>>>> > >>>> This is due to an accidental omission of the RDF entity type of the > >>>> basionym object. Will fix this. > >>>> > >>>> > >>>>>> I also suggest that urn:lsid:indexfungorum.org:Names:148860 has a > >>>>>> complementary tag such as > >>>>>> > >>>>>> <TaxonNames:isBasionymOf rdf:resource = > >>>>>> "urn:lsid:indexfungorum.org:Names: 213649" /> > >>>>>> > >>>> Godd idea. The fields are based on the initial implementation of > >>>> TCS-RDF that Roger completed, and as he said, it is not a complete > >>>> schema at this stage. BTW the reverse RDF pointers can be viewed > >>>> using > >>>> launchpad by going into the launchpad settings and turning on 'Show > >>>> back > >>>> links'. > >>>> > >>>> > >>>> > >>>>>> The attribute > >>>>>> TaxonNames:nomenclaturalCode=" http://tdwg.org/2006/03/12/ > >>>>>> TaxonNames/ > >>>>>> NomenclaturalCode/#botanical" of the tag <TaxonNames:TaxonName> is > >>>>>> problematic. Firstly, I don't know why this is an attribute rather > >>>>>> > >>>> than > >>>> > >>>>>> just another tag, > >>>>>> > >>>> Due to my lack of understanding of RDF and when to use attributes as > >>>> opposed to tags - I was blindly following an example. > >>>> > >>>> > >>>> > >>>>>> and the URI > >>>>>> http://tdwg.org/2006/03/12/TaxonNames/NomenclaturalCode/#botanical > >>>>>> returns a 404. If this is just a made up URI then this is bad -- > >>>>>> > >>>> EVERY > >>>> > >>>>>> URI in an RDF document must be real -- unlike XML schema where any > >>>>>> > >>>> old > >>>> > >>>>>> rubbish can be used. > >>>>>> > >>>> Also due to the prototyping stage of this 'project'. Will be fixed > >>>> by > >>>> online TDWG ontologies at some stage I assume? > >>>> > >>>> > >>>>>> <TaxonNames:publishedIn><i>Syll. fung.</i> (Abellini) > >>>>>> <b>1</b>: 148 (1882) (1882)</TaxonNames:publishedIn> > >>>>>> has formatting information (the <i></i> and <b></b> tags). I think > >>>>>> > >>>> this > >>>> > >>>>>> is in principle a bad thing(TM) > >>>>>> > >>>> We debated this a little and decided to leave the field text the > >>>> same as > >>>> has been returned by other services of IndexFungorum. But you have > >>>> a > >>>> good point and it is something we will need to discuss further in > >>>> future. > >>>> > >>>> 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 > >>> ------------------------------------- > >>> > >>> > >> ---------------------------------------------------------------------- > >> ------------------------------------------ > >> > >> Professor Roderic D. M. Page > >> Editor, Systematic Biology > >> DEEB, IBLS > >> Graham Kerr Building > >> University of Glasgow > >> Glasgow G12 8QP > >> United Kingdom > >> > >> Phone: +44 141 330 4778 > >> Fax: +44 141 330 2792 > >> email: r.page(a)bio.gla.ac.uk > >> web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > >> reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html > >> > >> Subscribe to Systematic Biology through the Society of Systematic > >> Biologists Website: http://systematicbiology.org > >> Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/<http://darwin.zoology.gla.ac.uk/%7Erpage/portal/> > >> Find out what we know about a species: http://ispecies.org > >> Rod's rants on phyloinformatics: http://iphylo.blogspot.com > >> > >> > >> > >> > >> > >> > >> ___________________________________________________________ > >> Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with > >> voicemail http://uk.messenger.yahoo.com > >> > > > > > > -- > > > > ------------------------------------- > > Roger Hyam > > Technical Architect > > Taxonomic Databases Working Group > > ------------------------------------- > > http://www.tdwg.org > > roger(a)tdwg.org > > +44 1578 722782 > > ------------------------------------- > > > > > ------------------------------------------------------------------------ > ---------------------------------------- > Professor Roderic D. M. Page > Editor, Systematic Biology > DEEB, IBLS > Graham Kerr Building > University of Glasgow > Glasgow G12 8QP > United Kingdom > > Phone: +44 141 330 4778 > Fax: +44 141 330 2792 > email: r.page(a)bio.gla.ac.uk > web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html > reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html > > Subscribe to Systematic Biology through the Society of Systematic > Biologists Website: http://systematicbiology.org > Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/<http://darwin.zoology.gla.ac.uk/%7Erpage/portal/> > Find out what we know about a species: http://ispecies.org > Rod's rants on phyloinformatics: http://iphylo.blogspot.com > > > > > ___________________________________________________________ > Yahoo! For Good - Sponsor a London Marathon runner - http://uk.promotions.yahoo.com/charity/london-marathon > >

1 0

Re: LSID Annotation and Link-out
by Sally Hinchcliffe 26 Apr '06

26 Apr '06

I agree with Kevin that the Foreign Authentication Notification services looked like an interesting way of providing third party data. I didn't go into it in too much detail, but from what I discussed with Ben, it might well work quite well as a way of providing linkouts from name information to other information linked via that name (e.g. a taxon concept ...) Unfortunately I'm unlikely to have any time to investigate this further in time for the June meeting. My idea was that anyone who had interesting information that was keyed by an IPNI LSID (such as a concept) could notify us of that fact using FAN and we could then provide an automated link out from the relevant IPNI record to those related records. The original idea was to do this so we could provide relevant drill downs from the website, but it could also be included as part of the LSID metadata. We'd have to have some sort of authentication method to stop link spammers. Anyway that's as far as I had got with the idea, if anyone wants to take up the question further ... Sally > Relying on crwalers is not always going to get all the relevant information for a particular query, especially if that relevant data that is hidden deep inside some organisation's database, and hence cannot be found via crawlers. > To get the best functionality for the system I think we need to strongly reccommend a required set of services that all of our data providers need to provide (ie including the LSID FAN services that allow thrid party 'annotations' of LSID objects). For those who cannot provide all services, then tools like crawlers could attempt to fill the gap. > Kevin > > >>> dhobern(a)GBIF.ORG 21/04/2006 9:15 p.m. >>> > > There would seem to be two other fairly obvious approaches we could follow to manage external annotation of LSIDs: We could rely simply on passive discovery of the links by crawler applications such as the GBIF data indexer * when indexing the third-party data, it would be possible to store a reference to the relationship between the objects and to offer a service allowing users to check for "additional information" on any LSID. This relies on good coverage by the crawler tools * in particular it assumes that the data objects offered by the third-party data provider belong to classes which are themselves of interest to the crawler. > > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > *** Sally Hinchcliffe *** Computer section, Royal Botanic Gardens, Kew *** tel: +44 (0)20 8332 5708 *** S.Hinchcliffe(a)rbgkew.org.uk

1 0