S.Hinchcliffe at kew.org
Mon Nov 28 17:10:23 CET 2005
Hi Roger and everyone
> Hi Everyone,
> I have been doing some work on a TaxonAPI. This is a high/low definition
> of the kind of thing I believe people publishing taxonomic data need to
> produce and people consuming it need to eat based on the work I have
> been involved in on TCS.
I don't know if it helps but more than a year ago Donald & I worked
out a set of calls that he would need for indexing ipni for ECAT. I
don't think they've ever actually been used (although they are
implemented within ipni but not very rigorously tested) but they
might be of some use to look at if you haven't already.
(we had requirements like 'changed since' and added since' which
avoids flogging the entire ipni data set each time the index was
Other brief comments (with ipni hat firmly on my head) - on your
TaxonApiMatching page, some of the terms you list are ones which we
can respond to but incompletely. For example publication year
(because it's not as important with botanical names) - we could send
back some data but it would be incomplete (because of the state of
parsing of the underlying data), i.e. records published in the
supplied year would not actually get returned. This may be the case
(or not) for other data suppliers. Or they may not be able to return
at all for particular parameter if their level of normalisation does
not support it.
Also your example parameters (Genus, Species epithet) don't actually
appear in the list below the text - is this because it's a work in
progress or because I have totally missed the point?
I didn't quite understant GetReferringTNames -there is a parameter
which is a list of ids but apparently no other parameter to say which
relationship (basionymof, homonymof) is being referred to. Does that
mean that can't be set? The client would then have to parse through
the resulting TCS to see which were the basionyms if that is what
they were interested in.
On GetTNamesById, you point out that suppliers can refuse to respond
(presumably in the case of a too-long list of ids) - alternatively I
suppose they could just truncate at some predetermined number of
records (something to mention in a capability document?)
Also we have the issue of deleted (or in IPNI's case suppressed) ids.
At the moment IPNI will serve up suppressed records which it must do
if the ids are to be persistent, but there's nothing in the response
which could be used to indicate that the records are deprecated in
any way. I don't know if this is a problem or not ...
Forgive me if I've missed the point on some of these issues ...
Monday afternoon and all that
> It is framed as if it were a web service type of thing but I imagine
> that each of the method calls mentioned could equate to a Tapir template
> of some kind. I imagine a template containing a parameterized filter
> (not sure if those exist anymore).
> This is still work in progress as I need to define the list of
> parameters more closely and sort the greater than/less than issue for
> dates and a few other bits. Plus no one has seen it to comment on!
> You can read more about it here:
> I would be most grateful for your comments.
> How does this fit with Tapir?
> Roger Hyam
> Technical Architect
> Taxonomic Databases Working Group
> roger at tdwg.org
> +44 1578 722782
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
*** Sally Hinchcliffe
*** Computer section, Royal Botanic Gardens, Kew
*** tel: +44 (0)20 8332 5708
*** S.Hinchcliffe at rbgkew.org.uk
More information about the tdwg-tag