Adding to what Rod said the important thing to point out is that using GUID+RDF you can reason about resources you don't own. So the herbarium that discovers it has a duplicate of something in another herbarium can publish the fact without involving the other herbarium.
In fact I can make assertions I have only just invented about things in two collections that have never heard of me.
But wait... there is more. As Arthur points out we already have most of this stuff defined. TCS encapsulates a whole load of semantics about nomenclatural relationship (types of type etc) and TaxonConcept relationship (child taxon of, hybrid parent of etc) and ABCD has similar knowledge about collections. A great deal of re-engineering and transition is involved. We mustn't go throwing any babies out with the bath water.
Also serving this stuff may be problematic....
So yes GUID+RDF seems to solve most every problem just at the moment.
Roger
Arthur Chapman wrote:
Rod
This is a neat solution and may well work. I like it!
It is somewhat akin to the "Relation" element in Dublin Core but which has generally not been implemented with a controlled vocabulary as was recommended at the Canberra meeting of Dublin Core in about 1996 or 1997.
It was implemented in the Australian Government Locator Service (AGLS) as Australian Standard AS5044 with a controlled vocabulary. The vocabulary is not what we would need, but gives a parallel example
isVersionOf hasVersion isReplacedBy replaces isRequiredBy requires isPartOf isReferencedBy isFormatOf hasFormat isBasisFor isBasedOn
http://www.naa.gov.au/recordkeeping/gov_online/agls/AGLS_reference_descripti...
Cheers
Arthur
From Roderic Page r.page@BIO.GLA.AC.UK on 25 Nov 2005:
These relationships would be specified in the metadata attached to the GUIDs, not the GUIDs themselves (they are simply unique identifiers).
For example, if we think of you tax number/Social Security Number/National Insurance Number (insert whatever identifier your government attaches to you here), then you could have two GUIDs such as
JE 5679434A
and
JH 5679434B
The metadata for JE 5679434A could contain a statement that the individuals are related, e.g. something like
<rdf:Description rdf:about="JE 5679434A"> <isMarriedTo rdf:resource ="JH 5679434B" /> </rdf:Description>
In other words, the person identifed by "JE 5679434A" is married to the
person identified by "JH 5679434B".
One can develop ontologies that specify these relationships, and enable
us to deduce other facts. For example, if X is married to Y, then Y is married to X, but if Z is a child of Y, Y is the parent of Z, and so on. What is nice is that you wouldn't have to explicitly state that Y is the parent of Z in the metadata Y, it can be inferred from the relationship Z is a child of Y.
I use RDF here because these are the kind of things it handles nicely. All (!) you'd need is a consistent vocabulary to describe the relationships. RDF already has some basic ones ("sameAs", "subPropertyOf", etc.). In the examples you provide, I guess you'd want
"part of", "extracted from", "hosted by", "parent of", "mother of", etc.
Does this help?
Regards
Rod
On 25 Nov 2005, at 11:18, Arthur Chapman wrote:
Below I have placed two scenarios that show some of the cross-discipline problems I believe we face with GUIDs. They don't provide the answers, alas!
It would appear to me that each of these separate entities need a GUID; but that each needs to show some relationship (nearly a genealogy or pedigree line) - child of (i.e. derived from); brother
of>
(duplicate collection); sister of (wet collection); part of (genetic study) etc. Can these be built into a GUID?
If we just look at the simplest problem, where a herbarium makes a collection and sends out duplicates to other herbaria. More often than not, the duplicates are distributed prior to receiving a catalogue number in the originating ionstitution. We can only thus identify duplicates using collector name and number, but these are
not>
always unique, and not all collectors use numbers. - We can't use the
lat/long coordinates as these are often put on after distribution and
are often different (one collection I looked at in 5 different herbaria was given 4 different lat/longs). The resolution of many of these duplicates will need to be a human problem - possibly helped by
parsing routines similar those being developed for location information in the BioGeomancer project, and possibly some artificial
intelligence (to sort out collector's names used in different ways, etc. - initials first/surname first, etc.).
I wish I could supply the answers!
These scenarios don't show up all that well in text, I have also attached a word document.
PLANT
- Collector Makes collection
a. Provides collector number (not always Unique) <Fred 123> i. Submits collection to Herbarium
- Herbarium supplies collection number <Index
Herbarium-CANB12345> >
- and a name <TCS-123454>
a. Herbarium distributes collections to other herbaria i. New herbaria supply collection numbers <IH-NY65432;IH-MO34562; IH-K98765>
=== message truncated ==
--
------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger@tdwg.org +44 1578 722782 -------------------------------------