81 lines
3.5 KiB
Plaintext
81 lines
3.5 KiB
Plaintext
head 1.1;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.1
|
|
date 2008.09.26.18.50.38; author RenatoDeGiovanni; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@%META:TOPICINFO{author="RenatoDeGiovanni" date="1222455038" format="1.1" reprev="1.1" version="1.1"}%
|
|
%META:TOPICPARENT{name="WebHome"}%
|
|
---+++ History about the Integration Process
|
|
|
|
---++++ Introduction
|
|
|
|
During the 2004 TDWG meeting in Christchurch, NZ, the presented unified protocol was named TAPIR, TDWG Access Protocol for Information Retrieval. It was agreed to start testing the protocol by reimplementing two data provider software, each one carried out by one of the existing network communities, [[BiocaseProtocol][BioCASe]] and [[DigirProtocol][DiGIR]].
|
|
|
|
---++++ General Protocol Requirements
|
|
|
|
* Integrate the CurrentProtocols being used by different networks from the biodiversity informatics community.
|
|
* Try to accommodate the needs of other BiodiversityDataStandards.
|
|
* Keep the protocol generic so that other communities (not only biodiversity informatics) could use it and possibly collaborate.
|
|
* Try to impose minimum impact on SoftwareRelatedToPreviousProtocols.
|
|
|
|
---++++ Preparatory Documentation
|
|
|
|
* DifferencesBetweenProtocols: Documentation about differences between the CurrentProtocols.
|
|
* DifferencesTapirWfs: Documentation about the differences between TAPIR and Web Feature Service (WFS) from OGC
|
|
|
|
---++++ Integration Proposals
|
|
|
|
* ProposalPresentedInTdwg 2004 as [[http://ww2.biocase.org/svn/tapir/tags/protocol/proposal_2004/report.pdf][PDF]], [[http://ww2.biocase.org/svn/tapir/tags/protocol/proposal_2004/protocol.xsd][XML schema]]
|
|
* Older proposals
|
|
* FirstProposal, XQuery based
|
|
* SecondProposal, straightforward approach (schema: http://www.bgbm.org/biodivinf/Schema/protocol2.xsd)
|
|
* ThirdProposal, the same as the second proposal but using SOAP
|
|
* FourthProposal, based on the SecondProposal but incorporating the BerlinMeetingResults
|
|
* FifthProposal, current proposal based on the SecondProposal, FourthProposal and incorporating new suggestions/changes since the BerlinProtocolMeeting
|
|
* [[LatestProposal][Last proposal documented on the Wiki]]
|
|
|
|
---++++ Requested Features
|
|
|
|
* Some AdditionalIdeas that were discussed in the past.
|
|
|
|
---++++ Output model issues
|
|
(output models used to be called views, thats why you will still find the term view being mentioned in some places)
|
|
|
|
Are models determinate or do they depend upon the providers datasource structure? Is the current model definition sufficient? In particular some potential problems have surfaced during the PyWrapper implementation:
|
|
|
|
* EmptyRepeatableRegionProblem
|
|
* IndexingElementExplosion
|
|
|
|
To address these issues the following options are being considered:
|
|
|
|
* SemanticMapping: Use ontologies to do the output model mapping
|
|
* DroppingDynamicOutputModels: Restrict providers to offer a set of predefined output models.
|
|
* ObjectOrientedApproach: Make TAPIR truly object oriented and serve interlinked, compound objects instead of XML documents. A very different approach which causes a lot of reorganisation of the protocol. Promosing for the future in a time where GUIDs are omnipresent.
|
|
|
|
Dynamic processing of output models is considered experimental. Data providers are encouraged to declare the specific output models that are supported by them.
|
|
|
|
---++++ Meetings
|
|
|
|
* BerlinProtocolMeeting and the BerlinMeetingResults
|
|
* [[MadridResults2005][Madrid protocol meeting results]]
|
|
* TapirWorkshop2007 (Copenhagen)
|
|
@
|