LSID Annotation and Link-out
Bob Morris
morris.bob at GMAIL.COM
Mon Apr 24 21:15:38 CEST 2006
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 at 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 at 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 at 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
>
------=_Part_24886_6273000.1145927738247
Content-Type: text/html; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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.
<br><br>--Bob<br><br><br><div><span class="gmail_quote">On 4/21/06, <b class="gmail_sendername">Roderic Page</b> <<a href="mailto:r.page at bio.gla.ac.uk">r.page at bio.gla.ac.uk</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As Tony Blair is fond of saying, there is a third way. Why not co-opt<br>an existing service, such as Pingback used in blogs (e.g.,<br><a href="http://hixie.ch/specs/pingback/pingback">http://hixie.ch/specs/pingback/pingback
</a>).<br><br>Blogging can be thought of as distributed annotation. It provides a<br>mechanism whereby if I comment on an entry in another person's blog,<br>that person's blog gets notified automatically.<br><br>Now, if we were really clever, we'd do things like support the blogging
<br>explicitly, and potentially get useful annotations almost for free. For<br>example, if somebody makes an entry in their blog that links to an<br>LSID, the data provider is notified of the blog entry via Pingback. If<br>
the blog supports an RRS 1.0 feed, then the blog serves RDF, which can<br>be easily referenced as an annotation in the LSID metadata. We get this<br>with minimal effort, and users can annotate in an environment they are<br>
familiar with (their blog software). I'm not suggesting blogs are the<br>only annotation we support (obviously we'd like tools specific to our<br>area of interest), but making use of what is out there seems to make<br>sense to me.
<br><br>Given that there are existing tools out there to do this sort of thing,<br>I don't think this would be hard to do. Why not add it to the list of<br>things a TDWG-GUID-compliant data provider should/could support?<br>
<br>Regards<br><br>Rod<br><br><br><br><br>On 21 Apr 2006, at 10:15, Donald Hobern wrote:<br><br>><br>> One of the topics identified under the "LSID Infrastructure Working<br>> Group" umbrella relates to "GUID Annotation and Link-out Mechanisms"
<br>> (no other comments associated with this topic at this point). So far<br>> no-one has expressed any interest in doing any work on this topic.<br>> <br>> Basically the question is whether we should adopt any mechanisms and
<br>> best practices for how a third-party data provider should serve<br>> annotations and additional data fields to be related to a data object<br>> with its own LSID and served by some other data provider. During
<br>> GUID-1 Ben Szekely mentioned the annotation interfaces that had been<br>> proposed for use with LSIDs. This is a mechanism for a data provider<br>> using LSIDs to expose an interface which a third-party data provider
<br>> may invoke to notify the first data provider that they are serving<br>> such annotations. It is then up to the first data provider to decide<br>> whether or not to include a reference to these annotations as part of
<br>> the metadata for the LSID in question.<br>> <br>> This is a collaborative approach which could be useful but which<br>> relies on special software at both ends, in addition to any basis LSID<br>> resolution stack. Unless a high proportion of data providers serving
<br>> LSIDs install software to accept notifications of annotations and to<br>> store the appropriate external references, I do not believe that<br>> third-party data providers will find it worthwhile to establish their
<br>> end of the interaction. Does anyone think otherwise?<br>> <br>> There would seem to be two other fairly obvious approaches we could<br>> follow to manage external annotation of LSIDs:<br>> <br>> 1 We could rely simply on passive discovery of the links by crawler
<br>> applications such as the GBIF data indexer – when indexing the<br>> third-party data, it would be possible to store a reference to the<br>> relationship between the objects and to offer a service allowing users
<br>> to check for "additional information" on any LSID. This relies on<br>> good coverage by the crawler tools – in particular it assumes that the<br>> data objects offered by the third-party data provider belong to
<br>> classes which are themselves of interest to the crawler.<br>> 2 We could establish a central service which can be invoked by<br>> anyone to assert relationships between any two LSIDs. This would take
<br>> the burden of handling these notifications away from the original data<br>> providers and would provide the foundation for establishing an<br>> "additional information" service.<br>> <br>> I therefore have two questions:
<br>> <br>> 1 Are any of these options likely to be valuable enough that we<br>> should consider clarifying them, implementing any required software<br>> and services, and defining best practices?<br>
> 2 (Even more importantly) Is there anyone who is sufficiently<br>> interested to take ownership of this topic?<br>> <br>> Thanks,<br>> <br>> Donald<br>> <br>> ---------------------------------------------------------------
<br>> Donald Hobern (<a href="mailto:dhobern at gbif.org">dhobern at gbif.org</a>)<br>> Programme Officer for Data Access and Database Interoperability<br>> Global Biodiversity Information Facility Secretariat<br>> Universitetsparken 15, DK-2100 Copenhagen, Denmark
<br>> Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480<br>> ---------------------------------------------------------------<br>> <br>><br>------------------------------------------------------------------------
<br>----------------------------------------<br>Professor Roderic D. M. Page<br>Editor, Systematic Biology<br>DEEB, IBLS<br>Graham Kerr Building<br>University of Glasgow<br>Glasgow G12 8QP<br>United Kingdom<br><br>Phone: +44 141 330 4778
<br>Fax: +44 141 330 2792<br>email: <a href="mailto:r.page at bio.gla.ac.uk">r.page at bio.gla.ac.uk</a><br>web: <a href="http://taxonomy.zoology.gla.ac.uk/rod/rod.html">http://taxonomy.zoology.gla.ac.uk/rod/rod.html
</a><br>reprints: <a href="http://taxonomy.zoology.gla.ac.uk/rod/pubs.html">http://taxonomy.zoology.gla.ac.uk/rod/pubs.html</a><br><br>Subscribe to Systematic Biology through the Society of Systematic<br>Biologists Website:
<a href="http://systematicbiology.org">http://systematicbiology.org</a><br>Search for taxon names: <a href="http://darwin.zoology.gla.ac.uk/~rpage/portal/">http://darwin.zoology.gla.ac.uk/~rpage/portal/</a><br>Find out what we know about a species:
<a href="http://ispecies.org">http://ispecies.org</a><br>Rod's rants on phyloinformatics: <a href="http://iphylo.blogspot.com">http://iphylo.blogspot.com</a><br></blockquote></div><br>
More information about the tdwg-tag
mailing list