[tdwg-tapir] Updates and plans
"Markus Döring (GBIF)"
mdoering at gbif.org
Mon Oct 6 16:36:47 CEST 2008
I would like to discuss the optional bits of TAPIR capabilities again
in the light of service interoperability, especially when dealing with
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
- likewise cant logical operators and equals comparisons be mandatory
filter parts? what about greaterThan and lessThan?
On Oct 6, 2008, at 16:14, Markus Döring (GBIF) wrote:
> all proposals sound valuable and good to me. Working on my new TAPIR
> implementation I would like to propose another change.
> What do you think of removing the TAPIR lite option altogether and
> mandate tapir model support via KVP as the lowest option for
> compliant TAPIR services?
> I would at least have a discussion around this subject, as it
> effects TAPIR interoperability in networks a lot. And I think you
> didn't feel too comfortable when I said GBIF will implement
> TAPIRlite only. I am thinking of implementing model based TAPIR now
> because I see too many interoperability problems.
> what do you think? can we put this on the agenda for discussion at
> On Oct 6, 2008, at 15:14, Renato De Giovanni wrote:
>> Dear all,
>> As mentioned in the last message, I created a new page in the Wiki to
>> document possible changes in the protocol:
>> Please feel free to add your comments or suggest other changes. Use
>> Wiki or the mailing list.
>> If we decide to make any changes, they will be the last ones before
>> submitting TAPIR to the TDWG standards track. I would also like to
>> October 31st as the deadline to decide about this.
>> Best Regards,
>>> Dear all,
>>> I finally managed to update the TAPIR specification to reflect the
>>> issues discussed in this mailing list:
>>> I also updated the network builders' guide to include references
>>> to the
>>> new resources (TapirTester and TapirBuilder) and to recommend the
>>> new CNS
>>> encoding in XML instead of the old text file:
>>> The official links are already redirecting to these documents.
>>> I think it's time to consider submitting TAPIR to the TDWG standards
>>> track, but my feeling is that we should first wait for the annual
>>> since we're close to it anyway. There's no subgroup meeting
>>> planned for
>>> TAPIR this year, but the TDWG annual meeting is always an
>>> opportunity for
>>> most people here to interact and to see if there are any specific
>>> improvements we should still make in the protocol.
>>> I've been taking notes of additional changes that we could
>>> possibly make
>>> before finishing version 1.0. I'll try to organize this in the
>>> Wiki during
>>> the next days and I'll give you the link. We can then revise the
>>> list of
>>> possible changes and decide together what we should do.
>>> Please let me know if you have any ideas about this. I think we
>>> definitely finish TAPIR 1.0 this year and try to make it a TDWG
>>> Best Regards,
>> tdwg-tapir mailing list
>> tdwg-tapir at lists.tdwg.org
More information about the tdwg-tag