[tdwg-tapir] ideas & TapirLite

Renato De Giovanni renato at cria.org.br
Mon Nov 21 19:35:43 CET 2005

Hi Javier,

Query templates in particular do remind part of the idea behind WSDL, 
although WSDL only provides service descriptions at the syntactic 
level (probably in a more complete and better way than we're doing).
However we do have things related to semantics (the "mapping" 

I agree that it sounds a bit strange to see TAPIR being used only 
based on query templates (the APIs for TapirLite). But please 
remember that query templates (originally "views") were proposed in a 
very specific context, as I better explained in my previous message. 
We didn't want to reinvent the wheel, we just wanted to provide easy 
links on top of our services. And to make that happen, we only needed 
to include the "parameter" element as part of filters. All other view 
components were present in regular search operations.

On the other hand, I see no strong reasons to avoid TapirLite at this 
moment. The biggest difference between original Tapir and TapirLite 
was the dynamic view part, which is removed now. The other 
differences still don't make me believe that clients will necessarily 
become ovely complex. As Roger said, having both approaches under the 
Tapir fold could be beneficial in the long run, although it seems we 
cannot tell that in advance. But at least both types of service will 
share a common metadata and capabilities format. And if I'm a 
taxonomic concepts provider using a full-featured Tapir software, I 
can be easily plugged in a TapirLite TCS network (but not the other 
way around).


On 18 Nov 2005 at 12:41, Javier de la Torre wrote:

> Hi all,
> Well Markus, for me this looks like a very different approach... and 
> I think it makes sense, but I think this distinctions between 
> services should not be done in TAPIR and in its capabilities. If you
> take a look at your new proposal for capabilities it looks   like a
> WSDL file where you describe the kind of service that is  behind a web
> service. The kind of clients we will have to develop to  access a
> network like this will have to be quite complex, first  taking a look
> at the capabilities to know how to query a data  provider and then
> query them. What in reality will happen is that  portals, clients,
> will have their own registry where they store the  information about
> the data providers that they want to use and how  they can access
> them. At the end is like a UDDI where you define  different tmodels.
> Then, why don't we forget about the TAPIRLite idea and we consider 
> that some data providers will not use TAPIR but rather some simple 
> web service tmodels (that we will provide them) to access them.
> Eventually we could also ask TAPIR implementations to provide a WSDL 
> file where they emulate these tmodels.
> If you are a client that needs to get the data from all possible data 
> providers you will probably use these simple web services interfaces. 
> With this you will create your cache and your portal on top of it. If
> you are a client that wants to send dynamic queries to data 
> providers, or have more interaction with them using inventories and 
> things like that, then you will use TAPIR and probably you will 
> discard non TAPIR compliant data providers.
> Javier.

More information about the tdwg-tag mailing list