[tdwg-tapir] ideas & TapirLite
Javier de la Torre
jatorre at gmail.com
Fri Nov 18 12:41:34 CET 2005
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.
On 18/11/2005, at 11:33, Döring, Markus wrote:
> I would like to get into the lite idea a bit more in detail.
> Lets start with the list of expected "levels" of tapir compliant
> services:
>
>
> 1- a full TAPIR service incl an experimental dynamic custom output
> model
>
> 2- a full TAPIR service restricted to certain output models
> identfied via a list of URLs pointing to the output model
> definition documents
>
> 3- a TAPIR Lite that only wants to accept certain parameters for
> fixed queries. The main idea as I can see is to have a limited list
> (maybe only 1?) of query templates here (reminder: QTs are filters
> & a URL reference to an output model) that define the accepted
> parameters. I assume this service also only works via http GET and
> not through xml messaging.
>
>
> The difference between level 1 & 2 is quite small (not necessarily
> for implementations though). The list of accepted output models
> simply go into the capabilities of a provider and a client can
> easily identfy if it is able to communicate with a datasource service.
>
> A level 3 TAPIR lite service is quite different from the others.
> Essentially its a regular GET based webservice that can be
> described by a WSDL, cause no serialised filter is allowed and the
> response model is fixed. If we really want to define these kind of
> simple services with the same protocol schema, what should be its
> "capabilities"?
> - only http GET invocation, no xml messaging
> - the TAPIR envelope should be supported for responses
> - ping, metadata, capabilites should work
> - no inventory operation
> - no (complex) filters or variables, only parameters
>
> If only parameters are accepted, then this is not a real search. In
> the old protocol this was a distinct "view" operation. What we want
> here is exactly this again. A service only available via http get
> and parameters. A list of accepted query templates would be enough
> and no operators, variables and alike need to be supported.
>
>
> The current definition of capabilities does only allow to specify
> http-GET only services or the accepted list of query templates by
> the way!
>
>
> A new adhoc idea: what about defining these 3 levels and allowing
> no other intermediate compliance? Then we can reduce the
> capabilities a lot, a lot of burden would be removed from clients
> and we would get more interoperability? Just a quick thought when
> looking at the above.
>
> We could make it as simple as this:
>
> <FullService accept_custom_models="false">
> <supportedModels>
> <model location="URI" namespace="">
> ...
> </supportedModels>
> <concepts>
> <concept id="..." />
> ...
> </concepts>
> </FullService>
>
> or
>
> <LiteService>
> <supportedQueryTemplates>
> <template location="URI">
> <parameter name="" />
> ...
> </template>
> ...
> </supportedQueryTemplates>
> </LiteService>
>
>
> What do you think?
> I am really a bit afraid of ending up with different services that
> implement only bits of the specification. We are about to move all
> burden towards the clients which for my feeling should be easy to
> create as a researcher with just simple programming knowledge.
>
>
> Sorry to raise this issue again and especially for this drastic new
> suggestion.
> It came up while writing this mail, so dont take it for a well
> thought idea. I just want to think a bit more about the problems
> involved in having variable and mutating tapir services.
>
> Markus
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Roger Hyam [mailto:roger at tdwg.org]
> Gesendet: Freitag, 18. November 2005 10:32
> An: Donald Hobern
> Cc: Döring, Markus; tdwg-tapir at lists.tdwg.org
> Betreff: Re: [tdwg-tapir] ideas & TapirLite
>
> 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
> -------------------------------------
>
>
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
More information about the tdwg-tag
mailing list