[tdwg-content] Of Evidence and Individuals (Was Plea for competency questions)

Steve Baskauf steve.baskauf at vanderbilt.edu
Wed Jul 27 16:50:24 CEST 2011

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. 

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 
(http://rs.tdwg.org/dwc/terms/index.htm): "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. 

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 http://rs.tdwg.org/dwc/terms/index.htm change if we followed 
Rich's suggestions?  How would we shift existing terms under the new 

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.


Bob Morris wrote:
> On Wed, Jul 27, 2011 at 12:52 AM, Steve Baskauf
> <steve.baskauf at vanderbilt.edu> wrote:
>> [...]
>> 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.
> 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
> http://code.google.com/p/darwin-sw/source/browse/trunk/dsw.owl 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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.tdwg.org/pipermail/tdwg-content/attachments/20110727/b5a2fa6f/attachment.html 

More information about the tdwg-content mailing list