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

Use of XML Spy diagrams in specifications or documents
by Javier de la Torre 26 Apr '06

26 Apr '06

Dear all, During the Edinburgh meeting we had problems defining the way we were going to communicate to develop a core of clases-ontology-list- whatever for TDWG. While reading the OpenGIS Sensor Observation Service (SOS) Implementation Specification I have found that they seem to have the same problem of people very used to XML Spy and its XML Schema representation for modeling. They enforce the use of UML diagrams but use XML Spy diagrams for clarification. "5.2 UML Notation Most diagrams that appear in this specification are presented using the Unified Modeling Language (UML) static structure diagram, as described in Subclause 5.2 of [OGC 05- 008]. 5.3 XML schema notation Most diagrams that appear in this specification are presented using an XML schema notation defined by the XMLSpy1 product and described in this subclause. XML schema diagrams are for informative use only though they shall reflect the accompanied UML and schema perfectly. " And then continue explaining the different things that appear on an XML Spy diagram (elements, optionality, recursion, sequence, choices, etc.) I am sending this to the TAPIR mailing list because I think this could be really useful for the specification document. We can just point to them and we don't need to describe all this :) The document I am talking about can be found at: http://www.opengeospatial.org/specs/?page=requests&request=rfpc32 And is in its RPC process right now. Javier.

2 1

Re: LSID Annotation and Link-out
by Roger Hyam 26 Apr '06

26 Apr '06

At the TAG-1 meeting we discussed a base level provider having GUID resolution plus a harvest API (perhaps based on OAI though we need to look into it) with search/query as the next level of services. Roger Kevin Richards wrote: > 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: > > > > 1. 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 > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Re: LSID Annotation and Link-out
by Kevin Richards 26 Apr '06

26 Apr '06

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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Index Fungorum LSID server
by Roderic Page 25 Apr '06

25 Apr '06

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/ >> 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/ 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: Index Fungorum LSID server
by Roger Hyam 25 Apr '06

25 Apr '06

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/ > 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 -------------------------------------

1 0

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

25 Apr '06

Author: markus Date: 2006-04-25 11:01:16 +0200 (Tue, 25 Apr 2006) New Revision: 518 Modified: trunk/protocol/examples/capabilities_request.xml trunk/protocol/examples/capabilities_response.xml trunk/protocol/examples/inventory_request.xml trunk/protocol/examples/inventory_response.xml trunk/protocol/examples/inventory_template1.xml trunk/protocol/examples/metadata_request.xml trunk/protocol/examples/metadata_response.xml trunk/protocol/examples/output_model1.xml trunk/protocol/examples/ping_request.xml trunk/protocol/examples/ping_response.xml trunk/protocol/examples/search_template1.xml trunk/protocol/examples/wfs_gcp_output.xml trunk/protocol/tapir.xsd Log: updated to the new tdwg namespace: http://res.tdwg.org/tapir/1.0 Modified: trunk/protocol/examples/capabilities_request.xml =================================================================== --- trunk/protocol/examples/capabilities_request.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/capabilities_request.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> -<request xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<request xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + 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"> </source> Modified: trunk/protocol/examples/capabilities_response.xml =================================================================== --- trunk/protocol/examples/capabilities_response.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/capabilities_response.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> -<response xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<response xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + xsi:schemaLocation="http://res.tdwg.org/tapir/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> <header> <source accesspoint="http://accesspoint_url" sendtime="2005-11-11T12:23:56.023+01:00"> <software name="TAPIR_Implementation" version="1.0"/> Modified: trunk/protocol/examples/inventory_request.xml =================================================================== --- trunk/protocol/examples/inventory_request.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/inventory_request.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> -<request xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<request xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + 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"> </source> Modified: trunk/protocol/examples/inventory_response.xml =================================================================== --- trunk/protocol/examples/inventory_response.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/inventory_response.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> -<response xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<response xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + xsi:schemaLocation="http://res.tdwg.org/tapir/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> <header> <source accesspoint="http://accesspoint_url" sendtime="2005-11-11T12:23:56.023+01:00"> <software name="TAPIR_Implementation" version="1.0"/> Modified: trunk/protocol/examples/inventory_template1.xml =================================================================== --- trunk/protocol/examples/inventory_template1.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/inventory_template1.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> -<inventoryTemplate xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<inventoryTemplate xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + xsi:schemaLocation="http://res.tdwg.org/tapir/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> <label>Specimen Names</label> <documentation>Search and list unique scientific names of specimen identifications ordered alphabetically by their name. The filter parameter "name" is used to build the filter</documentation> Modified: trunk/protocol/examples/metadata_request.xml =================================================================== --- trunk/protocol/examples/metadata_request.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/metadata_request.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -2,9 +2,9 @@  -<request xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<request xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + 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"> </source> Modified: trunk/protocol/examples/metadata_response.xml =================================================================== --- trunk/protocol/examples/metadata_response.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/metadata_response.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -3,9 +3,9 @@ TAPIR Metadata Response example. This example only includes mandatory concepts. The metadata part in TAPIR is likely to be changed after comunity discussion. --> -<response xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<response xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + xsi:schemaLocation="http://res.tdwg.org/tapir/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> <header> <source accesspoint="http://accesspoint_url" sendtime="2005-11-11T12:23:56.023+01:00"> <software name="TAPIR_Implementation" version="1.0"/> Modified: trunk/protocol/examples/output_model1.xml =================================================================== --- trunk/protocol/examples/output_model1.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/output_model1.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -1,9 +1,9 @@ <?xml version="1.0" encoding="UTF-8"?> -<outputModel xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<outputModel xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" - http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd + http://res.tdwg.org/tapir/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/XMLSchema.xsd "> <structure> Modified: trunk/protocol/examples/ping_request.xml =================================================================== --- trunk/protocol/examples/ping_request.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/ping_request.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -3,9 +3,9 @@ TAPIR Ping Request example. The most simple operation in TAPIR. --> -<request xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<request xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + 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"> <software name="TAPIR_Implementation" version="1.0"/> Modified: trunk/protocol/examples/ping_response.xml =================================================================== --- trunk/protocol/examples/ping_response.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/ping_response.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -2,9 +2,9 @@  -<response xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<response xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + xsi:schemaLocation="http://res.tdwg.org/tapir/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> <header> <source accesspoint="http://accesspoint_url" sendtime="2005-11-11T12:23:57.023+01:00"></source> </header> Modified: trunk/protocol/examples/search_template1.xml =================================================================== --- trunk/protocol/examples/search_template1.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/search_template1.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -1,7 +1,7 @@ <?xml version="1.0" encoding="UTF-8"?> -<searchTemplate xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<searchTemplate xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" - xsi:schemaLocation="http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> + xsi:schemaLocation="http://res.tdwg.org/tapir/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd"> <label>Specimen by Name</label> <documentation>Search specimens by their scientific name. Result is returned ordered by name and catalogue number. The filter parameter "name" is used to build the filter.</documentation> Modified: trunk/protocol/examples/wfs_gcp_output.xml =================================================================== --- trunk/protocol/examples/wfs_gcp_output.xml 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/examples/wfs_gcp_output.xml 2006-04-25 09:01:16 UTC (rev 518) @@ -1,9 +1,9 @@ <?xml version="1.0" encoding="UTF-8"?> -<outputModel xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" +<outputModel xmlns="http://res.tdwg.org/tapir/1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation=" - http://www.tdwg.org/schemas/tapir/datasource/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd + http://res.tdwg.org/tapir/1.0 http://ww2.biocase.org/svn/tapir/trunk/protocol/tapir.xsd http://www.w3.org/2001/XMLSchema http://www.w3.org/2001/XMLSchema.xsd "> <structure> Modified: trunk/protocol/tapir.xsd =================================================================== --- trunk/protocol/tapir.xsd 2006-03-15 14:25:14 UTC (rev 517) +++ trunk/protocol/tapir.xsd 2006-04-25 09:01:16 UTC (rev 518) @@ -2,7 +2,10 @@    -<xsd:schema targetNamespace="http://www.tdwg.org/schemas/tapir/datasource/1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0" xml:lang="EN" xmlns="http://www.tdwg.org/schemas/tapir/datasource/1.0" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> +<xsd:schema targetNamespace="http://res.tdwg.org/tapir/1.0" + xmlns="http://res.tdwg.org/tapir/1.0" + xmlns:xsd="http://www.w3.org/2001/XMLSchema" + elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0" xml:lang="EN" >

1 0

Re: Index Fungorum LSID server
by Roderic Page 24 Apr '06

24 Apr '06

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/ 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

1 0

Re: LSID Annotation and Link-out
by Bob Morris 24 Apr '06

24 Apr '06

TrackBack is a similar facility to PingBack. It appears that there was a brief religious war between them 2-3 years ago (google "Trackback vs Pingback"). Since both don't seem to that blog specific, it is curious that there appears to be no W3 effort to standardize a protocol or at least the context for a protocol. --Bob On 4/21/06, Roderic Page <r.page(a)bio.gla.ac.uk> wrote: > > As Tony Blair is fond of saying, there is a third way. Why not co-opt > an existing service, such as Pingback used in blogs (e.g., > http://hixie.ch/specs/pingback/pingback). > > Blogging can be thought of as distributed annotation. It provides a > mechanism whereby if I comment on an entry in another person's blog, > that person's blog gets notified automatically. > > Now, if we were really clever, we'd do things like support the blogging > explicitly, and potentially get useful annotations almost for free. For > example, if somebody makes an entry in their blog that links to an > LSID, the data provider is notified of the blog entry via Pingback. If > the blog supports an RRS 1.0 feed, then the blog serves RDF, which can > be easily referenced as an annotation in the LSID metadata. We get this > with minimal effort, and users can annotate in an environment they are > familiar with (their blog software). I'm not suggesting blogs are the > only annotation we support (obviously we'd like tools specific to our > area of interest), but making use of what is out there seems to make > sense to me. > > Given that there are existing tools out there to do this sort of thing, > I don't think this would be hard to do. Why not add it to the list of > things a TDWG-GUID-compliant data provider should/could support? > > Regards > > Rod > > > > > On 21 Apr 2006, at 10:15, Donald Hobern wrote: > > > > > One of the topics identified under the "LSID Infrastructure Working > > Group" umbrella relates to "GUID Annotation and Link-out Mechanisms" > > (no other comments associated with this topic at this point). So far > > no-one has expressed any interest in doing any work on this topic. > > > > Basically the question is whether we should adopt any mechanisms and > > best practices for how a third-party data provider should serve > > annotations and additional data fields to be related to a data object > > with its own LSID and served by some other data provider. During > > GUID-1 Ben Szekely mentioned the annotation interfaces that had been > > proposed for use with LSIDs. This is a mechanism for a data provider > > using LSIDs to expose an interface which a third-party data provider > > may invoke to notify the first data provider that they are serving > > such annotations. It is then up to the first data provider to decide > > whether or not to include a reference to these annotations as part of > > the metadata for the LSID in question. > > > > This is a collaborative approach which could be useful but which > > relies on special software at both ends, in addition to any basis LSID > > resolution stack. Unless a high proportion of data providers serving > > LSIDs install software to accept notifications of annotations and to > > store the appropriate external references, I do not believe that > > third-party data providers will find it worthwhile to establish their > > end of the interaction. Does anyone think otherwise? > > > > There would seem to be two other fairly obvious approaches we could > > follow to manage external annotation of LSIDs: > > > > 1 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. > > 2 We could establish a central service which can be invoked > by > > anyone to assert relationships between any two LSIDs. This would take > > the burden of handling these notifications away from the original data > > providers and would provide the foundation for establishing an > > "additional information" service. > > > > I therefore have two questions: > > > > 1 Are any of these options likely to be valuable enough that > we > > should consider clarifying them, implementing any required software > > and services, and defining best practices? > > 2 (Even more importantly) Is there anyone who is > sufficiently > > interested to take ownership of this topic? > > > > Thanks, > > > > Donald > > > > --------------------------------------------------------------- > > Donald Hobern (dhobern(a)gbif.org) > > Programme Officer for Data Access and Database Interoperability > > Global Biodiversity Information Facility Secretariat > > Universitetsparken 15, DK-2100 Copenhagen, Denmark > > Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 > > --------------------------------------------------------------- > > > > > ------------------------------------------------------------------------ > ---------------------------------------- > 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/ > Find out what we know about a species: http://ispecies.org > Rod's rants on phyloinformatics: http://iphylo.blogspot.com >

1 0

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

24 Apr '06

This is great stuff. The vocabulary URIs are temporary but we are working on a central system for resolvable ones just now. We need a space for these as well as schemaLocations and various other things. 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. 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. 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. 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 -------------------------------------

1 0

Forward compatibility issues
by Gregor Hagedorn 24 Apr '06

24 Apr '06

I believe that if we view the TDWG architecture as being more than the GBIF indexing use case, we need to think closer about the assumptions made in the requirement of a fully forward compatible data structure. Please see: http://wiki.tdwg.org/twiki/bin/view/TAG/ForwardCompatibilityAndScientificDa… hange Gregor---------------------------------------------------------- Gregor Hagedorn (G.Hagedorn(a)bba.de) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Königin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203

1 0