February 2006 - tdwg-tag - lists.tdwg.org

Thoughts
by Roderic Page 09 Feb '06

09 Feb '06

For those at the workshop, it was great to meet you and to discuss GUIDs. I've posted a personal view on proceedings on one of my blogs: http://iphylo.blogspot.com/2006/02/globally-unique-identifiers.html . Comments are welcome. 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

1 0

[tdwg-tapir] Schema modification: r425 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 07 Feb '06

07 Feb '06

Author: markus Date: 2006-02-07 12:19:56 +0100 (Tue, 07 Feb 2006) New Revision: 425 Added: trunk/protocol/alias.txt Removed: trunk/protocol/concept_name_server.txt Log: Copied: trunk/protocol/alias.txt (from rev 424, trunk/protocol/concept_name_server.txt) Deleted: trunk/protocol/concept_name_server.txt =================================================================== --- trunk/protocol/concept_name_server.txt 2006-02-07 11:18:29 UTC (rev 424) +++ trunk/protocol/concept_name_server.txt 2006-02-07 11:19:56 UTC (rev 425) @@ -1,48 +0,0 @@ -# -# GLOBAL UNIQUE ALIASES FOR CONCEPTS -# -# It is recommended to form aliases by using the following syntax: -# CONCEPT_ABBREVIATION@NAMESPACE_ABBREVIATION -# - - - -[concept_source] - -label = ABCD v1.20 -namespace = http://www.tdwg.org/schema/abcd/1.20 -alias = abcd120 -location = http://www.bgbm.org/TDWG/CODATA/Schema/ABCD-1.20.xsd - -[aliases] - -SourceInstCode /DataSets/DataSet/OriginalSource/SourceInstitutionCode -SourceName /DataSets/DataSet/OriginalSource/SourceName -DateSupplied /DataSets/DataSet/OriginalSource/SourceLastUpdatedDate -DateUpdated /DataSets/DataSet/DatasetDerivations/DatasetDerivation/DateSupplied -SupplierName /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Supplier/Person/PersonName -TermsOfUse /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Rights/TermsOfUse -LegalOwnerOrganisation /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Rights/LegalOwner/Organisation/OrganisationName -LegalOwnerPerson /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Rights/LegalOwner/Person/PersonName -Disclaimer /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Statements/Disclaimer -Logo /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Statements/LogoURL -DatasetDescription /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Description -UnitID /DataSets/DataSet/Units/Unit/UnitID -RecordBasis /DataSets/DataSet/Units/Unit/RecordBasis -HigherTaxon /DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/HigherTaxa/HigherTaxon -ScientificName /DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/NameAuthorYearString -AuthorString /DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/AuthorString -BotGenus /DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/ScientificNameAtomized/Botanical/Genus -Identifier /DataSets/DataSet/Units/Unit/Identifications/Identification/Identifier/IdentifierPersonName/PersonName -IdentDate /DataSets/DataSet/Units/Unit/Identifications/Identification/IdentificationDate/ISODateTimeBegin -TypeStatus /DataSets/DataSet/Units/Unit/UnitStateDomain/SpecimenUnit/NomenclaturalTypeDesignations/NomenclaturalTypeDesignation/TypeStatus -ImageURI /DataSets/DataSet/Units/Unit/UnitDigitalImages/UnitDigitalImage/ImageURI -GatheringDate /DataSets/DataSet/Units/Unit/Gathering/GatheringDateTime/ISODateTimeBegin -Collector /DataSets/DataSet/Units/Unit/Gathering/GatheringAgents/GatheringAgent/Person/PersonName -Project /DataSets/DataSet/Units/Unit/Gathering/Project/ProjectTitle -Locality /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/LocalityText -Country /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/Country/CountryName -Longitude /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLong/LongitudeDecimal -Latitude /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLong/LatitudeDecimal -Altitude /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/Altitude/MeasurementAtomized/MeasurementLowerValue -Description /DataSets/DataSet/Units/Unit/UnitDescription

1 0

[tdwg-tapir] Schema modification: r424 - trunk/protocol
by tdwg-tapir＠lists.tdwg.org 07 Feb '06

07 Feb '06

Author: markus Date: 2006-02-07 12:18:29 +0100 (Tue, 07 Feb 2006) New Revision: 424 Added: trunk/protocol/concept_name_server.txt Log: Added: trunk/protocol/concept_name_server.txt =================================================================== --- trunk/protocol/concept_name_server.txt 2006-02-06 16:25:41 UTC (rev 423) +++ trunk/protocol/concept_name_server.txt 2006-02-07 11:18:29 UTC (rev 424) @@ -0,0 +1,48 @@ +# +# GLOBAL UNIQUE ALIASES FOR CONCEPTS +# +# It is recommended to form aliases by using the following syntax: +# CONCEPT_ABBREVIATION@NAMESPACE_ABBREVIATION +# + + + +[concept_source] + +label = ABCD v1.20 +namespace = http://www.tdwg.org/schema/abcd/1.20 +alias = abcd120 +location = http://www.bgbm.org/TDWG/CODATA/Schema/ABCD-1.20.xsd + +[aliases] + +SourceInstCode /DataSets/DataSet/OriginalSource/SourceInstitutionCode +SourceName /DataSets/DataSet/OriginalSource/SourceName +DateSupplied /DataSets/DataSet/OriginalSource/SourceLastUpdatedDate +DateUpdated /DataSets/DataSet/DatasetDerivations/DatasetDerivation/DateSupplied +SupplierName /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Supplier/Person/PersonName +TermsOfUse /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Rights/TermsOfUse +LegalOwnerOrganisation /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Rights/LegalOwner/Organisation/OrganisationName +LegalOwnerPerson /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Rights/LegalOwner/Person/PersonName +Disclaimer /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Statements/Disclaimer +Logo /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Statements/LogoURL +DatasetDescription /DataSets/DataSet/DatasetDerivations/DatasetDerivation/Description +UnitID /DataSets/DataSet/Units/Unit/UnitID +RecordBasis /DataSets/DataSet/Units/Unit/RecordBasis +HigherTaxon /DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/HigherTaxa/HigherTaxon +ScientificName /DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/NameAuthorYearString +AuthorString /DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/AuthorString +BotGenus /DataSets/DataSet/Units/Unit/Identifications/Identification/TaxonIdentified/ScientificNameAtomized/Botanical/Genus +Identifier /DataSets/DataSet/Units/Unit/Identifications/Identification/Identifier/IdentifierPersonName/PersonName +IdentDate /DataSets/DataSet/Units/Unit/Identifications/Identification/IdentificationDate/ISODateTimeBegin +TypeStatus /DataSets/DataSet/Units/Unit/UnitStateDomain/SpecimenUnit/NomenclaturalTypeDesignations/NomenclaturalTypeDesignation/TypeStatus +ImageURI /DataSets/DataSet/Units/Unit/UnitDigitalImages/UnitDigitalImage/ImageURI +GatheringDate /DataSets/DataSet/Units/Unit/Gathering/GatheringDateTime/ISODateTimeBegin +Collector /DataSets/DataSet/Units/Unit/Gathering/GatheringAgents/GatheringAgent/Person/PersonName +Project /DataSets/DataSet/Units/Unit/Gathering/Project/ProjectTitle +Locality /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/LocalityText +Country /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/Country/CountryName +Longitude /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLong/LongitudeDecimal +Latitude /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/SiteCoordinateSets/SiteCoordinates/CoordinatesLatLong/LatitudeDecimal +Altitude /DataSets/DataSet/Units/Unit/Gathering/GatheringSite/Altitude/MeasurementAtomized/MeasurementLowerValue +Description /DataSets/DataSet/Units/Unit/UnitDescription Property changes on: trunk/protocol/concept_name_server.txt ___________________________________________________________________ Name: svn:keywords + "Id Date Revision URL" Name: svn:eol-style + native

1 0

Re: Metadata and use cases
by Greg Whitbread 03 Feb '06

03 Feb '06

Ricardo, > Regarding LSIDs specifically, our biggest challange is to find an > appropriate way to define stable byte-identical data for our objects. We > have therefore been thinking mostly of turning everything to metadata. > We would be very interested in knowing what your thoughts are regarding > that issue. > Some comments on metadata and a few observations on the process. Hoping it lands before you break. I did not find persistence listed as a use case for GUIDs. But persistence of both GUID and data object should be one of our most important goals. LSIDs biggest advantage lies in the fact that the data should not change. This means that Donald's requirement for equivalence of ID and data object can be satisfied as long as we, even if much of it is duplicated as RDF metadata, also preserve the record (TCS, ABCD, DC,...) as data. LSID metadata will be more than an objects data values - extending to relationships between objects and links to alternative representations etc - and rarely complete for any one record. Rarely persistent. It is hard to imagine the benefit of a full ABCD, TCS or UBIF record as RDF. GUID metadata != GUID but GUID == Data object. Data object == object metadata but GUID != object. With persistence, facts based on data behind GUIDs may be compared and evaluated. Persistence enables the establishment of protocols for consolidating after market validation and correction of distributed data sets. The mapping of duplicates. Our data use agreements can specify that the GUID remains with an object at all times and that update or correction of that object will require a new version number, registration and appropriate documentation using metadata, preferably for both new and superseded versions. We can distribute maintenance of our primary sources to obtain global benefit from the value added after extraction. Without it ... we already have data extracted, altered, used for analysis then dumped, or worse ... lauded as superior, re-distributed ... languishing...re-used years after it has passed its use-by-date. If this process, as I perceive it after reading through these 240 posts, is going to work, then the custodians of object/concept/name metadata among us will have to give freely of these data. APNI, IPNI, AVH, BPH, etc will simply have to accept that they cannot participate, or even survive, if they are not prepared to freely distribute any or all of their data holdings to those that ask. But distributed with the above data use caveat conserving GUID and data object equivalence: GUIDs in this scenario may function as digital signatures establishing custodial rights wherever a record is found. Always pointing back to whence it came. Easy to check, update or communicate correction. Returning value to the source. Perhaps even making it worth the while and expense. Giving us time to complete the task. greg -- Greg Whitbread <ghw(a)anbg.gov.au> ANBG/CPBR/ANH

1 0

Message deleted
by ***** 02 Feb '06

02 Feb '06

Message deleted

1 0

Dave Thau's GUID comparison
by Kennedy, Jessie 02 Feb '06

02 Feb '06

Hi Folks As discussed yesterday in the GUID meeting, attached are the documents published by Dave Thau when he was working on SEEK and evaluating GUIDs for the SEEK project. Jessie This message is intended for the addressee(s) only and should not be read, copied or disclosed to anyone else outwith the University without the permission of the sender. It is your responsibility to ensure that this message and any attachments are scanned for viruses or other defects. Napier University does not accept liability for any loss or damage which may result from this email or any attachment, or for errors or omissions arising after it was sent. Email is not a secure medium. Email entering the University's system is subject to routine monitoring and filtering by the University.

1 0

Re: LSID & resolution discovery service (was: identifiers for geologic samples)
by Kevin Richards 01 Feb '06

01 Feb '06

Not a problem if we, as a group, agree upon using the standard LSID authorities and reolution services. The only problem will then be external parties that want to integrate with TDWG data sets and have already used a proprietary lsid authority format. To fix this the client requesting LSID information would need to install and use an LSID resolver that can handle that proprietary authority format. Kevin >>> ricardo(a)TDWG.ORG 02/01/06 9:08 AM >>> "The LSID Resolution Discovery service has only one method that takes any LSID and returns a list of LSID Resolution services that are responsible for the given LSID. The method may raise an exception if it fails to find an appropriate LSID Resolution service for the given LSID. This may occur particularly when the authority identification field of the LSID is less standardized (which may occur for local services known only to a limited number of clients)." Does that property of LSID brings any implications for our group? Cheers, Ricardo > > Also, LSIDs are required by the spec to be semantically opaque. > Though, this has some exceptions, and semantic opacity is narrowly > defined, I would say that except for resolution service discovery > services---and such services that use DNS are narrowly constrained by > the spec---, those applications that ascribe meaning to parts of an > LSID are probably guilty of violating the spec and perhaps don't > deserve that much sympathy. > > cf Section 8 and Section 13.3 of http://www.omg.org/docs/dtc/04-05-01.pdf > > I hope that those who argue against LSIDs on either of the above two > grounds will place in the wiki (or point me to where it already is) > how I am misreading the spec.If I am reading it correctly, I don't > understand how the arguments Rod puts forth here would lead to > rejection of LSID whatever other disadvantages it may have compared to > alternatives. > > This is a familiar sounding point and maybe somebody answered me the > last time I whined about it, long ago in a mailing list far, far away. > My apologies if so. > > Bob Morris ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 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: How GUIDs will be used
by Nozomi Ytow 01 Feb '06

01 Feb '06

Donald, > We then have the identifiers I1 and I2. In different situations these may > serve as identifiers for O1 and O2 or for D1 and D2 or for D1+M1 and D2+M2. > None of these is necessarily right or wrong. Appropriate practices must be > defined in each case. It is "wrong" to interprete I1/I2 as identifiers of O1/O2. They could be identifiers of Ds or D+Ms, but shouldn't be ID of Os. Isn't it our agreement at very early stage of this list? Interpretation of I1 and I2 is responsibility of applicagtions, not of GUID itself. What we need to decide is D or D+M, not O. I dont have sufficient time to spend on this issue at this moment for taching biodiversity informatics to undergraduate students, so I hope I didn't miss some important assumption already mentioned on the list... Cheers, James

1 0

Re: Combined response
by Bob Morris 01 Feb '06

01 Feb '06

Yes, it only works for the reason you say. In organizations where the network administration is unable, undertrained, underfunded, or unwilling to assert total physical control of all the machines on the local network, it can break down badly while still working correctly. A few months ago a a professor in another department improperly put a machine on the campus network using an IP address assigned to our department, which happened to be that of our department's mail server. Because the university has not invested enough in network management hardware and software, it required 6 hours of searching for the rogue machine by unplugging network cables one at a time from 10 different devices each with 48 cables, and testing for whether the rogue machine had gone away. During all that time, and the 12 hours preceding where we didn't know that our problem was a rogue machine, no mail whatsoever could reach us. The DNS correctly identified the IP address. The Internet routers and the campus routers correctly found the machine with the published IP address, and naturally that machine declined to answer email protocol requests, which then queued up all around the world awaiting whatever the sender's retry and local timeout policies dictated. The network worked exactly as it was designed to, and we were screwed. This shows you why, for example, nobody operates telephone systems in which end-users get to choose their own telephone number, at least without enforceable permission from an authority. Worse, IP and DNS are badly spoofable in many situations where it is not worth the expense to prevent the spoof. Examples are outside the realm of this list, but probably most apply to GUID resolution to. It should be examined at the workshop whether spoof insulation is a requirement or not. On 2/1/06, Richard Pyle <deepreef(a)bishopmuseum.org> wrote: > > Bob Morris wrote: > > > > I agree that it might, but I don't think it necessarily has > to. Again, > I > > > point to IP addresses and DNS. They are obviously harmonized, but > aren't > > > locked up in administrative layers (or are they???) > > > > Yes, they are, big time. Both have a hierarchy of organizational > > administrative control ending at IANA, the Internet Assigned Numbers > > Authority, http://www.iana.org/. If an individual proposes to put a > machine > > onto the internet, they receive permission, an IP address, and a dns > name > from > > the appropriate local authority managing the network to which they will > > physically connect. Often that permission and issuance is done by > software > > on a network host on that network (usually a DHCP, dynamic host control > > protocol, server. In turn, the network administrators will have received > > permissions from the next administration up the chain to issue a > specific > > block of IP addresses, or specific form of names. > > I think the active phrase is "locked up". My point is that the system > works -- right? Or does it only "work" because the en-users are so well > insulated from the administrative process? Would IP work more effectively > if it wasn't harmonized on a global scale, in a centralized sort of way? > > Rich >

1 0

Re: How GUIDs will be used
by Donald Hobern 31 Jan '06

31 Jan '06

>> We need to decide under which circumstances we want this to be a >> bidirectional implication, i.e. that: >> >> B) O1 == O2 --> I1 == I2 >> > >My 30 second reaction to this is that it assumes that the metadata >attached to I1 and I2 are the same, which may often not be the case. Rod is of course right. The example I gave was a major oversimplification. I would say that we need to distinguish several more levels in order to understand what we mean by "the same data object". Let me expand a little with some extra symbols. O1 and O2 are the (real-world) objects or events to which we wish to refer in our computer systems. Examples would be a specimen in a collection, or a nomenclatural act. D1 and D2 are digital representations of O1 and O2. This immediately raises a large number of questions which are probably external to the development of a basic GUID infrastructure, but which need to be addressed in applicability statements for different subdomains. We need to be sure that we agree on what is a data representation for the object/event and the extent to which it must have a standard form (including whether or not identity of byte streams matters to us). In some cases it may be hard for us to identify anything that we regard as essential to a canonical digital representation of an object/event. (This has already been identified as a problem that we would need to address with LSIDs.) It is also worth noting that there are cases in which distinguishing between objects and events and their digital representations is difficult or perhaps meaningless. Some objects of interest to us may not exist except in a digital form. M1 and M2 are representations of metadata that describe D1 and D2. Again the distinction between digital representations and associated metadata is rarely completely clear (applicability statements again needed). We then have the identifiers I1 and I2. In different situations these may serve as identifiers for O1 and O2 or for D1 and D2 or for D1+M1 and D2+M2. None of these is necessarily right or wrong. Appropriate practices must be defined in each case. The meaning of the identity I1==I2 will vary according to these defined practices. If I1==I2-->O1==O2 (and nothing more), we may retrieve different data records and metadata as alternative resolutions of the same identifier. Returning full circle to my original point, the inequality I1!=I2 may tell us that M1 and M2 differ, or that M1 and M2 and D1 and D2 differ, or that M1 and M2 and D1 and D2 and O1 and O2 differ, or in other cases may imply none of the above. We need to be sure which of these inferences we need to support for each subdomain. On top of this we also need to consider whether the same identifier should be used for D1 and for D1', where D1' is a later version of D1 (with some corrections or modifications of the data elements). I hope this makes some things clearer for someone. It helps me with thinking about the problems. Thanks, Donald --------------------------------------------------------------- Donald Hobern (dhobern(a)gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ---------------------------------------------------------------

1 0