December 2005 - tdwg-tag - lists.tdwg.org

DOI or Handle System
by Ricardo Scachetti Pereira 21 Dec '05

21 Dec '05

Hello, So far we have been considering both DOI and Handle System (besides LSID and maybe ARK) as potential GUID technologies for biodiversity informatics. However, DOI uses the Handle System as its underlying resolution mechanism, thus sharing many features with Handles. What I wanted to discuss is whether DOI additional features warrant its use by our community, or we should only consider the Handle System as a potential candidate. The DOI handbook states that the features added by DOI are metadata, policy and business rules [1]. According to the handbook, policy is specifically developed to control how the intellectual-property based businesses using DOI operate in the network [2]. As far as I can tell, the list of current policies [3] looks more like a list of mandatory requirements that all other technologies meet, plus other policies that have little use in the biodiversity informatics field. I believe that the same applies to the business rules they try to enforce. That leaves us with the DOI metadata infrastructure built on top of the Handle System as the only usable feature uniquely provided by DOI. For one thing, it seems to be possible to perform queries in DOI using the metadata, which is an unique feature among the GUID technologies being evaluated. However, DOI metadata framework has two drawbacks: it is tied up to a particular technology, XML Schema, and (not so serious) DOI impose a mandatory set of metadata core fields, which are geared towards the publishing industry, but resemble the Dublin Core metadata profile. In any case, a completely separate metadata framework can be implemented on top of the Handle System, either using DOI approach (not recommended - lot of work to reinvent DOI wheel) or using the type and index fields in the handle record (but not so nice because it is based on a proprietary protocol - more on this later). In LSID one can use ANY technology, past, present or future, to implement the metadata framework. And several implementations can be supported simultaneously by the framework. The LSID specs currently *recommends*, but does not mandate the use of RDF for metadata. In any case this metadata facility comes at a price: the DOI fees. From my professional experience in the field, I would say that the DOI funding model is not suitable for biodiversity informatics. I'm not saying that the other technologies have no setup and maintenance costs. It is just that their cost just doesn't appear as a yearly, per identifier fee. The costs of the other systems are incurred by individual agents (or authorities), usually in the form of in-kind contribution of systems and network administrator's time. To me, that seems like a much more suitable model for our field. Given those arguments I would conclude that DOI is not suitable for our purposes and that we should really only consider the Handle System as a candidate GUID technology. Comments are more than welcome. Best regards, Ricardo [1] - DOI Handbook - Section 3.5.1 - Relationship between the DOI System and the Handle System - http://www.doi.org/handbook_2000/resolution.html#3.5.1 [2] - DOI Handbook - Section 6.1 - Policy formulation - http://www.doi.org/handbook_2000/policies.html#6.1 [3] - DOI Handbook - Section 6.3 - Current policies of the IDF - http://www.doi.org/handbook_2000/policies.html#6.3

1 0

Re: New GUID technology comparison page
by Ricardo Scachetti Pereira 21 Dec '05

21 Dec '05

Thanks Rod, I've messed with the username and passwords in the LSID Perl stack several times, but forgot about it completely when writing the comparison. Thanks for pointing it out. I'm going to make a guess and ellaborate it further. The username and password are probably used to authorize clients resolving a LSID or getting data/metadata using SOAP/HTTP. Anyway, I've fixed it on the comparison page. Regards, Ricardo Roderic Page wrote: > Two quick comments. > > 1. LSIDs do support security, albeit not with much sophistication. I've > not played with this feature, but the source code examples clearly > support username and password authentication. > > 2. There have been some attempts to use LDAP to resolve LSIDs > (http://lifecde.com/products/lsid/lsid_resolver_spec.html). All > attempts I've made to contact the author of this work have failed. > > The code for this was in SourceForge at http://lsid.sourceforge.net, > but IBM took over that URL. However, I have a copy of the code, and > I've just discovered it's been archived at > http://cvs.sourceforge.net/viewcvs.py/lsid-orig/lsid/ as well. > > I've virtually no understanding of how LDAP works, nor whether this is > useful, but it seemed to get some attention for a while > (http://gmod.sourceforge.net/gds/gds_desc.shtml). > > Regards > > Rod > > > On 21 Dec 2005, at 03:05, Ricardo Scachetti Pereira wrote: > >> Hi folks, >> >> Over the last few days I re-read the specifications of some >> candidate GUID technologies to be used by GBIF and TDWG. As a result, >> I've upgraded the technology comparison in the GUID wiki. The direct >> URL >> is http://wiki.gbif.org/guidwiki/wikka.php?wakka=TechnologyComparison. >> Please feel free to make comments and corrections. >> >> Cheers, >> >> Ricardo >> >> <ricardo.vcf> > > ------------------------------------------------------------------------ > ---------------------------------------- > 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 > 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 at http://darwin.zoology.gla.ac.uk/~rpage/portal/ > Find out what we know about a species at http://ispecies.org >

1 0

DNS for discovery in LSID
by Ricardo Scachetti Pereira 21 Dec '05

21 Dec '05

Hi folks. It's me again. Also during my reading of the GUID technologies specs, I identified some controversial issues that I would like to introduce to the list for discussion. Here goes the first one. In the DOI handbook, the authors argue that DNS shouldn't be used as a general name resolution system. Their arguments are the following: * DNS would not scale to support a large number of digital objects as required in a GUID framework (did they mean to use one domain name as an identifier for every object?!?!?) * Names included in identifiers might be implicated in trademark disputes. * DNS administration model is not suitable for a general purpose name system, i.e., only network administrators can manage DNS records. * Change in ownership of domain names can prevent authorities from resolving identifiers. * That reduces semantic opacity of identifiers LSID technology uses DNS for resolution discovery. My questions are: Is LSID affected by any of those issues? How can we work around them? If the response includes using the alternate discovery method which is part of the LSID specification (NAPTR), is that operational? If not, what would it take to make it work? Regards, Ricardo PS. If you are a LSID enthusiast and got mad at me for spilling the beans on it, don't worry, I have some good ones about DOI and Handle in my bag ;)

1 0

New GUID technology comparison page
by Ricardo Scachetti Pereira 21 Dec '05

21 Dec '05

Hi folks, Over the last few days I re-read the specifications of some candidate GUID technologies to be used by GBIF and TDWG. As a result, I've upgraded the technology comparison in the GUID wiki. The direct URL is http://wiki.gbif.org/guidwiki/wikka.php?wakka=TechnologyComparison. Please feel free to make comments and corrections. Cheers, Ricardo

1 0

Re: [Tdwg-tag] GML application schema for TDWG
by Javier de la Torre 20 Dec '05

20 Dec '05

Hi Flip, I've been playing a little bit more with the schemas. Here are some ideas: I think I am still not understaind the way you would like to implement the schemas, but here is an idea on how to do it for ABCD and for Darwin Core: The main idea is to create a CollectionRecordType in a document called something like abcd2.06_gml_biding.xsd or dwc2_gml_binding.xsd What this schema does is to create an element called CollectionRecordType that extends the AbstractFeatureType of GML and that includes two elements in a sequence: Unit or Record of type "abcd:Unit" or "dwc:Record" and another element called Geospatial of type "tdwg_geo:GeospatialType". The schema imports GML, ABCD, and your Geospatial schema. We only create the binding between our actual schemas and GML and then we add also a GeospatialExtension to them. Here is an example: --------- <?xml version="1.0" encoding="UTF-8"?> <xsd:schema.....> <xsd:import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/gml.xsd"/> <xsd:import namespace="http://www.tdwg.org/schemas/abcd/2.06" schemaLocation="http://www.bgbm.org/TDWG/CODATA/Schema/ABCD_2.06/ ABCD_2.06.XSD"/> <xsd:import namespace="http://www.tdwg.org/schemas/geo_spatial/1.0" schemaLocation="http://gis.grinfo.net/resources/dcGeospatial_javi.xsd"/> <xsd:complexType name="CollectionRecordType"> <xsd:complexContent> <xsd:extension base="gml:AbstractFeatureType"> <xsd:sequence> <xsd:element name="Unit" type="abcd:Unit"/> <xsd:element name="Geospatial" type="tdwg_geo:GeospatialType"/> </xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="CollectionRecord" type="CollectionRecordType" substitutionGroup="gml:_Feature"/> </xsd:schema> -------------------------- I do not like it specially like this... Is not possible to extend something from two types in XML schema no? this is why I have to repeat CollectionRecord and then Unit... I don't know. In any case now I think I understand that what you want is to separate the extension from the binding, is that correct? We will have to recreate our schemas inside the binding or we can somehow, like I am showing, import directly our schemas? I have the schemas that you sent already to make them validate if you want them. Javier.

1 0

[tdwg-tapir] metadata
by "Döring, Markus" 20 Dec '05

20 Dec '05

Dear all, I think we agreed in Madrid that the metadata definition doesnt influence our work a lost and that others should inspect it again. So I am wondering whom we should ask? Donald, have you taken a look at it from the GBIF registry point of view? Markus

2 1

Re: [tdwg-tapir] Proposal
by "Döring, Markus" 20 Dec '05

20 Dec '05

Great Renato, we really need to get this done very soon, so I support the 5th of January. I agree to most of your changes, but want to discuss this one a little further: * Change multiCOPType (basis of the <in> operator) so that <values> can contain a sequence of "expression" elements instead of only literals. This will allow parameters with multiple values (or multiple parameters) to be used by the TCS API. --- Why do we need this? You can always submit multiple values through the same parameter name. Do we need to have an IN with multiple parameter names? can you give an example? Markus -----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces(a)lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Freitag, 16. Dezember 2005 19:18 An: tdwg-tapir(a)lists.tdwg.org Betreff: [tdwg-tapir] Proposal Dear all, I would like to propose a set of changes to the protocol trying to address the main issues that we've recently discussed here. The changes are described below and if you want to browse the corresponding schema you can find it here: http://www.cria.org.br/~renato/tapir.xsd The main issues are related to TapirLite (how to accomodate it without making generic clients overly complicated), and are also related to Donald's suggestion about inventory templates. All other changes proposed were a mere consequence of browsing the schema and finding parts that I thought could be improved. Please, take a look when you have some time and let me know if you have any comments, suggestions, objections, etc. Personally I'm happy with the changes, so if you all agree, and if we don't find other issues, I'll suggest to "feature freeze" it as soon as possible so that people can (re)start implementation based on it. The feature freeze was originally planned for yesterday (December 15th), but since the current version still has open issues and this proposal should obviously be reviewed and discussed, I'll suggest that we postpone it for at least January 5th. By the way, I'll be on vacation during the next two weeks, so only accessing e-mail sporadically. Best Regards, -- Renato ------- TAPIR / proposed changes ------- * Change filter capabilities so that implementations either accept all filter functionality or none. Specific changes: rename element /response/capabilities/operators to "filter" and include an optional subelement called "encoding". Rename "boolean" to "booleanOperators", and make all logical and comparative operators mandatory. This way parsers can always rely on the existence of a <filter> element and then pass it to a specific handler (same technique suggested by Steve in other parts of the protocol). Such handler can just detect if there's an element "encoding" or not, which means "I understand the basic filtering mechanism" or "I don't know how to parse any filters". TapirLite implementations will answer in the capabilities: ... <filters/> ... Full TAPIR implementations will answer: ... <filters> <encoding> <expression> <concept/> <literal/> <parameter/> <variable/> <arithmetic/> </expression> <booleanOperators> <logical> <not/> <and/> <or/> </logical> <comparative> <equals/> <greaterThan/> <greaterThanOrEquals/> <lessThan/> <lessThanOrEquals/> <in/> <isNull/> <like/> </comparative> </booleanOperators> </encoding> </filters> ... * Change multiCOPType (basis of the <in> operator) so that <values> can contain a sequence of "expression" elements instead of only literals. This will allow parameters with multiple values (or multiple parameters) to be used by the TCS API. * Re-include an operation completely dedicated to the usage of queryTemples (I called it "view" but I'm happy with any other better names if people feel uncomfortable with it). This operation would only be accessible through GET whithout using XML requests. And it would not accept the "filter" and "partial" parameters. This seems to be the cleanest way to accomodate TapirLite since the _only_ change in the schema is the new optional element /response/capabilities/operations/view indicating the query templates supported. Obs: I tried other ways, but the results were not so nice and the changes were more drastic. * Remove the possibility to use queryTemplateURI in XML search requests. If someone wants to use a queryTemplateURI in a search request, it's so much simpler to use regular GET parameters in the URL that it's looks reasonable to simplify the protocol in these situations. * Move /response/capabilities/operations/search/queryTemplates to /response/capabilities/operations/view/queryTemplates. * On the other hand, include a new <predefinedOutputModels> element in /response/capabilities/operations/search (issue raised in a recent discussion with Rob in this mailing list). DiGIR2 will make use of it. * Reduce "queryTemplateGroup" to contain only <label> and <documentation>. Move the other elements to a new "searchTemplateGroup" which also references the "queryTemplateGroup". Create a new "inventoryTemplateGroup" in the same way, and make the inventory request element reference it (as it happens in the search request definition). Remove global element <queryTemplate>, including <searchTemplate> and <inventoryTemplate> to make the schema validate external template definitions. This way query templates used in view operations can point to predefined search or inventory operations. Other changes: * Make /response/capabilities/concepts/schema a mandatory element so that any implementation shows which concepts are present. * Remove controlled vocabulary of element /response/metadata/relatedEntities/entity/contact/role and make it unbounded: controlled vocabularies do help with standardization, but they also reduce flexibility. In different contexts people could easily envision different uses for that attribute, so I would rather enforce vocabulary control in other levels (such as software configuration or network configuration). * Remove "datum" attribute from geoLocationType: the corresponding element has been included so that "related entities" (part of metadata responses) could indicate their location. People can easily always put lat/long in WGS84 in this case, it's just a matter of adding a note about that in the documentation. * Rename primaryConceptNameServer and secondaryConceptNameServer to primary and secondary, respectively (the enclosing element already provides the context). Make <primary> optional. * Rename global element <environment> to <variable>, and move /response/capabilities/search/variables to /response/capabilities/variables since they can be used in both mappings and filters. Remove redefinition of all variables in the capabilities response by referencing the existing variable element defintion. Remove empty /response/capabilities/search/variables/environment/metadata element. ------- _______________________________________________ tdwg-tapir mailing list tdwg-tapir(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org

1 0

[tdwg-tapir] Schema modification: r388 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 16 Dec '05

16 Dec '05

Author: markus Date: 2005-12-16 17:31:54 +0100 (Fri, 16 Dec 2005) New Revision: 388 Added: trunk/protocol/report_korean_v0.1.pdf Log: Added: trunk/protocol/report_korean_v0.1.pdf =================================================================== (Binary files differ) Property changes on: trunk/protocol/report_korean_v0.1.pdf ___________________________________________________________________ Name: svn:mime-type + application/octet-stream

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Kevin Richards 13 Dec '05

13 Dec '05

Its taken a little while but in answer to Donalds question, for us here at Landcare Research: 1. Is your data organised using taxon names or to taxon concepts? Our taxonomic data is represented by taxon concepts. First by a concensus concept of a preferred name+synonyms+ taxonomic reference (this includes misapplied names, i.e incongruent taxon concepts), and we also track alternate taxon concepts through name/synonmy linkages recorded from the literature. 2. Do you assign any reusable identifiers to taxon names or concepts (i.e. identifiers used in more than one database)? We use guids to link to name strings. A bit of history here - first we were using a U(nique)Pk counter, then we changed to using a UUID (128 bit hex computer generated number), and now we are starting to use LSIDs. We have a taxonomic names web service that provides names lists to external users of our databases, and these are identified by our LSID. (note: we do not currently have a working LSID resolver/authority set up for our LSIDs, but are in the process of doing so). However, these guids are applied only to the name strings that comprise the taxon concept and are not applied to the ensemble of names representing a concept. 3. If so, what is the process in assigning new identifiers for additional taxa and for accommodating taxonomic change? We assign UUIDs to any new names, and our LSID is just our Landcare namespace + this UUID. All names may be cross-linked linked to existing names, eg IsBasionymOf ID, IsReplacedNameOf ID, IsBlockedBy ID, IsParentOf ID, IsSanctionedBy ID etc. In our 'concensus' view all of these names are stored within the same database table with recursive concensus parent linkages. We keep all history of editorial changes to names and their linkages. However, it is recognised that we need to maintain additional GUIDs that identify the ensemble of names representing our 'concensus' taxon concept and that we need to maintain and be able to resolve the time-dependent changes to the concepts. Here we have the difficulty of persuading our end-users (e.g. the curators of collection databases), that they should be using such resolvable concept GUIDs rather than name string guids. We envisage a compromise where some linked datasets maintain a name string guid (the concensus preferred name) and a resolvable taxon concept guid where appropriate. 4. Where are these identifiers used (other organizations, databases, data exchange, recording forms, etc.)? The name string GUIDs are used within many interoperable linked databases maintained by our organization (collections, surveys, phylogeny, attributes, descriptions, images, keys, bibliographies). We also provide an externally accessible taxonomic names web service that used by a number of regional agencies to maintain their own authoritative list of names integrated into their own information systems. 5. Do you use identifiers from any external classification within your database? Yes. Landcare Research is a member of the IndexFungorum partnership. The fungal names in our system are derived from, and kept in synchrony with the IndexFungorum global nomenclator. This is achieved by maintaining inks between our GUIDs and the LSIDs assigned to IndexFungorum entries. 6. Would there be any social or technical roadblocks to replacing these identifiers with a single identifier that was guaranteed to be unique? Yes. We are the creators and maintainers of both nomenclatural and taxonomic data. We would be unhappy about any resolution mechanism that didn't acknowldge our IP in that process. For example, if the LSID contained another organisation's namespace when we were the originators/editors of that entity. Kevin ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ WARNING: This email and any attachments may be confidential and/or privileged. They are intended for the addressee only and are not to be read, used, copied or disseminated by anyone receiving them in error. If you are not the intended recipient, please notify the sender by return email and delete this message and any attachments. The views expressed in this email are those of the sender and do not necessarily reflect the official views of Landcare Research. Landcare Research http://www.landcareresearch.co.nz ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: Topic 3: GUIDs for Taxon Names and Taxon Concepts
by Patricia Mergen 12 Dec '05

12 Dec '05

Dear colleagues I agree with Arthur and Rod on this issue. What we need is a technically GUID which meet our needs. The IP, terme of uses, access rights, copy rights, proper citations has to be dealt with elsewhere, probably locally or nationally with the help of legal specialists. All this information finds indeed best its place in the metadata or even simply as a link in form an accessible webpage at institutional level explaining to the end-users how they are supposed to behave when using the information. I agree that this information should not be included in the GUID and the Genbank Accession number is indeed a good example, where the scientific community has accepted this "GUID" although the string does not contain any "IP" information ... Best regards Patricia Arthur Chapman <tdwg(a)ACHAPMAN.ORG> wrote: I agree with Rod here If we try and build IP rights into a GUID we will get absolutely no where. GUIDs are meant to be machine to machine and aren't meant to be human readable or human intelligent. There are better ways to handle IP /Access constraints/ Conditions of Use, etc. through Metadata (at both the Dataset level and record level if necessary), but these shouldn't be handles through GUIDs. The use of Creative Commons is not inconsistent with Dublin Core, it is not necessarily one or the other - Creative Commons can fit neatly inside Dublin Core. About 10 years ago I wrote a paper on "Intellectual Property Rights in a Digital World" that covered some of these issues. Unfortunately, it was electronic and the Government Department that owned the web site later decided it was not important and deleted it in a revamp of the Web site! If anyone still has a copy, could they please send it to me, as I no longer have a copy myself. If I can get a copy, I will make it available as I believe it is still relevant. Arthur Chapman >>>From Roderic Page on 12 Dec 2005: > A quick comment: > > > > > 6. Would there be any social or technical roadblocks to replacing > > these identifiers with a single identifier that was guaranteed to be > > unique? > > > > Yes. We are the creators and maintainers of both nomenclatural and > > taxonomic data. We would be unhappy about any resolution mechanism > > that didn't acknowldge our IP in that process. For example, if the > > LSID contained another organisation's namespace when we were the > > originators/editors of that entity. > > Leaving aside the awful term "Intellectual Property" -- which should be > > > avoided like the plague (see > http://www.gnu.org/philosophy/not-ipr.xhtml ) -- this strikes me as an > issue handled by metadata, not the GUID itself. For example, there are > vocabularies such as Dublin Core (http://www.dublincore.org/), or even > better, Creative Commons (http://creativecommons.org/) which can handle > > > these issues. I'd strongly favour the later, as Creative Commons > licenses are designed to be computer-readable, and hence can be handled > > > automatically. If a license has to be read by a human, we're shooting > ourselves in the foot. > > I understand that people want credit for their hard work, but this > shouldn't get in the way of a workable system. Imagine if everybody > submitting a sequence to GenBank insisted on their organisation's > namespace being in the GenBank accession number! It would be a utter > mess. In the same way, with DOIs even the mighty Elsevier don't mind > that the DOI has nothing that (explicitly) identifies them as the > source. > > Please let us not let "Intellectual Property" get in the way of a > sensible solution. To my mind "IP" is one of the biggest obstacles in > the way of biodiversity informatics achieving its potential. > > 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 > 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 at http://darwin.zoology.gla.ac.uk/~rpage/portal/ > Find out what we know about a species at http://ispecies.org > --------------------------------- Yahoo! Shopping Find Great Deals on Holiday Gifts at Yahoo! Shopping

1 0