[tdwg-tapir] Updates and plans

[Renato De Giovanni]

Hi Tim,

OK, now I think I can see from your point of view. You're considering a
multi-protocol wrapper software on top of the same database, and it's
strange to see the dump file being advertised by one of the protocols when
it could be useful to any client. From a registry perspective, assuming
that non-TAPIR protocols are unlikely to ever give an indication about
dump files, this means that besides advertising all endpoints (each
protocol with a separate endpoint, I suppose) you will also want to
register the dump file as a separate link. A new service binding as you
said.

Anyway, regardless the protocol being used by the client it also seems
strange to use a specific protocol to interact with the provider but get
the information about dump files somewhere else. Since we have the chance
to still make adjustments in TAPIR, why not make things easier and more
consistent at least for TAPIR clients? If we do this, the multi protocol
wrapper could easily advertise the dump file twice: as an independent link
(if you wish) and as part of TAPIR capabilities.

Regarding the TapirLite example, it's not exactly a misuse, but it's
certainly good practice to periodically check the provider capabilities.
In your case, given any TAPIR endpoint, a generic TAPIR client should
ideally send a capabilities request first. If the two query templates are
supported, you can proceed to the search requests. If not, you can still
check if the provider supports the necessary output models. If they are
supported, you can proceed to the search requests. If not, you can still
check if the provider supports any output model and if the necessary
concepts are mapped. If the answer is yes, you can send exactly the same
search requests. If not, then the provider won't understand your search
requests. This would be the way to cover the 3 TAPIR profile levels. The
logic requires some understanding about TAPIR, but it's not complex.
However, it definitely helps if you use a generic TAPIR client library to
parse the capabilities for you and offer a few methods to return what you
need.

Best Regards,
--
Renato


> 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