<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Responses inline.<br>
<br>
Richard Pyle wrote:
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<blockquote type="cite">
<pre wrap="">So then what IS an actual individual organism like the wildebeest calf?
It is a BiologicalEntity if it has been documented as an Occurrence or
assigned an Identification. It is a CollectionObject if it was
collected for a zoo, or shot and mounted in a museum. Or it can be
both simultaneously if it is both documented and collected. If none
of these things were done, then it's neither a BiologicalEntity nor a
CollectionObject - it's simply a wildebeest calf. Define the
class/type of the thing by the properties that you wish to assert for
it (or the competency questions that you can answer for it).
</pre>
</blockquote>
<pre wrap=""><!---->
I think I get where you are coming from here, but I'm very queasy about this
notion that the same "thing" (a mass of flesh & bones) can be represented as
an instance of two different DwC classes, depending merely on what
attributes about the "thing" are emphasized. </pre>
</blockquote>
Well, I have to say I had a problem with this at first. Because most
of the existing classes in Darwin Core are disjoint with other classes
(as in
<a class="moz-txt-link-freetext" href="http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DisjointClasses">http://www.w3.org/TR/2004/REC-owl-guide-20040210/#DisjointClasses</a>), I
was predisposed to thinking that it was "bad" to have two classes that
were not mutually exclusive. But actually we have such classes all the
time. A person can be a member of the class Father, class Teacher, and
class ElectedOfficial depending on which set of properties we can
appropriately apply to that person. In fact, most of the things that
we could consider as "evidence" (i.e. instances of the proposed class
CollectionObject) could probably be members of other classes as well,
such as foaf:Image, foaf:Document, acterms:MultiMediaObject, etc. An
image could be an instance of dwc:CollectionObject because it had
properties such as dwc:catalogNumber and dwc:collectionCode that it
shares with other types of CollectionObjects while at the same time
being a acterms:MultiMediaObject because it has properties like
dcterms:format, xmpRights:UsageTerms, Iptc4xmpExt:creditLine that it
shares with other types of MultiMediaObjects. There isn't anything
wrong with that as far as I know, other than getting used to the idea.<br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">For example, during my recent
trip to South Africa, we took the opportunity of one of our non-diving days
to visit a game park where we saw (among other things), numerous wildebeest
(coincidentally enough). I took video images of these wildebeest with my
GPS-enabled camera, and therefore documented the presence of a specific
individual wildebeest at a particular date and time. Clearly there is a
dwc:Occurrence record there, so it's certainly a BiologicalEntity (by your
definition; i.e., documented as an Occurrence and assigned an
Identification). But does a Game Park constitute the same thing as a zoo?
There are electric fences around the perimeter of the park, so I'm inclined
to think so. Is it also a CollectionObject? Would this be an example of
something that is both?
</pre>
</blockquote>
Well, I've thought about this question quite a bit. My opinion is that
the wildebeest you photographed would not be a CollectionObject. It
seems to me that implicit in the idea of a CollectionObject is an
understanding that someone is "keeping track" of the object and that
there is a reasonable expectation that the particular object could be
produced at will (or at least accounted for if it no longer exists in
the collection). That's what we are doing when we assign
catalogNumbers to things, put them in particular pens, jars, or
cabinets, and keep track of their dwc:disposition. If the game park
were tracking that wildebeest by means of an ear tag, radio collar,
unique color patterns, etc., assigned the wildebeest an identifying
number, kept track of which electric fence unit the wildebeest was
located in, and put this all in a database, then I would say the
wildebeest was a CollectionObject that was a LivingSpecimen. If you
could walk into the park office with the wildebeest's ID number and ask
"what's going on with this wildebeest" and get an answer, it would be a
CollectionObject. I really had to come to grips with this when
thinking about the Bicentennial Oak at Vanderbilt. It is clearly a
CollectionObject in the Vanderbilt Arboretum because it has an ID
number, is on the arboretum's map, and has a record in the arboretum's
database. But Vanderbilt didn't "do" anything physically to make it
become a CollectionObject (i.e. didn't move or plant it - it was there
long before the University). It became a CollectionObject of type
LivingSpecimen when the arboretum started accounting for it by
assigning it a catalogNumber and keeping track of its status in the
collection. That's different from some other random bur oak that I
happen across in the forest. Even if I assign it a GUID and record
it's latitude and longitude, I'm not asserting to anybody that I will
know what is going on with that tree or if it even continues to exist
after I make a record of its Occurrence. It does NOT have a
dwc:catalogNumber, dwc:collectionCode, or dwc:disposition because it
isn't in a collection over which I assert control - it does not have
properties in common with other CollectionObjects. <br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">
The more I think about it, the less confident I am that we really need
*both* new classes. With such potential overlap between them, should we not
simply generalize them both into the same class, and provide whatever
properties are known/relevant in a DwC instance of it?
</pre>
</blockquote>
Well you could say this about any non-disjoint classes. Why not
combine the classes Teacher and ElectedOfficial if a person can be an
instance of both? We don't do that because there are instances where
persons are Teachers and not ElectedOfficials and other instance where
people are ElectedOfficials and not Teachers. Instances of the class
Teacher share properties like numberOfStudents and schoolOfEmployment,
while instances of ElectedOfficial share properties like votesReceived
and yearElected. <br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">
You said that the CollectionObject class is fully capable of doing much of
what I want to accomplish with my vision of "Individual". Could I not say
the exact same thing that a broader definition of CollectionObject (i.e.,
one that doesn't attempt to distinguish the disposition of the same mass of
flesh & bones in the context of human-mitigated captivity/preservation vs.
nature) could be fully capable of accomplishing what you want to accomplish
with Individual? Namely, the three competency questions you established for
the "Individual" (=BiologicalEntity) class.
</pre>
</blockquote>
If we do as you have suggested here, we would limit CollectionObjects
to
individual organisms, their pieces, and aggregations that include
them. That definition would not include all kinds of things which can
serve as evidence (which I think
is what John was suggesting in his proposal) because it would exclude
Images, Sounds, and Documents. It actually would make sense to define
a class of things for "biological material" that could include
individual organisms, their pieces, and aggregations that include
them. That class doesn't currently exist as far as I know. Perhaps it
could be a superclass of LivingSpecimen, PreservedSpecimen, tissue
sample, DNA sample, cell culture, herd, mixed flock, etc. and disjoint
with other classes like Image and Document that could also serve as
CollectionObjects. Whether that "biological material" class would be
synonymous with BiologicalEntity would be a subject for discussion.
Perhaps it does just boil down to the same thing. <br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">An actual single, live organism can serve both as a unit for
resampling and "attachment" of Identifications, AND as an
organizational unit that is part of and which has parts that are
biological samples. Some other entities, such as cohesive pack/herds
and clonal organisms can also serve both purposes. Other entities
cannot: it doesn't make sense to resample dead organisms or pieces of
organisms,
</pre>
</blockquote>
<pre wrap=""><!---->
I guess it depends on what you mean by "resample". Surely a tissue sample
can be removed from a dead organism, and used for DNA sequencing that can
lead to a new Identification instance. I agree that a dead organism cannot
represent the basis for future Occurrence instances, </pre>
</blockquote>
That's what I meant.<br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">but I don't really see
the relevance of that.
</pre>
</blockquote>
I guess it would depend on the agreed definition. If the
BiologicalEntity class only needed to facilitate some of the three
functions that I outlined, then it's not relevant whether the organism
is dead or not (i.e. whether it could potentially be the subject of
additional future Occurrence records). If it needs to always be
capable of facilitating all three functions, then the entity would
probably have to be alive. The most important thing to me is that we
are clear about the definition.<br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Personally, I would like for the third function ("inferring
duplicates"; linking multiple Identifications to the same entity and
being assured that all Identifications of the same Individual would
apply to all artifacts associated with that Individual) to be
accommodated by the definition,
</pre>
</blockquote>
<pre wrap=""><!---->
I definitely support this, and on this basis, I am willing to abandon my
earlier defense for what you would call taxonomic heterogeneity. I still
feel the need to not limit the rank at which a taxon identification may be
applied, but I am ready to abandon my original notion that a rock with
multiple phyla of organism attached should ever be represented as a single
instance with Identification "Animalia". In other words, I've come around
to your perspective on this. I think the power of implied "taxon
identification inheritance" that you advocate in your function #3 overrides
my advocacy for taxonomically heterogenous organisms to be lumped together
with the same instance of the class.
Thus, I now agree with you on the following:
</pre>
<blockquote type="cite">
<pre wrap="">When I used that term, I intended for it to mean that the entity is
believed to be homogeneous to the lowest possible level in the way
that one knows that two branches from the same tree or two parts of
the same clonal organism are guaranteed to have the same taxonomic
</pre>
</blockquote>
<pre wrap=""><!---->identify at every level.
So, from my perspective, we can put that part of the debate to rest.
</pre>
</blockquote>
OK, cool. I think that simplifies the matter considerably.<br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">This email is now at or has exceeded the length of an email that many
people will take the time to read. So I will draw it to a close and
post a separate email on the topic of competency questions for John's
proposed class "CollectionObject" which I believe address Rich's
desire to track "real-world" objects (samples, re-samples, etc.).
</pre>
</blockquote>
<pre wrap=""><!---->
Rather than respond separately to the other post, I've just made this single
response with the new subject heading, because I think we're narrowing down
the scope of the debate in such a way that we should now focus on the
difference between the two proposed new classes
("Individual"/"BiologicalEntity", and "Evidence"/"CollectionObject").
For a while, I thought I saw the difference as being the "Evidence" was more
like an instance of "Documentation" (e.g., an image, a label on a preserved
specimen, etc.); rather than the flesh-and-bones organism itself. But with
your suggestion that this class may serve the function(s) of my desires for
the "Individual" class, the waters have been muddied a bit in my own mind.
I guess if there are to be two separate classes, then I would favor a more
generalized "Organism" class to serve the functions of what Steve has
described for both the "CollectionObject" and "BiologicalEntity" classes,
but then define a separate "Documentation" class that serves as the basis of
"proof" for an Occurrence.
</pre>
</blockquote>
I think there is probably more than one way of sorting this out. In my
email I've suggested one method of defining the classes, which more or
less corresponds to the approach Cam and I suggested with darwin-sw.
This method is implemented on my website, e.g. for a particular tree in
the UNC-Greensborough campus having GUID
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/uncg/39">http://bioimages.vanderbilt.edu/uncg/39</a><br>
Using the terminology of the current discussion, the tree is an
instance of BiologicalEntity (called IndividualOrganism in darwin-sw).
It's existence is documented by 17 instances of CollectionObject
(called Tokens in darwin-sw): 15 that are StillImages, one that is a
PreservedSpecimen in the NCU herbarium, and one that is a
LivingSpecimen in the UNC-G arboretum (i.e. the tree itself). It would
be painful to pick through the RDF (located in the files
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/uncg/39.rdf">http://bioimages.vanderbilt.edu/uncg/39.rdf</a> for the tree,
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/specimen/ncu592804.rdf">http://bioimages.vanderbilt.edu/specimen/ncu592804.rdf</a> for the
specimen, <a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/kirchoff/em2535.rdf">http://bioimages.vanderbilt.edu/kirchoff/em2535.rdf</a> and 14
other files for the 15 images) but suffice it to say that the
BiologicalEntity (the tree) has the properties hasIdentification,
hasOccurrence, foaf:depiction (relating it to the images), and
dcterms:hasPart (relating it to the specimen) as would be expected
based on the three "purposes" I outlined for BiologicalEntity. The 17
CollectionObjects have the properties dwc:institutionCode,
dwc:collectionCode, dwc:catalogNumber, evidenceFor [an Occurrence], and
derivedFrom [the BiologicalEntity] as would be expected based on how I
described CollectionObject instances. Not all of these properties are
from Darwin Core in part because DwC doesn't have any object properties
relating the classes (we had to make those up). So what I would like
to see is what particular properties (DwC and otherwise) would be held
in common by instances of each of the two classes that Rich suggests:
"Organism" and "Documentation". <br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">
On a semi-related topic, I don't think it's appropriate to create a DwC
class simply to establish a Many-to-Many relationship between instances of
other classes. That function (in my mind) is already elegantly fulfilled by
the existing dwc:ResourceRelationship class (another major discussion that
will need to take place on this list). While it's true that certain DwC
classes do serve a M:M function (e.g., Occurrence), I think that classes
should represent "things" that are unambiguously different, with very
specific sets of properties.
</pre>
</blockquote>
Well, "many-to-many relationship" was the way Kevin described it and I
liked that because it described succinctly the way that "Individual"
fit into the "crow's feet" and block diagram that you included in
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/pipermail/tdwg-content/2010-October/001703.html">http://lists.tdwg.org/pipermail/tdwg-content/2010-October/001703.html</a>
and which I used as the basis for the Fully Normalized Model diagram at
the bottom of
<a class="moz-txt-link-freetext" href="http://code.google.com/p/darwin-sw/wiki/RelationshipToExistingModels">http://code.google.com/p/darwin-sw/wiki/RelationshipToExistingModels</a> .
That doesn't mean that the class BiologicalEntity (a.k.a. "Individual"
or dsw:IndividualOrganism) doesn't actually represent a real "thing".
The BiologicalEntity instance that is the tree
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/uncg/39">http://bioimages.vanderbilt.edu/uncg/39</a> is an actual "thing", not just
an abstract database artifact. It just can have the relationships "one
tree:many Occurrences" and "one tree:many Identifications". The same
would be true of all BiologicalEntity instances which would have
specific sets of properties that would differ from the specific
properties of CollectionObjects as I outlined in the paragraph above. <br>
<blockquote cite="mid:006501cc4be8$f6c763e0$e4562ba0$@bishopmuseum.org"
type="cite">
<pre wrap="">
On a final, somewhat encouraging note, I *really* like the diagram
represented in the link that Cam sent earlier:
<a class="moz-txt-link-freetext" href="http://code.google.com/p/darwin-sw/">http://code.google.com/p/darwin-sw/</a>
During one of our non-diving days in South Africa, Rob Whitton and I spent
some time thinking about the BiSciCol project (BCC'd on this post), and we
studied this diagram and both agreed it represents an *excellent* foundation
to both this discussion on proposed new DwC classes, and the BiSciCol
project in particular.
</pre>
</blockquote>
Cool! Go BiSciCol!<br>
<br>
Steve<br>
<br>
<pre class="moz-signature" cols="72">--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences
postal mail address:
VU Station B 351634
Nashville, TN 37235-1634, U.S.A.
delivery address:
2125 Stevenson Center
1161 21st Ave., S.
Nashville, TN 37235
office: 2128 Stevenson Center
phone: (615) 343-4582, fax: (615) 343-6707
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
</pre>
</body>
</html>