[tdwg-tapir] ideas & TapirLite
Renato De Giovanni
renato at cria.org.br
Mon Nov 21 19:35:43 CET 2005
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
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.
More information about the tdwg-tag