[tdwg-tapir] Updates and plans

Tim Robertson (GBIF) trobertson at gbif.org
Sun Oct 12 00:28:54 CEST 2008


Hi Renato, Markus, Kevin et al

Should a dump file really have anything to do with TAPIR?  I would have
expected to see it external to TAPIR spec - not to say that the wrapper
software can't be a TAPIR wrapper plus a 'dump file' wrapper at the same
time.

Similarly with TAPIRLite - maybe I don't get it right, or perhaps it was
the early adopters, but one can be a TAPIRLite provider while only
answering one search URL pointing at a custom query template with say a
couple of GET params passed in, only support a custom response schema, yet
claim TAPIR compliance - is this technically correct?

What say you guys?
Looking forward to discussing with you all.

Cheers from Singapore Airport,

Tim





> Hi Markus,
>
> Sorry about the delay - I've just returned from a workshop.
>
> If I understood your suggestion correctly, all TAPIR providers would need
> to parse filters, understand search requests with the model parameter, and
> support inventories in any concepts. This means that query templates would
> not be necessary anymore, right?
>
> I think it's quite a big change at this point and it will impact existing
> provider implementations that follow the current TAPIRLite approach.
>
> If there's any serious interoperability problem now, we need to
> investigate it carefully before making this kind of change. I understand
> that raising the minimum service profile level can in principle make
> things easier for clients. But if this is going to make things too
> difficult for new provider implementations, one of the possible
> consequences is to see other protocols or even unofficial variations of
> TAPIR being used, which can be worse than having a single protocol with
> different service profiles.
>
> What I do think we're missing is guidelines for different types of
> providers and networks. Simple documents, 1 or 2 pages, with clear
> recommendations such as what conceptual schemas, output models and query
> templates to use.
>
> Some comments about your specific suggestions:
>
>> the inventory and search operation is optional. Is there a need for
> services not supporting them?
>
> We were probably too flexible when we made them optional. However, now
> that we're considering a change that will allow providers to advertise
> dump files, I'm just thinking if this can be acceptable: "here's my
> metadata, here's the conceptual schemas that I mapped and here's a dump
> file, but I still don't support inventories and searches". If we don't
> want to allow this, then at least the search operation could be mandatory.
> Or maybe both search and inventory, as you suggested.
>
>> any need for inventory operations not to support anyConcept?
>
> I don't know if there's any TAPIR provider not supporting them (anyone
> here?). If not, perhaps we can change. Anyway, I think we still need to
> allow inventory templates for providers that won't support filters.
>
>> search operation should mandate at least 1 output model support
>
> This is related with dropping TAPIRLite. I'm not convinced that this would
> be a good change.
>
>> cant concept, literal and parameter expressions in filters be mandatory?
>> likewise cant logical operators and equals comparisons be mandatory
> filter parts? what about greaterThan and lessThan?
>
> I didn't understand this. Are you talking about capabilities or about the
> filter definition in the XML Schema? Can you give some example?
>
> Best Regards,
> --
> Renato
>
> PS: I'm traveling next week, so I may not be able to respond promptly. By
> the way, we can also discuss this during TDWG.
>
>
>
>> Dear all,
>> I would like to discuss the optional bits of TAPIR capabilities again
>> in the light of service interoperability, especially when dealing with
>> TAPIR lite.
>> Do we really need to have so many optional capabilities for TAPIR? I
>> do firmly think this is causing more problems than benefits and would
>> prefer more mandatory capabilities. In particular I think TAPIR model
>> support should be the lowest common denominator and not only templates
>> as it is currently for TAPIR lite.
>>
>> Do the following capabilities really need to optional?
>>
>> - the inventory and search operation is optional. Is there a need for
>> services not supporting them?
>> - any need for inventory operations not to support anyConcept?
>> - search operation should mandate at least 1 output model support
>> - cant concept, literal and parameter expressions in filters be
>> mandatory?
>> - likewise cant logical operators and equals comparisons be mandatory
>> filter parts? what about greaterThan and lessThan?
>>
>>
>> regards,
>> Markus
>
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
>
>


____________________________________________________________
Tim Robertson
Systems Architect
Global Biodiversity Information Facility Secretariat  (GBIF)
Universitetsparken 15, 2100 Copenhagen Ø, Denmark
http://www.gbif.org
trobertson at gbif.org
Phone: +45 35 32 14 87 (Office)
Fax: +45 35 32 14 80
____________________________________________________________




More information about the tdwg-tag mailing list