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

Re: Index Fungorum LSID server
by Kevin Richards 24 Apr '06

24 Apr '06

No, not too negative, its good to get some feedback. The server is not .NET based yet - I am still working on the .NET implementation of the LSID framework at present - making good progress though. Kevin >>> r.page(a)BIO.GLA.AC.UK 04/23/06 10:52 PM >>> Hope it didn't come across as too negative. I know these things are not easy to get set up, and I'm still finding my own way through the RDF jungle. Is your server .NET based? Regards Rod On 22 Apr 2006, at 10:57, 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>Syll. fung. (Abellini) >>> 1: 148 (1882) (1882)</TaxonNames:publishedIn> >>> has formatting information (the and 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 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > > ------------------------------------------------------------------------ ---------------------------------------- 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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 [ Scanned for viruses ]
by Paul Kirk 23 Apr '06

23 Apr '06

Not in the slightest ... ;-) Not yet. Kevin is porting everything into .NET - at the moment the resolver runs on an old Dell box with the database on a slightly less old Dell box (the same server as the human interface and the web service). We plan to move everything on to one server when we have the .NET version written and tested (sometime in the summer is my optimistic plan) - accompanied by a server swop (testing in isolation from live server) to give a bit more horsepower. Regards, Paul ________________________________ From: Taxonomic Databases Working Group GUID Project on behalf of Roderic Page Sent: Sun 23/04/2006 11:52 To: TDWG-GUID(a)LISTSERV.NHM.KU.EDU Subject: Re: Index Fungorum LSID server [ Scanned for viruses ] Hope it didn't come across as too negative. I know these things are not easy to get set up, and I'm still finding my own way through the RDF jungle. Is your server .NET based? Regards Rod On 22 Apr 2006, at 10:57, 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>Syll. fung. (Abellini) >>> 1: 148 (1882) (1882)</TaxonNames:publishedIn> >>> has formatting information (the and 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 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > > ------------------------------------------------------------------------ ---------------------------------------- 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 Roderic Page 23 Apr '06

23 Apr '06

Hope it didn't come across as too negative. I know these things are not easy to get set up, and I'm still finding my own way through the RDF jungle. Is your server .NET based? Regards Rod On 22 Apr 2006, at 10:57, 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>Syll. fung. (Abellini) >>> 1: 148 (1882) (1882)</TaxonNames:publishedIn> >>> has formatting information (the and 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 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > > ------------------------------------------------------------------------ ---------------------------------------- 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 Kevin Richards 22 Apr '06

22 Apr '06

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>Syll. fung. (Abellini) >> 1: 148 (1882) (1882)</TaxonNames:publishedIn> >>has formatting information (the and 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 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Index Fungorum LSID server
by Kevin Richards 22 Apr '06

22 Apr '06

The IF LSID server now returns TCS-RDF (based on Roger's initial implementation) as the metadata and a "full taxonomic name" as the data. Eg try lsidres:urn:lsid:indexfungorum.org:Names:213649 in your browser. Kevin ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

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

22 Apr '06

Cool! A few quick comments re TCS-RDF. The syntax <TaxonNames:hasBasionym> <rdf:Description rdf:about="urn:lsid:indexfungorum.org:Names:148860" /> </TaxonNames:hasBasionym> strikes me as odd. If you want to assert a relationship between to entities, something like <TaxonNames:hasBasionym rdf:resource = "urn:lsid:indexfungorum.org:Names:148860" /> seems appropriate. You are making a link to another entity. Nesting an rdf:about tag doesn't actually express what we want to say. 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" /> so we can recover the names for which it is a basionym. Ultimately this could go in an ontology (i.e., that hasBasionym implies the reverse isBasionnymOf), but this adds a layer of inference not supported by triple stores (yet?). If the tags are in the RDF it becomes very easy to aggregate this information. 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, 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. <TaxonNames:publishedIn>Syll. fung. (Abellini) 1: 148 (1882) (1882)</TaxonNames:publishedIn> has formatting information (the and tags). I think this is in principle a bad thing(TM) if we can do this in any old tag. We should separate content and presentation. If we want information that has formatting, then I think we need to look at what the RSS feed community has to say about this (of course, they can't quite make up their mind). Options include the content namespace (http://web.resource.org/rss/1.0/modules/content/), or using xhtml:body (see, e.g., http://weblog.infoworld.com/udell/2003/04/14.html). Regards Rod On 22 Apr 2006, at 01:14, Kevin Richards wrote: > The IF LSID server now returns TCS-RDF (based on Roger's initial > implementation) as the metadata and a "full taxonomic name" as the > data. > > Eg try lsidres:urn:lsid:indexfungorum.org:Names:213649 in your browser. > > 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 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > +++++ > > ------------------------------------------------------------------------ ---------------------------------------- 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 ___________________________________________________________ 24 FIFA World Cup tickets to be won with Yahoo! Mail http://uk.mail.yahoo.com

1 0

Re: LSID Annotation and Link-out
by Roderic Page 21 Apr '06

21 Apr '06

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

LSID Annotation and Link-out
by Donald Hobern 21 Apr '06

21 Apr '06

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

1 0

Use of RDDL in OGC
by Javier de la Torre 21 Apr '06

21 Apr '06

Hi all, It was nice to meet some of you in Edinburgh, thanks Roger and Jessie for the organization. Just a short notice about RDDL. I think we couldn't find anybody using RDDL for their schemas apart of W3C. OGC is also using it, for example: http://opengis.net/gml/ Best regards, Javier.

1 0

Message deleted
by ***** 20 Apr '06

20 Apr '06

Message deleted

1 0