January 2009 - tdwg-tag - lists.tdwg.org

Final changes in TAPIR
by renato＠cria.org.br 02 Feb '09

02 Feb '09

Dear all, There are just two items left on the list of possible changes before submitting TAPIR to the TDWG standards track: 1) Allow custom operations to be declared as part of capabilities. I would suggest to simply include a new custom slot for this in the schema in case someone needs to use it in the future. 2) Allow dump files to be declared. This has been discussed some time ago in the TAPIR mailing list but we didn't come to a final conclusion. Since some networks are starting to harvest data by fetching entire dump files, I think it's important to allow TAPIR services to declare any dump files that may be available. Fetching a dump file from a provider and using incremental harvesting in later interactions with the service will probably be the most efficient approach. Since TAPIR generates XML output, it makes more sense to me to see dump files in XML. However, Tim/Markus (GBIF) are proposing another format for dump files using tab/csv files together with a metafile. It should be easy to allow both options when declaring a dump file in TAPIR capabilities, but I don't think it's the role of TAPIR to define specific formats. We can probably use something like this to declare dump files: <archives> <archive format="" location="" outputModel=""/> ... </archives> Where format could be "xml" or any custom term, and outputModel would be optional (only used with "xml" format). Things like date when the dump file was generated and whether it's gzipped or not could be additional attributes, but in most cases this can be discovered through the protocol used to retrieve the file, so in principle I would not include the attributes. Please let me know if this is an acceptable solution or if you have any different thoughts. Also let me know if you have any other ideas or suggestions about TAPIR in general. This is the time. I would like to finally submit specification & schema to the standards track in the beginning of the week. Best Regards, -- Renato -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

3 3

Re: [tdwg-tag] [tdwg-tapir] "partial" and "omit-ns" parameters
by renato＠cria.org.br 27 Jan '09

27 Jan '09

Hi Franck, Thanks for your comments and for your input about the suggested changes. I only wrote a few XSLTs for TAPIR responses and it was easy to handle namespaces. You basically just need to declare them in the root element and use the corresponding prefixes when referencing nodes. It worked with the two main browsers, so I don't know if there can be issues with other XSLT processors. Please note that, as it is now, "omit-ns" can only be used with the search operation when the TAPIR envelope is turned off. In all other situations, clients will need to handle namespaces anyway. We need to be careful about forcing providers to implement protocol features that may never be really used. Personally I was only expecting to keep these two features if: 1) there can be serious usability or interoperability issues if we don't keep them; 2) there are clients that are already making use of them; or 3) someone spent considerable time implementing them in a provider software besides TapirLink. Best Regards, -- Renato > Hi Renato, > > Congratulation to you and Markus for all your work! > > Removing the "partial" parameter seems also a good solution to me as it > would certainly make maintenance of the intermediate provider easier by > simplifying the code it needs. > > But I would maybe keep the "omit-ns" parameter if we plan to use XSLT > stylesheets to convert responses from the provider into webpages for > Internet browsers. > Namespace can be sometimes difficult to parse in xslt processor and > keeping this attribute would allow a better compatibility between search > responses and the "exclude-result-prefixes" xsl attribute. > > Best regards, > > Franck > > -----Original Message----- > From: tdwg-tapir-bounces(a)lists.tdwg.org > [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of > renato(a)cria.org.br > Sent: mercredi 21 janvier 2009 21:45 > To: tdwg-tapir(a)lists.tdwg.org > Subject: Re: [tdwg-tapir] "partial" and "omit-ns" parameters > > > Thanks, Tim. > > Actually the same provider can explicitly declare that it supports more > than one output model, so you don't need to have separate access points. > > Anyway, the most important thing is that clients/networks can create as > many response structures as necessary if they want to work with smaller > pieces of the same big schema. So I don't think we will lose so much if > we remove the "partial" parameter. > > Best Regards, > -- > > Renato > > >> Hi Renato, >> >> Congratulations with all your work. >> >>> I can see two solutions for this: 1) Specify that the "partial" >>> parameter only needs to be supported by TAPIR Full, which will make >>> the parameter >>> specification more intricate. 2) Remove the "partial" parameter from >>> the >>> protocol. >> >> Since there appears no strong demand, I would be in favor of it >> removed. For TAPIR Intermediate, a possible work around solution could > >> be 2 access points each with differing output models, one being a >> subset of the other? >> >>> Markus is also suggesting to remove the "omit-ns" parameter from the >>> protocol. "omit-ns" is used to indicate that search responses should >>> not include any namespaces at all. If this is not being used by any >>> network or >>> client, I also don't mind removing it. >> >> I personally have never had a need to use it. Most XML clients I use >> have a "namespaceAware" parameter anyway. >> >>> Please let me know if you have any feelings about this. >> >> Well done again Renato >> >> Tim -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

technical mailing lists
by "Markus Döring (GBIF)" 25 Jan '09

25 Jan '09

Dear technical friends of TDWG, you might remember we decided some time ago to merge all technical discussions on a single mailinglist, the tdwg-tag list. I therefore took the liberty to "close" the guid and the tapir lists so that no new subscriptions or posts can be done. An autoreply should inform users about the tag list and the existing archives are still publicly available, but no new ones will be created anymore. In addition I have also created a new mailing list tdwg-content which I will advertise on the other tdwg group lists, so that individual groups can decide whether they wanna close their list and move discussions to this central one. The darwin core group has already been invited and will start using this new mailing list for discussions about darwin core term definitions. Thanks for all your past & future contributions and best wishes, Markus

1 0

Re: [tdwg-tapir] "partial" and "omit-ns" parameters
by THEETEN Franck 23 Jan '09

23 Jan '09

Hi Renato, Congratulation to you and Markus for all your work! Removing the "partial" parameter seems also a good solution to me as it would certainly make maintenance of the intermediate provider easier by simplifying the code it needs. But I would maybe keep the "omit-ns" parameter if we plan to use XSLT stylesheets to convert responses from the provider into webpages for Internet browsers. Namespace can be sometimes difficult to parse in xslt processor and keeping this attribute would allow a better compatibility between search responses and the "exclude-result-prefixes" xsl attribute. Best regards, Franck -----Original Message----- From: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of renato(a)cria.org.br Sent: mercredi 21 janvier 2009 21:45 To: tdwg-tapir(a)lists.tdwg.org Subject: Re: [tdwg-tapir] "partial" and "omit-ns" parameters Thanks, Tim. Actually the same provider can explicitly declare that it supports more than one output model, so you don't need to have separate access points. Anyway, the most important thing is that clients/networks can create as many response structures as necessary if they want to work with smaller pieces of the same big schema. So I don't think we will lose so much if we remove the "partial" parameter. Best Regards, -- Renato > Hi Renato, > > Congratulations with all your work. > >> I can see two solutions for this: 1) Specify that the "partial" >> parameter only needs to be supported by TAPIR Full, which will make >> the parameter >> specification more intricate. 2) Remove the "partial" parameter from >> the >> protocol. > > Since there appears no strong demand, I would be in favor of it > removed. For TAPIR Intermediate, a possible work around solution could > be 2 access points each with differing output models, one being a > subset of the other? > >> Markus is also suggesting to remove the "omit-ns" parameter from the >> protocol. "omit-ns" is used to indicate that search responses should >> not include any namespaces at all. If this is not being used by any >> network or >> client, I also don't mind removing it. > > I personally have never had a need to use it. Most XML clients I use > have a "namespaceAware" parameter anyway. > >> Please let me know if you have any feelings about this. > > Well done again Renato > > Tim -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir ########################################### This message has been scanned by ICT - Africa Museum ________________________________________ 22/1/2009 - Filtered through antispam by ICT

2 1

[tdwg-tapir] "partial" and "omit-ns" parameters
by renato＠cria.org.br 21 Jan '09

21 Jan '09

Dear all, I finished almost all changes both in the TAPIR schema and the specification, except for the new "dump file" capability. Next week there will be a meeting at GBIF, and since this is one of the things to be discussed, there will soon be another message here to finally make a decision. After this, I think TAPIR should be ready for standardization. I've been also in contact with Markus, who's developing the new GBIF IPT provider. This will be the first implementation of a provider belonging to the category "Intermediate". For those who are unfamiliar with this, TAPIR providers can support different features, so at some point we decided to define 3 main categories of providers: * TAPIR Lite: Providers that only support pre-defined query APIs (fixed set of parameters and output models); * TAPIR Intermediate: Providers that allow custom filters on a fixed set of output models; * TAPIR Full: Providers that allow fully customized responses. The main reason for the Intermediate category was to remove the burden of parsing and interpreting output models and response structures. However, according to the specification, one of the parameters that TAPIR Intermediate providers need to support is the "partial" parameter. This parameter is used to point to one or more nodes in the response structure and force search responses to exclude all other nodes. This feature came from the BioCASe protocol to retrieve specific parts of huge schemas like ABCD. The problem is that all mandatory nodes according to the output model need to be present in the response, even if they are not specified in the "partial" parameter. This way we avoid invalid XML, but this requires knowledge about the output model, which contradicts the original reason for creating the Intermediate category. I can see two solutions for this: 1) Specify that the "partial" parameter only needs to be supported by TAPIR Full, which will make the parameter specification more intricate. 2) Remove the "partial" parameter from the protocol. Since the protocol already allows different response structures to be defined and used, and BioCASe doesn't need to use the "partial" parameter anymore (to the best of my knowledge), I'm currently in favor of removing the parameter from the protocol to simplify things - unless this is being used by some other network (please let me know!). Markus is also suggesting to remove the "omit-ns" parameter from the protocol. "omit-ns" is used to indicate that search responses should not include any namespaces at all. If this is not being used by any network or client, I also don't mind removing it. TapirLink supports both "partial" and "omit-ns" parameters. If they get removed from the protocol I'll still keep them as unofficial parameters in any case. Please let me know if you have any feelings about this. Best Regards, -- Renato -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

2 2

[tdwg-tapir] [AOC 2009]: Call for Papers
by Emilio Ancillotti 15 Jan '09

15 Jan '09

[Our apologies for possible duplicates] --------------------------------------------------------------- CALL FOR PAPERS Third IEEE WoWMoM Workshop on Autonomic and Opportunistic Communications (AOC 2009) June 15, 2009 - Island of Kos (Greece) http://cnd.iit.cnr.it/aoc2009/ jointly organized by the SOCIALNETS project funded by the FET-IST Programme under the FET proactive initiative on Pervisive Adaptation (PerAda) http://www.social-nets.eu ANA project funded by the FET-SAC Programme in the area Situated and Autonomic Communications (SAC) http://www.ana-project.org/ Fast Track on Computer Communications Journal http://www.elsevier.com/locate/comcom **** Submission Deadline --- 5 February 2008 **** --------------------------------------------------------------- The goal of this workshop is to provide a forum between the autonomic and opportunistic communication communities to exchange ideas, discuss solutions, and share experiences among researchers, professionals, and application developers both from industry and academia. The synergies between autonomic and opportunistic communications & social networks studies and technologies are one of the primary interests of this yearâ€™s edition. Original papers addressing both theoretical and practical aspects of autonomic and opportunistic communications and are solicited. Papers describing prototype implementations and deployments are welcome. Topics of interest include but are not limited to: * Architecture and models for autonomic and opportunistic communications * Economic, biological and social models used for autonomic and opportunistic communications * Social networking technologies applied to autonomic and opportunistic communications * Tools and techniques for designing, analysing and building autonomic and opportunistic networks * Adaptive security for self protection of networks * Mobility models for opportunistic networking * Novel management techniques for autonomic and opportunistic communications * Sensing, monitoring and measurements for self-managing networks * Advanced technologies for enabling autonomic and opportunistic communications * Autonomic and opportunistic communication testbeds and measurements * Algorithmic aspects associated with autonomic communications environments and problems PAPER SUBMISSION AND PUBLICATION -------------------------------- Papers should neither have been published elsewhere nor currently under review by another conference or journal. Guidelines on paper submission and formatting are available at http://cnd.iit.cnr.it/aoc2009/. Accepted papers will appear in the symposium proceedings published by IEEE. At least one author of each accepted paper is required to register and present their work at the workshop. Extended versions of workshop selected papers will be considered for possible fast track publication on the Computer Communications Journal (Elsevier). IMPORTANT DATES --------------- Full papers due: 5 February, 2009 Notification: 23 March, 2009 ORGANIZING COMMITTEE -------------------- WORKSHOP Chairs Andrea Passarella, IIT-CNR, Italy Konstantinos Oikonomou, Ionian University, Greece STEERING Committee Marco Conti, IIT-CNR, Italy Silvia Giordano, SUPSI, Switzerland Ioannis Stavrakakis, University of Athens, Greece PUBLICITY Co-Chairs Emilio Ancillotti, IIT-CNR, Italy Nikolaos Laoutaris, Telefonica Research, Spain PROGRAM COMMITTEE (confirmed) ----------------------------- Mostafa Ammar, Georgia Institute of Technology, USA Giuseppe Anastasi, University of Pisa, Italy Eleonora Borgia, IIT-CNR, Italy Levente Buttyan, BUTE, Hungary Vania Conan, Thales, France Franca Delmastro, IIT-CNR, Italy Falko Dressler, University of Erlangen-Nuremberg, Germany Serge Fdida, UPCM Paris VI, France Philip Ginzboorg, Nokia, Finland Mohan Kumar, University of Texas at Arlington, USA Emmanouil V. Magkos, Ionian University, Greece Cecilia Mascolo, University of Cambridge, UK Daniele Miorandi, Create-net, Italy Refik Molva, EurÃ©com, France Joerg Ott, HUT, Finland Antonios Panagakis, University of Athens, Greece Symeon Papavassiliou, NTUA, Greece Giovanni Pau, UCLA, USA Calicrates Policroniades, Telenor, Norway George Polyzos, AUEB, Greece Konstantinos Psounis, University of Southern California, USA Christian Rohner, Uppsala University, Sweden Fabrizio Sestini, EU Commission Thrasyvoulos Spyropoulos, ETH Zurich, Switzerland Pablo Vidales, Deutsche Telekom Laboratories, Germany Roger Whitaker, Cardiff University, UK Christos Xenakis, University of Piraeous, Greece Eiko Yoneki, University of Cambridge, UK Franco Zambonelli, University of Modena-Reggio, Italy -- ============================================================ Ing. Emilio Ancillotti, PhD Pervasive Computing & Networking Lab. (PerLab) Institute for Informatics and Telematics (IIT) National Research Council (CNR) Via G. Moruzzi, 1 || voice: +39 050 315 2437 56124 Pisa, Italy || fax: +39 050 315 2113 || mobile: +39 328 2963760 ============================================================

1 0

[tdwg-tapir] TapirJChirp
by renato＠cria.org.br 07 Jan '09

07 Jan '09

Dear all, In case there's someone else interested in a generic Java client library for TAPIR, James Ytow recently ported the tapirChirp PHP library. You can check out the source code from sourceforge using the following Subversion address: https://digir.svn.sourceforge.net/svnroot/digir/TapirJChirp/trunk To run a simple capabilities test: java -cp . org.tdwg.tapir.TAPIRClient some_tapir_end_point According to James, the remaining works are: - API documentation (cut-and-paste from TapirChirp PHP code?). - Implementation of a TAPIR finder using GBIF UDDI. Anyone willing to collaborate will be certainly more than welcome. Best Regards, -- Renato -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

[tdwg-tapir] r1422 - tapir/dev/schema
by svn＠rs.tdwg.org 07 Jan '09

07 Jan '09

Author: RenatoDeGiovanni Date: 2009-01-07 14:02:45 +0100 (Wed, 07 Jan 2009) New Revision: 1422 Modified: tapir/dev/schema/tapir.xsd Log: Added new <rootElement> in the output model definition to indicate the name of a global element that should be the root element in search responses. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2009-01-07 12:48:54 UTC (rev 1421) +++ tapir/dev/schema/tapir.xsd 2009-01-07 13:02:45 UTC (rev 1422) @@ -252,6 +252,15 @@ </xsd:choice> </xsd:complexType> </xsd:element> + <xsd:element name="rootElement" minOccurs="0"> + <xsd:annotation> + <xsd:documentation>Name of a global element that should be the root element in + search responses. When not specified, the first global element should be used.</xsd:documentation> + </xsd:annotation> + <xsd:complexType> + <xsd:attribute name="name" type="xsd:string" use="required"/> + </xsd:complexType> + </xsd:element> <xsd:element name="indexingElement"> <xsd:annotation> <xsd:documentation>A simple XPath pointing to a response structure node that

1 0

[tdwg-tapir] r1420 - tapir/dev/schema
by svn＠rs.tdwg.org 07 Jan '09

07 Jan '09

Author: RenatoDeGiovanni Date: 2009-01-07 13:44:37 +0100 (Wed, 07 Jan 2009) New Revision: 1420 Modified: tapir/dev/schema/tapir.xsd Log: Added type attribute (organization or person) to related entities. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2009-01-07 12:33:17 UTC (rev 1419) +++ tapir/dev/schema/tapir.xsd 2009-01-07 12:44:37 UTC (rev 1420) @@ -1779,6 +1779,14 @@ </xsd:element> <xsd:element ref="custom" minOccurs="0"/> </xsd:sequence> + <xsd:attribute name="type" use="optional" default="organization"> + <xsd:simpleType> + <xsd:restriction base="xsd:string"> + <xsd:enumeration value="organization"/> + <xsd:enumeration value="person"/> + </xsd:restriction> + </xsd:simpleType> + </xsd:attribute> <xsd:attribute ref="xml:lang" use="optional"/> </xsd:complexType>

1 0

[tdwg-tapir] r1418 - tapir/dev/schema
by svn＠rs.tdwg.org 07 Jan '09

07 Jan '09

Author: RenatoDeGiovanni Date: 2009-01-07 13:26:51 +0100 (Wed, 07 Jan 2009) New Revision: 1418 Modified: tapir/dev/schema/tapir.xsd Log: Removed xslt-apply parameter and xslt capability. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2009-01-07 12:17:52 UTC (rev 1417) +++ tapir/dev/schema/tapir.xsd 2009-01-07 12:26:51 UTC (rev 1418) @@ -841,7 +841,6 @@ </xsd:complexType> <xsd:attributeGroup name="globalParametersGroup"> <xsd:attribute name="xslt" type="xsd:anyURI" use="optional"/> - <xsd:attribute name="xslt-apply" type="xsd:boolean" use="optional" default="false"/> <xsd:attribute name="log-only" type="xsd:boolean" use="optional" default="false"/> </xsd:attributeGroup> <xsd:attributeGroup name="pagingParametersGroup"> @@ -996,7 +995,6 @@ </xsd:restriction> </xsd:simpleType> </xsd:element> - <xsd:element name="xlst" minOccurs="0"><xsd:complexType/></xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element>

1 0