<!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">
I would like to clarify that although RDF files were mentioned in my
previous post and although I've used some terms from the OWL world in
my post, the discussion we are having is not about OWL or RDF. It's
about addition of two classes to Darwin Core which is general-purpose
and at the moment doesn't even have any sort of guidelines for its use
in RDF. There has been a general criticism of the "Individual class"
proposal that it doesn't really "do anything" that is beneficial to the
community or that it cannot be defined in a way that makes it usable.
The examples that I gave involved darwin-sw and my website because they
aren't theoretical. They actually exist and (I believe) demonstrate
that the classes CollectionObject and BiologicalEntity (or Token and
IndividualOrganism) CAN actually serve a useful purpose. So at this
point I would rather not let the discussion get distracted by the
technical OWL and RDFS issues that Bob raises below - the discussion is
about John's BiologicalEntity and CollectionObject term proposals, not
technical problems with darwin-sw. <br>
<br>
So keeping this on a general level, it is my understanding that classes
in DwC do not have any formal relationship to the terms that are listed
under them because DwC terms do not have ranges and domains. So what
then are DwC classes for? To quote the DwC Quick Reference guide
(<a class="moz-txt-link-freetext" href="http://rs.tdwg.org/dwc/terms/index.htm">http://rs.tdwg.org/dwc/terms/index.htm</a>): "The terms are
organized by categories (in bold) in the index. The categories
correspond to Darwin Core terms that are classes (terms that have other
terms to describe them). The terms that describe a given class (the
class properties) appear in the list immediately below the name of the
category in the index." It seems to me that our goal should be to
have a DwC class for each type of basic "thing" that needs to be
tracked in our community and that the terms listed under each class
should truly "describe a given class" (i.e. actually be a property of
instances of that class). Right now, I think there is a general
consensus that there is a problem with the Occurrence class because not
all of the properties under that class actually describe Occurrences
the way we've been talking about them. John's proposal is one way to
fix this problem. Is there a more sensible way to organize terms
within classes that fit the resources we are tracking in our
community? If so, then let's put it on the table. <br>
<br>
It is my belief that if we fix some of the problems that have been
discussed over the last couple years, the DwC classes could be
rdfs:Class's and the terms listed under them in DwC could serve as
rdf:Property's of instances of those classes. But that is not a
necessity - one could just as easily say that the DwC classes are
"things" that deserve their own table in a database and that the terms
listed under that class are appropriate column headings in that table.
Rich has made some suggestions for a different way to define the
classes than what I suggested - that's great! If we had "Organism" and
"Documentation" classes, what would be the column headings in database
tables holding the metadata for resources in those classes? How would
the page <a class="moz-txt-link-freetext" href="http://rs.tdwg.org/dwc/terms/index.htm">http://rs.tdwg.org/dwc/terms/index.htm</a> change if we followed
Rich's suggestions? How would we shift existing terms under the new
classes? <br>
<br>
After thrashing for two years about what the classes should be part of
DwC and what those classes represent, it looks like we may be close to
some kind of a consensus that could actually be incorporated into the
standard. Let's not get distracted - there are ongoing efforts like
BiSciCol and work to clarify how RDF can be used in our community that
would only be hampered by that.<br>
<br>
Steve<br>
<br>
Bob Morris wrote:
<blockquote
cite="mid:CADUi7O4oSkNqy3PJzbD6m_dXb5Y2vDk-xz3Ca8sx998tRfKarg@mail.gmail.com"
type="cite">
<pre wrap="">On Wed, Jul 27, 2011 at 12:52 AM, Steve Baskauf
<a class="moz-txt-link-rfc2396E" href="mailto:steve.baskauf@vanderbilt.edu"><steve.baskauf@vanderbilt.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">[...]
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.
</pre>
</blockquote>
<pre wrap=""><!---->
OWL supports intersection and union. In OWL the set of things that
are both a Teacher and an Elected Official would form a class. It
would perhaps have fewer individuals in it than either class, but in
OWL it is nevertheless a class. Similarly the set of things that are
either a Teacher or an ElectedOfficial, though not necessarily both,
is an OWL class. Note that
<a class="moz-txt-link-freetext" href="http://code.google.com/p/darwin-sw/source/browse/trunk/dsw.owl">http://code.google.com/p/darwin-sw/source/browse/trunk/dsw.owl</a> is at
this writing not an OWL ontology, as you will see if you try to put it
into the Manchester OWL validator. Much of that failure is minor
syntactic botches, but when you fix them, some issues remain about
dsw's secondary goal to "(hopefully) making design choices that do not
constrain full SW reasoning downstream".
RDFS does not guarantee that the intersection of two classes is a
class, but allows you to avow that in particular cases if you wish,
whereas OWL always requires it. More to the point, RDFS allows you to
conceptually think of classes and properties as having the same kind
of structure, so that you can effectively talk about intersecting
properties, e.g. define a property that is true for those individuals
for whom two particular properties are true. This is discussed on p.
135 of [1], though you won't like the word "infer" used there. Chapter
8 of [1] introduces a subset RDFS-Plus of OWL that is largely
motivated by being content with the expressiveness of SPARQL, which I
guess fits in your comfort zone, especially as to "AND". My
understanding of LOD is that its community is indeed content with the
expressiveness of SPARQL for now, and dsw probably corresponds to the
approach of Chapter 8 in a way that meets your primary goals for dsw.
In summary, I suspect that you are struggling about modeling
individuals because:
a. You believe in your heart that there is a fundamental difference
between properties and classes but
b. RDFS does not require that of one's models and
c. dsw is expressed in RDFS and not in a modeling language that
requires you to abandon a.
[1] Dean Alemang and Jim Hendler "Semantic Web for the Working
Ontologist", 2nd Edition 2011
Bob
</pre>
</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>