[tdwg-tapir] TapirLite

Mon Nov 21 16:37:28 CET 2005

Good Morning All,

I've been giving this some thought as well as I may be one of the people 
implementing client-side software.  I have much of the same concerns as 
Markus, that with the capabilities response as it stands generic clients 
will need to be exceedingly intelligent to prevent portals from 
supporting only the lowest common denominator of the feature set of all 
of its providers.

That being said, Renato is correct in his assessment of how providers 
have been setup in the past.  Most of the work with data sharing (at 
least in the US) has been through thematic networks (MaNIS, HerpNET, 
ORNIS and FishNET) with a small number of people configuring the data 
providers.  For situtations like these it is most likely the case that 
there will already be some minimum requirements that data providers must 
have.  It may be a close to full TAPIR implementation or even TAPIR Lite 
with query templates for that particular thematic network.  Either way, 
the clients for these networks will likely not require the intelligence 
that a generic TAPIR client will because enough of the capabilities will 
be known ahead of time that a functional portal could be written.

While this is generally true, there are some obvious situations where a 
more generic portal (ala DiGIR, but with a friendlier customizable user 
interface) would be desired.  Take the case where MaNIS is upgraded and 
John decided that each of the providers must implement TAPIR with search 
and operations and HerpNET is upgraded and decided to implement 
TAPIRLite with query templates.  For each of those thematic networks, 
the portal is fine because the developers of it know the capabilities 
before hand, but now assume a regional or institution portal is being 
setup that uses both MaNIS and HerpNET, they'll also have to write a 
custom portal that understands both TAPIR and the HerpNET specific 
implementation of TAPIRLite.  Further, say a portal wants to integrate 
specimen and taxon concept data, but the specimens implement TAPIR and 
all TCS providers are TAPIRLite.  Once again, the developers must write 
an entirely custom portal.

It would be nice if there was a baseline set of functionality that TAPIR 
providers must have rather than absolutely everything being optional and 
defined within the capabilities so that a generic portal could be 
written with a customizable user interface.

My thoughts on all of this are that at minimum search should be required 
by TAPIR implementations and that all operations except "in" should be 
required (which is not supported by RDF, but can be translated using 
boolean and comparative operators).  The question that seems to be the 
core of all of the recent concerns looks likes its boiling down too: 
"Are you a TAPIRLite implementation or a TAPIR implementation?"

Given that search and operations were mandatory for TAPIR 
implementations, it seems to me that the complexity of client-side code 
could be radically simplified if there was just a simple way for a 
provider to say "I'm a TAPIR Lite implementation."  This very well could 
be as Renato suggested, that operations are disabled or even that search 
is disabled (given that it is mandatory for TAPIR implementations).

Assuming the above was present in the TAPIR protocol and a mixed network 
of TAPIR/TAPIR Lite implementations, the generic portal's basic logic 
might look something like the following:

If Provider x is TAPIRLite:
   Find all query templates that match my output model

   As user constructs query, remove those query templates that could not
   possibly be used (missing concept, etc.)

   /* Likely more logic here if > 1 query templates are left
    * possibly with user interaction */

Else If Provider x is TAPIR:
   Ensure x supports my output model

   Can assume that search is available

   Can assume that operations (exception maybe "in") are supported

   /* If client is ambitious, may try to use any query templates defined
    * within search capabilities (would be same alg. as TAPIRLite), but
    * is optional */

The seems, at least on first glance by myself, to provide baseline 
functionality for both client/server side software that isn't just ping, 
capabilities and metadata.  This should improve on issues with 
interoperability as well as provide the minimum set of functionality 
that both client/server must support and can be rigorously tested. 
Further because the logic is vastly simplified, it would be feasible to 
compose a generic, customizable portal.

Anyway, just some thoughts...
- Rob

Renato De Giovanni wrote:
> Hi Markus,
> 
> I'm not sure that all client software will need to handle all 
> possible types of TAPIR providers. When writing a client for a 
> specific network, one could even assume the level of functionality 
> available from all providers and rely on the network registry (UDDI, 
> manual configuration file, or whatever) to point only to the 
> compatible ones.
> 
> On the other hand, I do agree that the new "operators" section in the 
> capabilities response is more complicated than necessary. I would 
> prefer to see "operators" an optional element (TapirLite would simply 
> not have it), but then we could make all other elements inside it 
> mandatory (except the custom ones). This way we could easily 
> distinguish minimalistic implementations, and at the same time get 
> rid of weird situations when a provider could offer the "and" 
> operator but not the "or", and things like that. In other words, if 
> "operators" is present, we could safely assume a lot of things 
> without adding much complexity to clients.
> --
> Renato
> 
> On 17 Nov 2005 at 16:25, Döring, Markus wrote:
> 
> 
>>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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: rgales.vcf
Type: text/x-vcard
Size: 322 bytes
Desc: not available
Url : http://lists.tdwg.org/pipermail/tdwg-tag/attachments/20051121/5d189c0c/attachment.vcf 