Renato,
Thanks for that. Great diagram!
If I read it correctly the number of non-DiGIR (i.e. SOAP) providers is more than double the number of DiGIR providers so to say that speciesLink is DiGIR network is only describing the public facing part of it. In a way it is more like a SOAP network with a DiGIR backbone.
I am currently putting together a series ANT build files with an AntForms interface for day to day use. It will effectively do the job of your Java client. I figured it was the easiest way to build configurable pipelines with some common components.
I intend to base the table structure on a TAPIR CNS. The CNS files effectively flatten the ontology into a table in a predictable way - but without the opportunity to have repeating properties. The server side tables can then have the same schema.
The only downside of this is the need to have a table for any one to many relationship such as multiple identifications of specimens.
I may put a wiki page on the TAG wiki about this if I get a chance as it would be good for people to share experiences and know what resources are available.
All the best,
Roger
On 14 May 2007, at 17:34, Renato De Giovanni wrote:
Hi Roger,
The speciesLink network makes use of regional servers to mirror data from collections that cannot set up a provider service. Some of them still use dial-up connections for instance. The following diagram is not up- to-date but gives an idea of how many collections are using this approach in the network:
http://splink.cria.org.br/manager/pdf/esquema.pdf
We had to define our own protocol to achieve this. It's based on SOAP and it has limitations such as only handling tabular data, but it does its job. We developed a client software in Java which is installed on providers' machines and has many interesting features. The newest ones include automatic updates of the software, and the possiblity of choosing mapping templates for specific collection management systems.
Best Regards,
Renato
Hi Everyone,
There is a requirement that all wrapper type applications (TAPIR, DiGIR, BioCASe and others) have but that I don't think we address.
All instances need to have:
Either a database on a server in a DMZ or with an ISP with the ability to export data from the production database to the public database and then keep changes in the production database synchronize with the public database.
Or the ability to provide a secured/restricted connection directly to production database through the firewall.
Configuring the wrapper software against a database seems a smaller problem than getting a handle on an up to date database to configure it against!
Should we have a recommended strategy or best practice for overcoming these problems? Do we have any figures on how they are overcome in the existing BioCASe and DiGIR networks?
Many thanks for your thoughts,
Roger
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir