<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Yes, I agree with statements made by Bob, Kevin, and Rich: if we get
the class Individual, we need to think carefully what properties go
with it. The only one that is obvious to me at the present is
individualRemarks. In line with what Bob said, I think that figuring
out how we will use terms and trying to model relationships and
properties in RDF will make it more clear what terms can be
appropriately used with instances of various classes and whether it
"works" to have a term be applied to several classes. I think
individualCount is a case in point. At first it seemed to me that it
should be in the Individual class, because it's a property of
Individual the way I've defined Individual. But since the count may
change with time, then maybe it should be a property of Occurrence
(which are essentially observations of the Individual at different
times). But how often is anyone actually going to track the number of
individuals over time? I could see it happening with wolf packs, but
in that case one would probably rather track each individual wolf
rather than calling the whole pack an "individual". So what makes
sense depends on how people need to use individualCount.<br>
<br>
Rich commented that he wasn't sure why catalog number wasn't in the
Record Level terms. I'm also wondering about that, particularly since
I would use a catalog number with a token (e.g. PreservedSpecimen,
StillImage) or Individual (if it were a living specimen) but probably
not for an Occurrence (although somebody else might). I believe that
in a previous discussion of the xxxxxxxID terms on tdwg-content (can't
check because Internet is out at my house and I'm working offline)
someone said that all of those terms should go into the Record Level
terms because one might use them as properties for various classes.
But that hasn't happened. Is that because nobody has gotten around to
it or because it takes some kind of official action to "change the
standard"? To recap that conversation from memory, it was agreed that
people appropriately use the xxxxxxxID terms two ways: as column
headings in a database table to indicate what the identifier is for the
row, and as ID references connecting the row to records in other
tables. In the first kind of use, it makes sense to have xyzID in the
class xyz, but in the second case it does not. You can see an example
of these dual uses in the DwC XML guide. This is another example where
some clear instructions on the use of terms in the DwC documentation
would help (i.e. to say that both of these kinds of uses are
acceptable). When I was trying to understand Paul's email on Taxon and
Name, I was having trouble because I was continually confused about
which of the two ways of using xxxxxxID terms he was intending as
either would apparently be correct.<br>
<br>
With regards to "individualScope", I was assuming that could be covered
in individualRemarks. I suppose individualScope could have a
controlled vocabulary and individualRemarks not. But again, I think we
can see how people want to use Individuals before deciding what terms
need to go with it (assuming that Individual gets added to DwC). <br>
<br>
Steve<br>
<br>
Bob Morris wrote:
<blockquote
cite="mid:AANLkTinp8PS2b0-3njNwxh7aWbY9CkKbdKF+FUk+GO_b@mail.gmail.com"
type="cite">On Sun, Oct 31, 2010 at 4:21 PM, Kevin Richards <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:RichardsK@landcareresearch.co.nz" target="_blank">RichardsK@landcareresearch.co.nz</a>></span>
wrote:<br>
> Not sure if this has been mentioned as I have struggled to keep up
with this thread, but it sounds to me like the benefit of the
Individual class/properties is to be able > to link together various
web resources that refer to data obtained from the same individual in
some manner, so we probably need terms that allow the description of
> how these individuals, or parts of individuals relate to each
other. The Scope idea will help, but maybe there is a need for terms
like "partOfIndividual",<br>
> "derivedFromIndividual"?<br>
<br>
Now you're talkin Kevin! Actually, now you're talking about ontology,
and I plead: Go slow, develop use cases; develop competency questions;
develop tools. I note that Steve was careful to separate the question
of adding terms to the normative, representation free, DwC, from the
problem(s) of making an RDF representation of same: <br>
<br>
<div class="gmail_quote">On Sun, Oct 31, 2010 at 10:38 AM, Steve
Baskauf <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:steve.baskauf@vanderbilt.edu" target="_blank">steve.baskauf@vanderbilt.edu</a>></span>
wrote:
> <br>
> I am pleased with the significant and thoughtful
discussion
that has taken place on the tdwg-content email list<br>
> regarding the
relationships
among Occurrences, <br>
> Individuals, and other entities that are a part of
the
community's thinking about biodiversity metadata<br>
> and the way that those
metadata are structured.<span> [...]</span><span> </span>I
feel that > would be critical for<br>
>facilitating the ultimate development of a recommendation for the
representation of Darwin Core as RDF.<span></span>
<div bgcolor="#ffffff">> [...]</div>
</div>
<br>
<br>
This separation is important, because what use one intends to make of
an RDF representation has a lot of bearing on what "gotcha's" one has
to take care about. <br>
<br>
For example, if there is a desire to exploit formal semantics available
for RDF stack ---which will probably emerge as a requirement once one
starts talking about relations between properties---then different
surprises will emerge from the pitfalls if one "merely" wishes to put
SKOS relations on the properties and reason about the SKOS instead of
the science. But I guess, for example, that Miranker's Morphster
project [1] will benefit most in its current use cases, from good
mereological ontologies for descriptive data, not just stuff like "more
general than".<br>
<br>
There are surprises even in the simplest use of RDFS and formalisms
about classes. I've previously whined about premature assignment of
rdfs:domain while conceding (did I???) that it can sometimes make a
designer's intention clearer to humans. Perhaps more startling is that
type assignment automatically "creates" an rdfs:class if one was not
already available, due to the formal semantics of rdf:type [3]. Thus,
in an earlier posting, Paul Murray has (unintentionally?) introduced a
new class apni:TaxonName in 33407.rdf [2] via <br>
<rdf:type rdf:resource="<a moz-do-not-send="true"
href="http://biodiversity.org.au/voc/apni/APNI#TaxonName"
target="_blank">http://biodiversity.org.au/voc/apni/APNI#TaxonName</a>"/><br>
<br>
Then there is the question of adequate tools for the desired style of
ontology architecture. The OWL community's important tools are not
friendly even to DublinCore, whose style is(?) what DwC follows. (Steve
Baskauf has complained to me in private email that the Manchester
validators don't seem to even check rdfs vocabulary correctly; Paul
complained that Protege4 makes a big mishmash of Properties when
importing DwC. (Both of these are probably false positives in cases of
insufficient typing of properties themselves, and the OWL community
probably doesn't care about the origin or utility of such weak typing
[4]. )<br>
<br>
So the hard part is yet to come. But I agree with you. It is quite
appealing.<br>
<br>
Bob Morris<br>
<br>
Robert A. Morris<br>
Emeritus Professor of Computer Science<br>
UMASS-Boston<br>
100 Morrissey Blvd<br>
Boston, MA 02125-3390<br>
Associate, Harvard University Herbaria<br>
email: <a moz-do-not-send="true" href="mailto:morris.bob@gmail.com"
target="_blank">morris.bob@gmail.com</a><br>
web: <a moz-do-not-send="true" href="http://bdei.cs.umb.edu/"
target="_blank">http://bdei.cs.umb.edu/</a><br>
web: <a moz-do-not-send="true"
href="http://etaxonomy.org/mw/FilteredPush" target="_blank">http://etaxonomy.org/mw/FilteredPush</a><br>
<a moz-do-not-send="true" href="http://www.cs.umb.edu/%7Eram"
target="_blank">http://www.cs.umb.edu/~ram</a><br>
phone (+1) 857 222 7992 (mobile)<br>
<br>
[1] <a moz-do-not-send="true"
href="http://www.cs.utexas.edu/%7Emiranker/studentWeb/MorphsterHomePage.html"
target="_blank">http://www.cs.utexas.edu/~miranker/studentWeb/MorphsterHomePage.html</a><br>
<div class="gmail_quote">[2] <a moz-do-not-send="true"
href="http://biodiversity.org.au/apni.name/33407.rdf" target="_blank">http://biodiversity.org.au/apni.name/33407.rdf</a>
<br>
[3] <a moz-do-not-send="true"
href="http://www.w3.org/TR/rdf-schema/#ch_type" target="_blank">http://www.w3.org/TR/rdf-schema/#ch_type</a><br>
<div>[4] <a moz-do-not-send="true"
href="https://mailman.stanford.edu/pipermail/p4-feedback/2009-October/002448.html"
target="_blank">https://mailman.stanford.edu/pipermail/p4-feedback/2009-October/002448.html</a><br>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
</blockquote>
</div>
-- <br>
<br>
<br>
</blockquote>
<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>