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@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 bycrawler
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 thatwe
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@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@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