July 2007 - tdwg-tag - lists.tdwg.org

[tdwg-tapir] Is the current schema valid?
by Roger Hyam 31 Jul '07

31 Jul '07

Hi All, I have just noticed that the schema at: http://rs.tdwg.org/tapir/1.0/schema/tapir.xsd isn't valid according to Oxygen 8.0. E cos-all-limited.1.2: An 'all' model group must appear in a particle with '{'min occurs'}' = '{'max occurs'}' = 1, and that particle must be part of a pair which constitutes the '{'content type'}' of a complex type definition. Am I missing something - I appreciate that there are a stack of emails I need to work back through. All the best, Roger ____________________________________________________________ Roger Hyam <roger(a)tdwg.org> ____________________________________________________________ Biodiversity Information Standards: http://www.tdwg.org/ "Working To Make Biodiversity Data Global" ____________________________________________________________ TDWG Standards Architecture: http://wiki.tdwg.org/twiki/bin/view/TAG LSID RDF Vocabularies: http://wiki.tdwg.org/twiki/bin/view/TAG/ LsidVocs ____________________________________________________________

3 2

[tdwg-guid] Immutability of LSID data
by Ricardo Pereira 25 Jul '07

25 Jul '07

Folks, Let's pick one controversial issue at a time and discuss it. I suggest we pick the "easiest" ones first. Let's pick the immutability of LSID data next. Let us first review which methods are provided by the LSID data services: bytes getData(LSID lsid) bytes getDataByRange(LSID lsid, integer start, integer length) I wasn't the one who came up with the LSID spec, but I suppose that those methods were specifically designed to handle sequence data (DNA and protein data). The getDataByRange method in particular was designed to allow clients to refer to very specific subsets of those sequences. No doubt that this is all very useful for the bioinformatics folks, but as we've seen in previous discussions, it is not as useful for us in the biodiversity (and ecological) informatics communities. The main reason is that some of our data is represented in XML, which cannot be serialized as the very same stream of bytes every time. But it may still be helpful to use the getData call to retrieve such data. The question in discussion in this thread is whether we should bend the LSID rules to accept XML data in getData calls. My proposal, which I think gathers the points presented in the previous discussion thread, is that whatever is served using getData is "semantically immutable". Semantical immutability would then depend on the content type of the data returned. For example: 1) If data is of content type text/plain, application/octet-stream, image/*, etc, then it must always be returned as the exact byte stream sequence (just like the LSID spec states now). 2) If data is in XML, i.e., it is of content type text/xml, text/html (God forbid), then it must always return an equivalent XML DOM tree; 3) If data is application/rdf+xml or application/rdf+n3 (i.e. RDF data), the getData call must always return the same RDF graph; 4) And so on for every other MIME type out there. // The implications of bending the LSID getData calls like that are: a) One may not use getDataByRange call for data that is not byte stream equivalent (item #1 above). Authorities would have to return an error message when getDataByRange is called on a "semantically immutable" object. b) Some may claim that caching of LSIDs and the associated data would be impossible. But since the data is always "semantically immutable", what's wrong with caching it? c) Authorities wouldn't be able to return data in alternate MIME types (RDF in XML or N3 or Turtle) as there is no parameter that specifies that. Not a problem I suppose. I agree with Dave in that we would gain much if we bent the LSID rule about immutability of data. We would have a more general solution that would fit the needs of a broader set of providers, without impacting the authorities that today don't use getData that much, such as the providers of names, concepts, observations, specimens, authors, and collections. So the questions I pose to our group in this thread are: "Should we allow 'semantically immutable' data to be returned in the getData call? How exactly do we do it (i.e., what would be a specification for it)?" I don't really see a problem bending the LSID rules a bit, as outlined above. What do you think? Cheers, Ricardo

9 14

[tdwg-tapir] TapirLink 0.4
by Renato De Giovanni 25 Jul '07

25 Jul '07

Dear all, Version 0.4 of TapirLink has just been released. This version includes some new features such as: - A new conceptual schema handler for CNS files (thanks to Roger Hyam!). If the CNS has multiple conceptual schemas, the handler will fetch only the first one by using the exact CNS location. However, it is possible to specify a particular conceptual schema inside the CNS by appending #concept_source_alias to the CNS location. - Support for ABCD both as a conceptual schema and as a response structure. Now it's possible to locally map ABCD concepts and produce an ABCD output using automapping in the output model, and it's possible to locally map DarwinCore and produce ABCD output from DarwinCore concepts (there's a special output model for this). - Many improvements in response structure parsing. - Preliminary support for TDWG Ontology concepts for specimens (not fully tested, but should hopefully work). This version also includes a number of bugfxes that will require users to save metadata and settings from the admin interface for each resource. This will regenerate the metadata and capabilities templates and make them fully compatible with the TAPIR XML Schema (this process can be automated in the future). You may find a detailed change log about this release here: https://sourceforge.net/project/shownotes.php?release_id=527435&group_id=38… TapirLink can be downloaded from: https://sourceforge.net/project/showfiles.php?group_id=38190&package_id=217… For those who want to update directly from the Subversion repository, you can reference revision 413. Happy data sharing, -- Renato

1 0

[tdwg-guid] International Standard Collection Identifiers (ISCI) Fwd: [Mdrt] metadata roundtable tomorrow, Wednesday, July 25th
by P. Bryan Heidorn 24 Jul '07

24 Jul '07

This might be of interest to this group. The standard linked here is for Collection Identifiers not "item" identifiers that are proposed for the GUID. -- -------------------------------------------------------------------- P. Bryan Heidorn Graduate School of Library and Information Science University of Illinois at Urbana-Champaign pheidorn(a)uiuc.edu (V)217/ 244-7792 (F)217/ 244-3302 http://www.uiuc.edu/goto/heidorn Online Calendar: http://www.uiuc.edu/goto/heidorncalendar Begin forwarded message: > From: <zavalina(a)uiuc.edu> > Date: July 24, 2007 11:50:28 AM CDT > To: mdrt(a)mail.lis.uiuc.edu > Subject: [Mdrt] metadata roundtable tomorrow, Wednesday, July 25th > > Dear metadata roundtable members, > > Tomorrow, July 25th, Richard Urban will be leading MDRT discussion > on draft standard for International Standard Collection Identifiers > (ISCI), which will establish a unique identifier for each archival > collection and fond. You can access the draft at <http:// > www.niso.org/pdfs/ISO_NP_27730ISCIandWD.pdf>. > > The meeting will take place from 12:30 to 2:00 pm at ISRL Commons > on the third floor of GSLIS building. > > The continuation of the DCMI abstract model discussion started last > week (audio available at http://waterfall.lis.uiuc.edu/dl/classes/ > mdrt/metadataRoundtable071807.ram)is tentatively scheduled for the > second half of August, once everyone is back from summer vacations. > > Have a great week and hope that you will come and participate in > ISCI discussion. > > Sincerely, > Oksana Zavalina > Research assistant > IMLS Digital Collections and Content project > _______________________________________________ > Mdrt mailing list > Mdrt(a)mail.lis.uiuc.edu > https://mail.lis.uiuc.edu/mailman/listinfo/mdrt

1 0

[tdwg-tapir] r1250 - tapir/dev/schema
by svn＠rs.tdwg.org 22 Jul '07

22 Jul '07

Author: RenatoDeGiovanni Date: 2007-07-23 00:56:16 +0200 (Mon, 23 Jul 2007) New Revision: 1250 Modified: tapir/dev/schema/tapir.xsd Log: Replaced xsd:any by the official list of TAPIR environment variables and a custom slot, just to enforce validation. Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-07-22 22:53:26 UTC (rev 1249) +++ tapir/dev/schema/tapir.xsd 2007-07-22 22:56:16 UTC (rev 1250) @@ -698,7 +698,7 @@ <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:enumeration value="dataSourceName"> <xsd:annotation> <xsd:documentation>The name of the datasource (dc:title metadata).</xsd:documentation> </xsd:annotation> @@ -740,7 +740,7 @@ </xsd:enumeration> <xsd:enumeration value="metadataLanguage"> <xsd:annotation> - <xsd:documentation>The language in which the content of the following variables are expressed: datasourceName, dataSourceDescription, rights, subject and bibliographicCitation.</xsd:documentation> + <xsd:documentation>The language in which the content of the following variables are expressed: dataSourceName, dataSourceDescription, rights, subject and bibliographicCitation.</xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="dataSourceLanguage"> @@ -1073,7 +1073,8 @@ <xsd:element name="environment" minOccurs="0"> <xsd:complexType> <xsd:sequence> - <xsd:any maxOccurs="unbounded" processContents="skip"/> + <xsd:group ref="tapirEnvironmentVariables"/> + <xsd:element ref="custom" minOccurs="0"/> </xsd:sequence> </xsd:complexType> </xsd:element> @@ -1567,6 +1568,27 @@ </xsd:element> </xsd:sequence> </xsd:complexType> + <xsd:group name="tapirEnvironmentVariables"> + <xsd:all> + <xsd:element name="date" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="timestamp" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="dataSourceName" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="accessPoint" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="lastUpdate" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="dateCreated" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="dataSourceDescription" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="rights" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="subject" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="bibliographicCitation" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="metadataLanguage" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="dataSourceLanguage" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="technicalContactName" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="technicalContactEmail" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="contentContactName" type="supportedVariableType" minOccurs="0"/> + <xsd:element name="contentContactEmail" type="supportedVariableType" minOccurs="0"/> + </xsd:all> + </xsd:group> + <xsd:complexType name="supportedVariableType"/>  <xsd:element name="metadata" type="metadataResultType"> <xsd:annotation>

1 0

[tdwg-tapir] New version of the specification
by Renato De Giovanni 19 Jul '07

19 Jul '07

Dear all, A new version of the TAPIR specification was published yesterday. It contains all changes that were discussed here during the last two months. You can always access the latest version with this link: http://www.tdwg.org/activities/tapir/specification/ In the end of the document you can find a detailed change log. I would like to thank again everyone who sent corrections or suggested improvements. Please contact me if you still find any issues. Best Regards, -- Renato

2 1

[tdwg-tapir] tapir metadata issues
by Wouter Addink 19 Jul '07

19 Jul '07

Hi, I am currently implementing Tapir metadata responses and have some issues. -indexing preferences frequency in the documentation states @Frequency (starting with uppercase), the schema uses @frequency. I assume I have to implement @frequency. -dc:language is mandatory. What to do with data that is not language specific? Example: we are going to use Tapir for sharing lists of scientific names. Should the language be Latin in that case? We think about using specifying English (eng) as default in that case. The recommendation is to use IANA Language subtags. Probably better to recommend the languages from ethnologue.org (3-letter abbreviations). This because the data can be in much more languages then the IANA Languages, for instance common names in extinct languages. This is different from the xml:lang attribute, which is primarily for application development. -the example for an accesspoint is http://example.net/tapir.cgi I think this may be misleading, it would perhaps be better to use http://example.net/tapir.cgi/yourdatasource as example. Wouter

4 20

[tdwg-tapir] r1245 - in tapir: 1.0/schema dev/schema
by svn＠rs.tdwg.org 19 Jul '07

19 Jul '07

Author: RenatoDeGiovanni Date: 2007-07-19 03:11:10 +0200 (Thu, 19 Jul 2007) New Revision: 1245 Modified: tapir/1.0/schema/tapir.xsd tapir/dev/schema/tapir.xsd Log: Included documentation about dc:language. Modified: tapir/1.0/schema/tapir.xsd =================================================================== --- tapir/1.0/schema/tapir.xsd 2007-07-19 00:40:57 UTC (rev 1244) +++ tapir/1.0/schema/tapir.xsd 2007-07-19 01:11:10 UTC (rev 1245) @@ -1606,14 +1606,19 @@ </xsd:element> <xsd:element ref="dc:language" maxOccurs="unbounded"> <xsd:annotation> - <xsd:documentation></xsd:documentation> + <xsd:documentation>Language of content that can be returned by search + and inventory responses. This element must follow RFC 4646 + and use language codes specified by the IANA Language Subtag + Registry. More than one language can be specified, in case + the provider can serve content in multiple languages. When + there is no linguistic content, "zxx" must be used.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="dc:subject" minOccurs="0"> <xsd:annotation> - <xsd:documentation>Subject and Keywords.Typically, a Subject will be expressed as keywords, + <xsd:documentation>Subject and Keywords. Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic - of the resource. Recommended best practice is to select + of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme</xsd:documentation> </xsd:annotation> Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-07-19 00:40:57 UTC (rev 1244) +++ tapir/dev/schema/tapir.xsd 2007-07-19 01:11:10 UTC (rev 1245) @@ -1606,14 +1606,19 @@ </xsd:element> <xsd:element ref="dc:language" maxOccurs="unbounded"> <xsd:annotation> - <xsd:documentation></xsd:documentation> + <xsd:documentation>Language of content that can be returned by search + and inventory responses. This element must follow RFC 4646 + and use language codes specified by the IANA Language Subtag + Registry. More than one language can be specified, in case + the provider can serve content in multiple languages. When + there is no linguistic content, "zxx" must be used.</xsd:documentation> </xsd:annotation> </xsd:element> <xsd:element ref="dc:subject" minOccurs="0"> <xsd:annotation> - <xsd:documentation>Subject and Keywords.Typically, a Subject will be expressed as keywords, + <xsd:documentation>Subject and Keywords. Typically, a Subject will be expressed as keywords, key phrases or classification codes that describe a topic - of the resource. Recommended best practice is to select + of the resource. Recommended best practice is to select a value from a controlled vocabulary or formal classification scheme</xsd:documentation> </xsd:annotation>

1 0

[tdwg-tapir] r1244 - in tapir: 1.0/schema dev/schema
by svn＠rs.tdwg.org 19 Jul '07

19 Jul '07

Author: RenatoDeGiovanni Date: 2007-07-19 02:40:57 +0200 (Thu, 19 Jul 2007) New Revision: 1244 Modified: tapir/1.0/schema/tapir.xsd tapir/dev/schema/tapir.xsd Log: Skip validation of supported environment variables in capabilities responses. Modified: tapir/1.0/schema/tapir.xsd =================================================================== --- tapir/1.0/schema/tapir.xsd 2007-07-19 00:06:24 UTC (rev 1243) +++ tapir/1.0/schema/tapir.xsd 2007-07-19 00:40:57 UTC (rev 1244) @@ -1073,7 +1073,7 @@ <xsd:element name="environment" minOccurs="0"> <xsd:complexType> <xsd:sequence> - <xsd:any maxOccurs="unbounded"/> + <xsd:any maxOccurs="unbounded" processContents="skip"/> </xsd:sequence> </xsd:complexType> </xsd:element> Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-07-19 00:06:24 UTC (rev 1243) +++ tapir/dev/schema/tapir.xsd 2007-07-19 00:40:57 UTC (rev 1244) @@ -1073,7 +1073,7 @@ <xsd:element name="environment" minOccurs="0"> <xsd:complexType> <xsd:sequence> - <xsd:any maxOccurs="unbounded"/> + <xsd:any maxOccurs="unbounded" processContents="skip"/> </xsd:sequence> </xsd:complexType> </xsd:element>

1 0

[tdwg-tapir] r1243 - in tapir: 1.0/schema dev/schema
by svn＠rs.tdwg.org 19 Jul '07

19 Jul '07

Author: RenatoDeGiovanni Date: 2007-07-19 02:06:24 +0200 (Thu, 19 Jul 2007) New Revision: 1243 Modified: tapir/1.0/schema/tapir.xsd tapir/dev/schema/tapir.xsd Log: Made dc:language unbounded and clarified documentation about the dataSourceLanguage environment variable. Modified: tapir/1.0/schema/tapir.xsd =================================================================== --- tapir/1.0/schema/tapir.xsd 2007-07-18 22:26:39 UTC (rev 1242) +++ tapir/1.0/schema/tapir.xsd 2007-07-19 00:06:24 UTC (rev 1243) @@ -745,7 +745,7 @@ </xsd:enumeration> <xsd:enumeration value="dataSourceLanguage"> <xsd:annotation> - <xsd:documentation>The primary language of the data provided by the service (dc:language metadata).</xsd:documentation> + <xsd:documentation>The primary language of the data provided by the service (first occurrence of the dc:language metadata element).</xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="technicalContactName"> @@ -1604,7 +1604,7 @@ of content or a free-text account of the content.</xsd:documentation> </xsd:annotation> </xsd:element> - <xsd:element ref="dc:language"> + <xsd:element ref="dc:language" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation></xsd:documentation> </xsd:annotation> Modified: tapir/dev/schema/tapir.xsd =================================================================== --- tapir/dev/schema/tapir.xsd 2007-07-18 22:26:39 UTC (rev 1242) +++ tapir/dev/schema/tapir.xsd 2007-07-19 00:06:24 UTC (rev 1243) @@ -745,7 +745,7 @@ </xsd:enumeration> <xsd:enumeration value="dataSourceLanguage"> <xsd:annotation> - <xsd:documentation>The primary language of the data provided by the service (dc:language metadata).</xsd:documentation> + <xsd:documentation>The primary language of the data provided by the service (first occurrence of the dc:language metadata element).</xsd:documentation> </xsd:annotation> </xsd:enumeration> <xsd:enumeration value="technicalContactName"> @@ -1604,7 +1604,7 @@ of content or a free-text account of the content.</xsd:documentation> </xsd:annotation> </xsd:element> - <xsd:element ref="dc:language"> + <xsd:element ref="dc:language" maxOccurs="unbounded"> <xsd:annotation> <xsd:documentation></xsd:documentation> </xsd:annotation>

1 0