[tdwg-tapir] Updates and plans

Tim Robertson trobertson at gbif.org
Mon Oct 13 17:38:59 CEST 2008

Hi Renato,

I get what you are saying but would the wrapper tool be better to just  
register the existence of the dump file (or the meta file describing  
the dump) in a registry?  E.g. A new service binding for a UDDI  
registration.  If I bundled WFS with a TAPIR implementation I wouldn't  
advertise the existence of that in the capabilities, or would I?  I  
foresee wrapper tools with WFS, WMS, TAPIR, locally generated index  
files (so called dumps), OAI-PMH, TCS complete dataset files, EML in a  
single installation - would the capabilities be flexible enough to  
allow for these additional protocols?

TAPIRLite - I think then to write a client you would have to be able  
to understand the templated request (E.g. deconstruct the filters) and  
work out the parameters required in order to construct the URL.  To me  
it seems backwards since it is the provider saying to the client "this  
is the one query I support" which is more like just advertising a  
custom webservice - no?  We must be misusing it, or shying away from  
writing complex client code at GBIFS as we only support 2 templates,  
which effectively says we only support 2 URL types and one output  
document format.  So we don't even issue capabilities requests to  
these providers since they are known to be coded against the  
template... misuse?

Really looking forward to picking your brains Renato!



On 13 Oct 2008, at 21:04, Renato De Giovanni wrote:

> Hi Tim,
> If the provider only has a dump file and is not planning to offer any
> TAPIR operation in the future, I certainly agree there's nothing  
> much to
> do with TAPIR. However, we all know that data harvesters may benefit  
> if
> real TAPIR providers do offer some sort of dump file to help in the
> initial load. In this case, isn't it better to know from the  
> capabilities
> response that the provider has a dump file in a certain format  
> available
> in a certain place? If we don't include this information as part of a
> capabilities response, how would you know about it? I'm sure you'll  
> prefer
> not to receive this additional information by e-mail from each  
> provider...
> Regarding TAPIRLite, the example you gave will only be technically  
> correct
> if the service is also able to respond the 3 (currently) mandatory
> operations (metadata, capabilities and ping) and if the query  
> template is
> defined according to the TAPIR spec.
> Best Regards,
> --
> Renato
>> Hi Renato, Markus, Kevin et al
>> Should a dump file really have anything to do with TAPIR?  I would  
>> have
>> expected to see it external to TAPIR spec - not to say that the  
>> wrapper
>> software can't be a TAPIR wrapper plus a 'dump file' wrapper at the  
>> same
>> time.
>> Similarly with TAPIRLite - maybe I don't get it right, or perhaps  
>> it was
>> the early adopters, but one can be a TAPIRLite provider while only
>> answering one search URL pointing at a custom query template with  
>> say a
>> couple of GET params passed in, only support a custom response  
>> schema, yet
>> claim TAPIR compliance - is this technically correct?
>> What say you guys?
>> Looking forward to discussing with you all.
>> Cheers from Singapore Airport,
>> Tim
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir

More information about the tdwg-tag mailing list