[tdwg-tapir] ideas & TapirLite
Roger Hyam
roger at tdwg.org
Fri Nov 18 10:31:36 CET 2005
As TapirLite champion I do have a problem with having to implement all
the operators. I just want to be pretty and dumb! I don't have a problem
with the concept of a named subset protocol i.e. Tapir (the real thing)
and TapirLite (the not so bright second cousin).
Are there some use cases somewhere listing what Tapir clients are
expected to call or some statistical break down of what kinds of queries
are run against existing BioCASE and DiGIR providers?
Roger
Donald Hobern wrote:
> Markus,
>
> Doesn't "all operations" imply that the provider must implement generic
> search operations? Isn't a large part of the reason for TAPIR Lite the need
> to support "databases" that cannot be mapped using the standard RDBMS
> mapping and which are just trying to emulate common views?
>
> I would say that these should be supported but that each TDWG content
> subgroup needs to define a set of (web service) interfaces that must be
> supported by any compliant provider. If they can handle this set of views,
> they may appear as TAPIR providers.
>
> Or did I miss something?
>
> Donald
>
> ---------------------------------------------------------------
> Donald Hobern (dhobern at 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
> ---------------------------------------------------------------
>
>
> -----Original Message-----
> From: tdwg-tapir-bounces at lists.tdwg.org
> [mailto:tdwg-tapir-bounces at lists.tdwg.org] On Behalf Of "Döring, Markus"
> Sent: 17 November 2005 16:25
> To: tdwg-tapir at lists.tdwg.org
> Subject: [tdwg-tapir] ideas & TapirLite
>
> Hi,
> talking to Anton today we were wondering if it makes sense to allow a tapir
> client to embed its own request-id into the tapir headers for later
> identification of asynchronous and distributed messages. Currently we would
> need to identify a message by its sendtime (vague) and source.
>
> Does this make sense? Does anyone know how other people deal with this
> problem?
>
> -----------
>
> The other thoughts were about TapirLite.
> We both think its a very bad idea to push all responsibility to the client
> by allowing any TAPIR service to be very minimalistic. If a client should be
> able to contact services that have different operators, operations and
> concepts, then I dont think we will get anything interoperable.
>
> I still prefer that these things must exist in the most basic TAPIR service.
> Otherwise we should call it different - maybe even TAPIR Lite as a valid
> subset:
> - all operations
> - all logical operators
> - the main COPs (<=> like)
>
> Cconcepts and response models can be optional without much problems I think.
> What do you think? should we sacrifice all this to have few clients but many
> providers?
>
> BTW, I think we didnt specify anywhere in capabilities if GET or XML
> Messaging is supported. So the idea is to always have both for all services,
> right?
>
>
> Markus
>
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
>
>
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
>
>
--
-------------------------------------
Roger Hyam
Technical Architect
Taxonomic Databases Working Group
-------------------------------------
http://www.tdwg.org
roger at tdwg.org
+44 1578 722782
-------------------------------------
More information about the tdwg-tag
mailing list