November 2007 - tdwg-tag - lists.tdwg.org

[tdwg-tapir] r1341 - tapir/dev/schema
by svn＠rs.tdwg.org 13 Nov '07

13 Nov '07

Author: RenatoDeGiovanni Date: 2007-11-13 17:01:09 +0100 (Tue, 13 Nov 2007) New Revision: 1341 Modified: tapir/dev/schema/tapir.xsd Log: Keep strict schema validation for inline response structures, adding requirement that elements must be in the XML Schema namespace. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-11-13 15:54:20 UTC (rev 1340) +++ tapir/dev/schema/tapir.xsd 2007-11-13 16:01:09 UTC (rev 1341) @@ -242,7 +242,7 @@ <xsd:complexType> <xsd:choice> <xsd:element name="schema" type="externalResourceType"/> - <xsd:any namespace="##other"> + <xsd:any processContents="strict" namespace="http://www.w3.org/2001/XMLSchema"> <xsd:annotation> <xsd:documentation>A structure represented through a subset of the XML Schema language defining how elements should be

1 0

[tdwg-tapir] r1340 - tapir/dev/schema
by svn＠rs.tdwg.org 13 Nov '07

13 Nov '07

Author: RenatoDeGiovanni Date: 2007-11-13 16:54:20 +0100 (Tue, 13 Nov 2007) New Revision: 1340 Modified: tapir/dev/schema/tapir.xsd Log: Avoid strict schema validation inside <custom> element but require that subelements must be in a different namespace. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-11-09 12:26:39 UTC (rev 1339) +++ tapir/dev/schema/tapir.xsd 2007-11-13 15:54:20 UTC (rev 1340) @@ -200,7 +200,7 @@ </xsd:annotation> <xsd:complexType> <xsd:sequence> - <xsd:any minOccurs="0" maxOccurs="unbounded"> + <xsd:any processContents="lax" namespace="##other" minOccurs="0" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation>For any custom extension. E.g what security related capabilities does the provider have? Encryption, access restriction,

1 0

[tdwg-tapir] Response content type specification
by Dave Vieglais 09 Nov '07

09 Nov '07

Hi Everyone, I've come across a minor issue with some existing TAPIR installations that should be easily fixed and will likely save some frustrations down the road. The TAPIR spec (http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRSpecification_2007-07…) indicates a response Content-type of "text/xml". RFC 3023 (http://www.ietf.org/rfc/rfc3023.txt) indicates that in this case, when no "charset" parameter is specified in the HTTP response header, the implied character encoding of the response document is "us-ascii" (see s8.5). so for example: Good: response header = Content-type: text/xml; charset="utf-8" response document signature = <?xml version="1.0" encoding="utf-8"?> result = document is assumed to be UTF-8 Not so good: response header = Content-type: text/xml response document signature = <?xml version="1.0" encoding="utf-8"?> result = document is assumed to be us-ascii All TAPIR installations that I've examined so far do not set a charset value, and hence the character encoding of "us-ascii" is assumed by the consumer application, which is likely to cause some issues for consumer applications. This was also a significant issue for DiGIR provider installations. The solution is likely to be quite simple, and there seems to be two basic options: 1. Configure the webserver / application to insert a charset value of "UTF-8" to avoid the consumer falling back to the default of us-ascii. or 2. Return a Content-type of "Application/xml" or one of its subtypes. In this case RFC 3023 indicates the default character encoding should be assumed to be UTF-8. Note that simply specifying the content type does not automatically make the response properly encoded - it is still up to the web application (TAPIR in this case) to ensure that the output stream is actually UTF-8 encoded. regards, Dave V.

5 5

[tdwg-guid] Need for citation information in GUID metadata
by Greg Riccardi 09 Nov '07

09 Nov '07

9 11

[tdwg-tapir] TAPIR variable misspelled in rss2 output model
by Ricardo Scachetti Pereira 08 Nov '07

08 Nov '07

Hi there folks, I've found what I think is a very small problem with the rss2 output model XML file at: http://rs.tdwg.org/tapir/cs/dwc/1.4/model/rss2.xml In that file, the node /rss/channel/lastBuildDate is mapped to a TAPIR variable named "lastUpdated", but the TAPIR XML schema (and documentation) describe a variable called "lastUpdate" (without the trailing "d"). I could have fixed it by now, but since that's my first commit to the TAPIR SVN repository, I thought I should ask first. Does anyone see a problem if I fix that little bug? Thanks, Ricardo PS. Is anyone using the rss2 TAPIR output model somewhere? If so, is there an example URL for a TAPIR KVP request that outputs valid RSS2 using that output model?

2 1

[tdwg-tapir] TAPIR and the standardization of SRU
by Ryan Scherle 08 Nov '07

08 Nov '07

Hello TAPIRians, I've recently moved from the library world into the biology world, and I'm noticing that TAPIR has a lot in common with the SRU standard that is gaining popularity in the library world. I would like to encourage collaboration between the two communities, and see whether it is possible to forge a single standard out of the two. One major difference is that TAPIR is database-oriented, while SRU is much more document-oriented, but this should be possible to overcome. SRU has been recently been turned over to the OASIS standards body as source material for developing a general-purpose web services search standard. As a part of this standardization process, the initial draft document has been opened for public comments (see below). If you have comments, you can post them at the URL indicated. If you work for an institution that is a member of OASIS, I believe you can still join the committee and vote on issues related to the standardization. --- Ryan Scherle --- Digital Data Repository Architect --- NESCent Begin forwarded message: > ---------- Forwarded message ---------- > Date: Wed, 7 Nov 2007 14:57:11 -0500 > From: Mary McRae <mary.mcrae(a)oasis-open.org> > To: members(a)lists.oasis-open.org, tc-announce(a)lists.oasis-open.org > Cc: search-ws(a)lists.oasis-open.org > Subject: [search-ws] Public Review of Search Web Services v1.0 > Discussion > Document > > To OASIS members, Public Announce Lists: > > The OASIS Search Web Services TC has recently approved for public > review the > following Discussion Document: > > Search Web Services v1.0 Discussion Document > > This document: "Search Web Services Version 1.0 - Discussion > Document - 2 > November 2007", was prepared by the OASIS Search Web Services TC as a > strawman proposal, for public review, intended to generate > discussion and > interest. It has no official status; it is not a Committee Draft. The > specification is based on the SRU (Search Retrieve via URL) > specification > which can be found at http://www.loc.gov/standards/sru/. It is > expected that > this standard, when published, will deviate from SRU. How much it will > deviate cannot be predicted at this time. The fact that the SRU > spec is used > as a starting point for development should not be cause for concern > that > this might be an effort to rubberstamp or fasttrack SRU. The > committee hopes > to preserve the useful features of SRU, eliminate those that are not > considered useful, and add features that are not in SRU but are > considered > useful. The committee has decided to request OASIS to release this > as a > discussion document. Detailed review of this document is premature > at this > point and is not requested; feedback on the functionality and > approach is > solicited. Feedback is requested by December 7. > > The public review starts today, 7 November 2007, and ends 7 > December 2007. > This is an open invitation to comment. We strongly encourage > feedback from > potential users, developers and others, whether OASIS members or > not, for > the sake of improving the interoperability and quality of OASIS > work. Please > feel free to distribute this announcement within your organization > and to > other appropriate mail lists. > > More non-normative information about the specification and the > technical > committee may be found at the public home page of the TC at > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=search-ws. > Comments may be submitted to the TC by any person through the use > of the > OASIS TC Comment Facility which can be located via the button > marked "Send A > Comment" at the top of that page, or directly at > http://www.oasis-open.org/committees/comments/index.php? > wg_abbrev=search-ws. > > Submitted comments (for this work as well as other works of that > TC) are > publicly archived and can be viewed at > http://lists.oasis-open.org/archives/search-ws-comment/. All comments > submitted to OASIS are subject to the OASIS Feedback License, which > ensures > that the feedback you provide carries the same obligations at least > as the > obligations of the TC members. > > The specification document and related files are available here: > > Editable Source: > http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.doc > > PDF: > http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.pdf > > HTML: > http://docs.oasis-open.org/search-ws/v1.0/DiscussionDocument.html > > > OASIS and the Search Web Services TC welcome your comments. > > > --------------------------------------------------- > Mary P McRae > Manager of TC Administration, OASIS > email: mary.mcrae(a)oasis-open.org > web: www.oasis-open.org

4 4

[tdwg-tapir] r1336 - tapir/dev/schema
by svn＠rs.tdwg.org 07 Nov '07

07 Nov '07

Author: RenatoDeGiovanni Date: 2007-11-07 13:11:07 +0100 (Wed, 07 Nov 2007) New Revision: 1336 Added: tapir/dev/schema/xml.xsd Modified: tapir/dev/schema/dc.xsd tapir/dev/schema/dcterms.xsd tapir/dev/schema/tapir.xsd tapir/dev/schema/vcard.xsd Log: Reference a local copy of xml.xsd for faster XML Schema validation. Modified: tapir/dev/schema/dc.xsd =================================================================== --- tapir/dev/schema/dc.xsd 2007-10-19 23:07:54 UTC (rev 1335) +++ tapir/dev/schema/dc.xsd 2007-11-07 12:11:07 UTC (rev 1336) @@ -39,7 +39,7 @@ <xs:import namespace="http://www.w3.org/XML/1998/namespace" - schemaLocation="http://www.w3.org/2001/03/xml.xsd"> + schemaLocation="xml.xsd"> </xs:import> <xs:complexType name="SimpleLiteral"> Modified: tapir/dev/schema/dcterms.xsd =================================================================== --- tapir/dev/schema/dcterms.xsd 2007-10-19 23:07:54 UTC (rev 1335) +++ tapir/dev/schema/dcterms.xsd 2007-11-07 12:11:07 UTC (rev 1336) @@ -57,7 +57,7 @@ <xs:import namespace="http://www.w3.org/XML/1998/namespace" - schemaLocation="http://www.w3.org/2001/03/xml.xsd"> + schemaLocation="xml.xsd"> </xs:import> <xs:import namespace="http://purl.org/dc/elements/1.1/" Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-10-19 23:07:54 UTC (rev 1335) +++ tapir/dev/schema/tapir.xsd 2007-11-07 12:11:07 UTC (rev 1336) @@ -23,7 +23,7 @@   <xsd:import namespace="http://www.w3.org/XML/1998/namespace" - schemaLocation="http://www.w3.org/2001/xml.xsd"/> + schemaLocation="xml.xsd"/> <xsd:import namespace="http://purl.org/dc/elements/1.1/" schemaLocation="dc.xsd"/> <xsd:import namespace="http://purl.org/dc/terms/" Modified: tapir/dev/schema/vcard.xsd =================================================================== --- tapir/dev/schema/vcard.xsd 2007-10-19 23:07:54 UTC (rev 1335) +++ tapir/dev/schema/vcard.xsd 2007-11-07 12:11:07 UTC (rev 1336) @@ -26,7 +26,7 @@ </annotation> - <import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.w3.org/2001/03/xml.xsd"/> + <import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="xml.xsd"/> <element name="VCARD"> <complexType> <sequence> Added: tapir/dev/schema/xml.xsd =================================================================== --- tapir/dev/schema/xml.xsd 2007-10-19 23:07:54 UTC (rev 1335) +++ tapir/dev/schema/xml.xsd 2007-11-07 12:11:07 UTC (rev 1336) @@ -0,0 +1,145 @@ +<?xml version='1.0'?> +<xs:schema targetNamespace="http://www.w3.org/XML/1998/namespace" xmlns:xs="http://www.w3.org/2001/XMLSchema" xml:lang="en"> + + <xs:annotation> + <xs:documentation> + See http://www.w3.org/XML/1998/namespace.html and + http://www.w3.org/TR/REC-xml for information about this namespace. + + This schema document describes the XML namespace, in a form + suitable for import by other schema documents. + + Note that local names in this namespace are intended to be defined + only by the World Wide Web Consortium or its subgroups. The + following names are currently defined in this namespace and should + not be used with conflicting semantics by any Working Group, + specification, or document instance: + + base (as an attribute name): denotes an attribute whose value + provides a URI to be used as the base for interpreting any + relative URIs in the scope of the element on which it + appears; its value is inherited. This name is reserved + by virtue of its definition in the XML Base specification. + + id (as an attribute name): denotes an attribute whose value + should be interpreted as if declared to be of type ID. + This name is reserved by virtue of its definition in the + xml:id specification. + + lang (as an attribute name): denotes an attribute whose value + is a language code for the natural language of the content of + any element; its value is inherited. This name is reserved + by virtue of its definition in the XML specification. + + space (as an attribute name): denotes an attribute whose + value is a keyword indicating what whitespace processing + discipline is intended for the content of the element; its + value is inherited. This name is reserved by virtue of its + definition in the XML specification. + + Father (in any context at all): denotes Jon Bosak, the chair of + the original XML Working Group. This name is reserved by + the following decision of the W3C XML Plenary and + XML Coordination groups: + + In appreciation for his vision, leadership and dedication + the W3C XML Plenary on this 10th day of February, 2000 + reserves for Jon Bosak in perpetuity the XML name + xml:Father + </xs:documentation> + </xs:annotation> + + <xs:annotation> + <xs:documentation>This schema defines attributes and an attribute group + suitable for use by + schemas wishing to allow xml:base, xml:lang, xml:space or xml:id + attributes on elements they define. + + To enable this, such a schema must import this schema + for the XML namespace, e.g. as follows: + <schema . . .> + . . . + <import namespace="http://www.w3.org/XML/1998/namespace" + schemaLocation="http://www.w3.org/2001/xml.xsd"/> + + Subsequently, qualified reference to any of the attributes + or the group defined below will have the desired effect, e.g. + + <type . . .> + . . . + <attributeGroup ref="xml:specialAttrs"/> + + will define a type which will schema-validate an instance + element with any of those attributes</xs:documentation> + </xs:annotation> + + <xs:annotation> + <xs:documentation>In keeping with the XML Schema WG's standard versioning + policy, this schema document will persist at + http://www.w3.org/2007/08/xml.xsd. + At the date of issue it can also be found at + http://www.w3.org/2001/xml.xsd. + The schema document at that URI may however change in the future, + in order to remain compatible with the latest version of XML Schema + itself, or with the XML namespace itself. In other words, if the XML + Schema or XML namespaces change, the version of this document at + http://www.w3.org/2001/xml.xsd will change + accordingly; the version at + http://www.w3.org/2007/08/xml.xsd will not change. + </xs:documentation> + </xs:annotation> + + <xs:attribute name="lang"> + <xs:annotation> + <xs:documentation>Attempting to install the relevant ISO 2- and 3-letter + codes as the enumerated possible values is probably never + going to be a realistic possibility. See + RFC 3066 at http://www.ietf.org/rfc/rfc3066.txt and the IANA registry + at http://www.iana.org/assignments/lang-tag-apps.htm for + further information. + + The union allows for the 'un-declaration' of xml:lang with + the empty string.</xs:documentation> + </xs:annotation> + <xs:simpleType> + <xs:union memberTypes="xs:language"> + <xs:simpleType> + <xs:restriction base="xs:string"> + <xs:enumeration value=""/> + </xs:restriction> + </xs:simpleType> + </xs:union> + </xs:simpleType> + </xs:attribute> + + <xs:attribute name="space"> + <xs:simpleType> + <xs:restriction base="xs:NCName"> + <xs:enumeration value="default"/> + <xs:enumeration value="preserve"/> + </xs:restriction> + </xs:simpleType> + </xs:attribute> + + <xs:attribute name="base" type="xs:anyURI"> + <xs:annotation> + <xs:documentation>See http://www.w3.org/TR/xmlbase/ for + information about this attribute.</xs:documentation> + </xs:annotation> + </xs:attribute> + + <xs:attribute name="id" type="xs:ID"> + <xs:annotation> + <xs:documentation>See http://www.w3.org/TR/xml-id/ for + information about this attribute.</xs:documentation> + </xs:annotation> + </xs:attribute> + + <xs:attributeGroup name="specialAttrs"> + <xs:attribute ref="xml:base"/> + <xs:attribute ref="xml:lang"/> + <xs:attribute ref="xml:space"/> + <xs:attribute ref="xml:id"/> + </xs:attributeGroup> + +</xs:schema>

1 0

abstract objects and digital representations: metadata
by Bob Morris 06 Nov '07

06 Nov '07

In connection with a discussion on the tdwg-tag mailing list, I am roughly agreeing with a proposal Rich Pyle makes to the effect of having separate LSIDs for digital representations (e.g. media files) of non-digital objects (e.g. a scene in the world). Because it is easy to see the distinctions for media files, I've carried that discussion to the Image Wiki at the page http://wiki.tdwg.org/twiki/bin/view/Image/ImageOrImageFile I hope you will join the discussion there. You can also subscribe to mail or RSS notification of changes to that Wiki at http://wiki.tdwg.org/twiki/bin/view/Image/WebNotify Bob -- Robert A. Morris Professor of Computer Science UMASS-Boston http://www.cs.umb.edu/~ram phone (+1)617 287 6466

1 0

[tdwg-guid] TDWG specimen RDF and browser project completion
by Kevin Richards 05 Nov '07

05 Nov '07

A new tool has been developed for searching, harvesting and browsing RDF and XML data within the TDWG domain. Biodiversity Information Standards (TDWG: http://www.tdwg.org) recognised the urgent need to apply semantic web technologies to sharing biodiversity data. The endorsement of LSID (Life Science Identifiers) for use within the TDWG domain and associated development of RDF metadata has introduced semantic web protocols. This project was accomplished with funding from the TDWG Infrastructure Project (www.tdwg.org/activities/tip), funded by the Gordon and Betty Moore Foundation (http://www.moore.org). The tool was developed in parallel with an LSID resolver for specimen-related data. The Herb IMI specimen database was used for the specimen records, which is closely related to the index of Fungi names, IndexFungorum (http://www.indexfungorum.org). Herb IMI contains nearly 400000 specimen records including location data, and is currently hosted by CABI in the UK. The tool's data sources are configurable and the protocols available include TDWG's TAPIR, OAI-PMH and LSID resolution. Multiple data sources can be configured using various protocols, then queried, harvested and stored in a local RDF-triple store cache. Semantic web inferences can then be derived from the cached RDF. The VB.NET code and documentation is located at the source forge project site, http://sourceforge.net/projects/tdwgrdfbrowser/. The code re-uses the TapirDotNET and LSIDDotNET Source Forge projects. An installation file allows for easy installation. The Herb IMI LSID resolver is set up at http://lsid.herbimi.info/authority/ - for example urn:lsid:herbimi.info:specimens:100069. The TAPIR provider (including a subset of the OAI-PMH protocol) is set up at http://lsid.herbimi.info/tapirdotnet/tapir.aspx. Any feedback is very welcome. Kevin Richards Landcare Research New Zealand

1 0