Hi Renato,
Hmmm... 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!
Cheers
Tim
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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir