January 2007 - tdwg-tag - lists.tdwg.org

[Tdwg-guid] Demise of Phyloinformatics journal
by Roderic Page 19 Feb '07

19 Feb '07

The Open Access web-only journal "Phyloinformatics" seems to have disappeared, with the Internet address http://www.phyloinformatics.org now up for sale. This means the articles have just disappeared! There weren't many papers published, but some were interesting and have been cited in the mainstream literature. This also illustrates the problems with linking to digital resources using URLs, as opposed to identifiers such as DOIs. With the loss of the domain name, this journal has effectively died. A sobering lesson... Regards Rod ------------------------------------------------------------------------ ---------------------------------------- Professor Roderic D. M. Page Editor, Systematic Biology DEEB, IBLS Graham Kerr Building University of Glasgow Glasgow G12 8QP United Kingdom Phone: +44 141 330 4778 Fax: +44 141 330 2792 email: r.page(a)bio.gla.ac.uk web: http://taxonomy.zoology.gla.ac.uk/rod/rod.html iChat: aim://rodpage1962 reprints: http://taxonomy.zoology.gla.ac.uk/rod/pubs.html Subscribe to Systematic Biology through the Society of Systematic Biologists Website: http://systematicbiology.org Search for taxon names: http://darwin.zoology.gla.ac.uk/~rpage/portal/ Find out what we know about a species: http://ispecies.org Rod's rants on phyloinformatics: http://iphylo.blogspot.com Rod's rants on ants: http://semant.blogspot.com

6 7

[tdwg-tapir] TapirLink is available
by Renato De Giovanni 30 Jan '07

30 Jan '07

Dear all, There's a new fully functional TAPIR provider software available to our community. TapirLink is based on the well-known DiGIR PHP provider. So those who already have the DiGIR provider can simply run TapirLink in a separate instance since it doesn't require any extra libraries or software. It's also possible to import the DiGIR provider configuration. At this point there may still be some bugs to be fixed before it gets stable enough for a production environment, but I already invite those who are interested to give it a try: https://sourceforge.net/project/showfiles.php?group_id=38190&package_id=217… If you have any questions or find any issues please feel free to contact me. There's also the sourceforge tracker that can be used: https://sourceforge.net/tracker/?group_id=38190&atid=422311 Best Regards! -- Renato

2 1

LsidVocs
by Bob Morris 29 Jan '07

29 Jan '07

I'm eager to study these in detail. In the case of the XML-Schema representations, which I want to try to incorporate in several schemas, the import Schema Locations are relative and so it would be very helpful to have some kind of access to the actual schemas used in the imports. The most robust might be public read access to the SVN server holding these schemas. Bob -- Robert A. Morris Professor of Computer Science UMASS-Boston http://www.cs.umb.edu/~ram phone (+1)617 287 6466

2 1

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

24 Jan '07

Author: MarkusDoering Date: 2007-01-24 11:36:00 +0100 (Wed, 24 Jan 2007) New Revision: 812 Modified: tapir/dev/schema/tapir.xsd Log: Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-01-23 15:45:03 UTC (rev 811) +++ tapir/dev/schema/tapir.xsd 2007-01-24 10:36:00 UTC (rev 812) @@ -1698,11 +1698,11 @@ </xsd:annotation> <xsd:complexType> <xsd:sequence> - <xsd:any maxOccurs="unbounded"> + <xsd:any maxOccurs="unbounded" namespace="##targetNamespace" processContents="skip"> <xsd:annotation> <xsd:documentation>Single values for each concept. The sequence of the values should correspond to the sequence used in the - request.</xsd:documentation> + request. The elements should be within the TAPIR namespace, but as they cannot all be defined by this schema the validation should be skipped</xsd:documentation> </xsd:annotation> </xsd:any> </xsd:sequence>

1 0

[tdwg-tapir] Recent changes
by Renato De Giovanni 23 Jan '07

23 Jan '07

Dear all, I've just updated the schema and the specification to include the changes that I mentioned in a previous e-mail. The specification now contains a new section "history of changes" to document all relevant changes since its first public release (it doesn't include minor changes related to grammar, mispelling errors and small additions to clarify specific parts of the document). Three things that I should mention: * I didn't make any change about having a single case-sensitivity configuration because I found in the specification that "in" operators should use the case-sensitivity capability specified for the "equals" operator. * I took the liberty to include a new KVP parameter "tagname" or "n" corresponding to the new optional attribute "tagName" for inventory concepts. * I took the liberty to include a new KVP parameter "descend" or "d" corresponding to the "descend" attribute in orderBy concepts (it was missing in the KVP encoding). * I used "source-ip" instead of "source_ip" to keep consistency with the other global parameter names. Please let me know in case there's any issue with the changes. Best Regards, -- Renato

1 0

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

23 Jan '07

Author: RenatoDeGiovanni Date: 2007-01-23 16:20:07 +0100 (Tue, 23 Jan 2007) New Revision: 808 Modified: tapir/dev/schema/tapir.xsd Log: * Removed maxOccurs="unbounded" from indexingElement. * Changed documentation for <basicSchemaLanguage/> removing simpleContent and complexContent. * Included optional attribute "tagName" in inventory <concept> elements. * Changed subelements of inventory concepts to xsd:any. * Added optional "alias" attribute to capabilities/concepts/schema. * Removed default="1" for the "limit" attribute. * Element <variable> is not abstract anymore. Its previous concrete representations are now pre-defined attribute values from an extensible controlled vocabulary of a new "name" attribute. * Changed subelements of capabilities/variables/environment to xsd:any and removed <custom> subelement. * Changed use of header/source@accesspoint to optional. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-01-23 12:24:06 UTC (rev 807) +++ tapir/dev/schema/tapir.xsd 2007-01-23 15:20:07 UTC (rev 808) @@ -1,4 +1,4 @@ -<?xml version="1.0"?> +<?xml version="1.0"?>  <xsd:schema targetNamespace="http://rs.tdwg.org/tapir/1.0" xmlns="http://rs.tdwg.org/tapir/1.0" @@ -151,7 +151,7 @@ </xsd:complexType> </xsd:element> </xsd:sequence> - <xsd:attribute name="accesspoint" type="xsd:anyURI" use="required"/> + <xsd:attribute name="accesspoint" type="xsd:anyURI" use="optional"/> <xsd:attribute name="sendtime" type="xsd:dateTime" use="required"/> </xsd:complexType> </xsd:element> @@ -255,7 +255,7 @@ </xsd:choice> </xsd:complexType> </xsd:element> - <xsd:element name="indexingElement" maxOccurs="unbounded"> + <xsd:element name="indexingElement"> <xsd:annotation> <xsd:documentation>A simple XPath pointing to a response structure node that should be used as a reference for counting.</xsd:documentation> @@ -345,9 +345,9 @@ <xsd:sequence> <xsd:element name="concept" maxOccurs="unbounded"> <xsd:annotation> - <xsd:documentation>Repeatable element. One or more concepts to be used for ordering the + <xsd:documentation>One or more concepts to be used for ordering the model. If the attribute "descend" is set to true, a descending - ordering will be used instead of the default ascending one.</xsd:documentation> + order will be used instead of the default ascending one.</xsd:documentation> </xsd:annotation> <xsd:complexType> <xsd:complexContent> @@ -389,11 +389,20 @@ </xsd:annotation> <xsd:complexType> <xsd:sequence> - <xsd:element name="concept" type="qualifiedConceptReferenceType" minOccurs="1" maxOccurs="unbounded"> - <xsd:annotation> - <xsd:documentation>A single qualified concept</xsd:documentation> - </xsd:annotation> - </xsd:element> + <xsd:element name="concept" maxOccurs="unbounded"> + <xsd:annotation> + <xsd:documentation>A single qualified concept. The attribute + tagName can be used to specify the name of the element + that will enclose the respective values in the response.</xsd:documentation> + </xsd:annotation> + <xsd:complexType> + <xsd:complexContent> + <xsd:extension base="qualifiedConceptReferenceType"> + <xsd:attribute name="tagName" type="xsd:string" use="optional" default="value"/> + </xsd:extension> + </xsd:complexContent> + </xsd:complexType> + </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> @@ -664,48 +673,47 @@ </xsd:annotation> </xsd:element>  - <xsd:element name="variable" abstract="true" substitutionGroup="expression"> + <xsd:element name="variable" substitutionGroup="expression"> <xsd:annotation> - <xsd:documentation>An abstract element to represent datasource specific values taken - from the datasource environment by the wrapper.</xsd:documentation> + <xsd:documentation>An element to represent specific values + from the service local environment.</xsd:documentation> </xsd:annotation> + <xsd:complexType> + <xsd:attribute name="name" type="variableNameType" use="required"/> + </xsd:complexType> </xsd:element> - <xsd:element name="date" substitutionGroup="variable"> - <xsd:annotation> - <xsd:documentation>An element to represent ISO date like 2005-07-21. Substitutes an - abstract environment variable element.</xsd:documentation> - </xsd:annotation> - <xsd:complexType/> - </xsd:element> - <xsd:element name="timestamp" substitutionGroup="variable"> - <xsd:annotation> - <xsd:documentation>An element to represent an ISO timestamp like 2005-07-20 17:01:38. - Substitutes an abstract environment variable element.</xsd:documentation> - </xsd:annotation> - <xsd:complexType/> - </xsd:element> - <xsd:element name="datasourceName" substitutionGroup="variable"> - <xsd:annotation> - <xsd:documentation>An element to represent the name of the datasource. Substitutes an - abstract environment variable element.</xsd:documentation> - </xsd:annotation> - <xsd:complexType/> - </xsd:element> - <xsd:element name="accessPoint" substitutionGroup="variable"> - <xsd:annotation> - <xsd:documentation>An element to represent the access point of the datasource. - Substitutes an abstract environment variable element.</xsd:documentation> - </xsd:annotation> - <xsd:complexType/> - </xsd:element> - <xsd:element name="lastUpdate" substitutionGroup="variable"> - <xsd:annotation> - <xsd:documentation>An element to represent the timestamp of the last update of the - datasource. Substitutes an abstract variable expression - element.</xsd:documentation> - </xsd:annotation> - <xsd:complexType/> - </xsd:element> + <xsd:simpleType name="predefinedVariableNamesType"> + <xsd:restriction base="xsd:string"> + <xsd:enumeration value="date"> + <xsd:annotation> + <xsd:documentation>Current date in ISO format like 2005-07-21.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="timestamp"> + <xsd:annotation> + <xsd:documentation>Current timestamp in ISO format like 2005-07-20 17:01:38</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="datasourceName"> + <xsd:annotation> + <xsd:documentation>The name of the datasource (service title).</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="accessPoint"> + <xsd:annotation> + <xsd:documentation>Service access point.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + <xsd:enumeration value="lastUpdate"> + <xsd:annotation> + <xsd:documentation>Timestamp of the last update of the datasource.</xsd:documentation> + </xsd:annotation> + </xsd:enumeration> + </xsd:restriction> + </xsd:simpleType> + <xsd:simpleType name="variableNameType"> + <xsd:union memberTypes="predefinedVariableNamesType xsd:string"/> + </xsd:simpleType>    @@ -770,7 +778,7 @@ <xsd:attributeGroup name="pagingParametersGroup"> <xsd:attribute name="count" type="xsd:boolean" use="optional" default="false"/> <xsd:attribute name="start" type="xsd:nonNegativeInteger" use="optional" default="0"/> - <xsd:attribute name="limit" type="xsd:nonNegativeInteger" use="optional" default="1"/> + <xsd:attribute name="limit" type="xsd:nonNegativeInteger" use="optional"/> </xsd:attributeGroup>   @@ -976,6 +984,7 @@ </xsd:sequence> <xsd:attribute name="namespace" type="xsd:anyURI" use="required"/> <xsd:attribute name="location" type="xsd:anyURI" use="required"/> + <xsd:attribute name="alias" type="xsd:string" use="optional"/> </xsd:complexType> </xsd:element> </xsd:sequence> @@ -987,12 +996,7 @@ <xsd:element name="environment" minOccurs="0"> <xsd:complexType> <xsd:sequence> - <xsd:element ref="variable" minOccurs="0" maxOccurs="unbounded"/> - <xsd:element ref="custom" minOccurs="0"> - <xsd:annotation> - <xsd:documentation>Extension slot for other variables.</xsd:documentation> - </xsd:annotation> - </xsd:element> + <xsd:any maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> </xsd:element> @@ -1044,7 +1048,6 @@ <xsd:element ref="custom" minOccurs="0"/> </xsd:sequence> </xsd:complexType> - <xsd:complexType name="templatesCapabilitiesType"> <xsd:sequence> <xsd:element name="template" maxOccurs="unbounded"> @@ -1069,10 +1072,8 @@ <xsd:element name="basicSchemaLanguage"> <xsd:annotation> <xsd:documentation>This includes the following xml schema tags: schema incl - target namespace, element incl min/maxOccurs, attribute incl minOccurs, - sequence, all If defined locally it should also include complexType + - simpleType definitions incl complexContent + - simpleContent</xsd:documentation> + target namespace, element incl min/maxOccurs, attribute incl use, + sequence, all and local definitions of complexType and simpleType.</xsd:documentation> </xsd:annotation> <xsd:complexType/> </xsd:element> @@ -1697,18 +1698,13 @@ </xsd:annotation> <xsd:complexType> <xsd:sequence> - <xsd:element name="value" maxOccurs="unbounded"> + <xsd:any maxOccurs="unbounded"> <xsd:annotation> - <xsd:documentation>A single value for a single concept. The sequence + <xsd:documentation>Single values for each concept. The sequence of the values should correspond to the sequence used in the request.</xsd:documentation> </xsd:annotation> - <xsd:complexType> - <xsd:simpleContent> - <xsd:extension base="xsd:string"/> - </xsd:simpleContent> - </xsd:complexType> - </xsd:element> + </xsd:any> </xsd:sequence> <xsd:attribute name="count" type="xsd:positiveInteger" use="optional"/> </xsd:complexType>

1 0

[tdwg-tapir] Suggested changes
by Renato De Giovanni 17 Jan '07

17 Jan '07

Dear all, I recently finished a new TAPIR provider implementaiton and I've been taking notes about some issues with the protocol schema and the specification. Most are minor things that are now unspecified or that have some contradiction considering schema, specification and wiki notes. Some are really errors that need to be fixed and others are suggestions to improve the way that some things are defined now. I'm listing all issues below suggesting an approach for each one. Most of them I already talked to Markus and we have a similar opinion. Please feel free to give your ideas or suggest different approaches. In case there are no objections, I should probably change the XML Schema and the specification by the end of this week. Best Regards, -- Renato ========================= Issues and proposed changes to TAPIR 1) Now the schema says that indexingElement is unbounded. However, there must be one and only one indexingElement for each output model. This is an error and must be fixed in the schema. 2) Some time ago there was a proposal to allow renaming <value> elements in inventory responses to ease the parsing (http://lists.tdwg.org/pipermail/tdwg-tapir/2005-October/000009.html). Apparently there was an agreement about this, but for some reason the schema was never changed. Suggested approach: change schema and specification accordingly. (inventory requests: concept elements will have an optional attribute "tagName", and inventory responses will need to have xsd:any inside <record>). 3) Currently the "basicSchemaLanguage" capability for response structures includes "...ComplexType, simpleType, complexContent and simpleContent only when related to local definitions". On the other hand, "xsd:extension" and "xsd:restriction" are optional capabilities. Since complexContent and simpleContent have to be used with either "xsd:extension" or "xsd:restriction", this becomes a contradiction. Suggested approach: remove complexContent and simpleContent from basicSchemaLanguage, also trying to keep it as "basic" as possible. 4) header/source@accesspoint is a mandatory attribute that can be either an IP or a name. For TAPIR responses this is fine, when @accesspoint should be the service accesspoint. But for requests it becomes incovenient to force clients to put an accesspoint there (which can potentially contradict with the REMOTE_ADDR environment variable). Suggested approach: make @accesspoint an optional attribute and change the specification saying that: @accesspoint must be present in all responses indicating the service accesspoint. On requests, @accesspoint must be present in all <source> elements except the last <source>. In these cases, when present it must contain the IP address. The IP of the last source must always be taken from REMOTE_ADDR. 5) There's no way to track the original source using KVP when there are intermediate services. Suggested approach: include an optional KVP parameter "source_ip" (same DiGIR approach). 6) Currently, local variables are defined with their own elements, like <dateLastUpdated/>. This makes it complicated for a service to define new variables (need to extend the schema!) and also to identify variables when parsing a request. Suggested approach: use the same strategy adopted by parameters: <variable name="var_name"/> with the difference that @name will be an extensible controlled vocabulary. 7) <mappedConcept> in capablities responses has an optional @alias. Suggestion: add an optional @alias attribute to <schema> as well. 8) There's no indication whether response structures must contain a targetNamespace or not. If there's no targetNamespace and the response includes the TAPIR envelope, then custom search elements will be forced to inherit from the TAPIR namespace. Suggested approach: change the specification to say that response structures (schema) should always indicate a targetNamespace. 9) The specification says that the default value for "start" (search and inventory operations) is "1", but schema says the default is "0". Suggested approach: use "0" (= index of the first record) and change the specification. 10) The specification says that the default value for "limit" (search and inventory operations) is "null" (unlimited), but schema says the default is "1". Suggested approach: when not specified ("null") consider unlimited. Change the schema to remove "default=1". Otherwise it would be necessary to define a specific value to indicate "unlimited". 11) Currently, case sensitivity can be separately specified for "equals" and "like" operators, while nothing is said about the "in" operator. Suggested approach: have a single setting for case sensitivity related to the three operators. 12) There's no default behaviour for "like" comparisons when there's no wildcard in the term. Suggested approach: include * both in the beginning and the end of the term. 13) There's nothing specificed about how to escape * in like terms. Suggestion: use _* to escape (avoiding reserved and unsafe URL characters). 14) Specification is not clear about what content should be included in reponses when one or more partial parameter is specified. Suggested approach: response content should be minimal (non-greedy) when partial is specified. This means "include only the partial nodes and all other nodes (below and above) that are mandatory". When partial is not specified then reponses should be greedy (include all possible content). =================================

1 0

Message deleted
by ***** 06 Jan '07

06 Jan '07

Message deleted

1 0