<!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">
Well, at the risk of being scolded, we actually DID declare some
classes to be disjoint in the ontology. Those classes are Location,
Event, Occurrence, IndividualOrganism, Identification, and Taxon.
Based on the discussion of Oct/Nov, it was clear to us that each of
those is a distinct type of thing. From the standpoint of DSW, it is
"wrong" to type something as both a Location and an Occurrence, or a
Taxon and an Event. If one does, a reasoner should have a fit. That
is why we have taken care on the Wiki pages to define what we consider
each class to be and to support that reasoning with references to
either publications or discussion that took place on the list. As I
said in a previous email, the point of DWS is to provide clarity about
what an RDF file says, not to encourage creativity. <br>
<br>
You should note that Token is not included on the list of classes that
are mutually disjoint. Another point of discussion between Cam and I
was whether there actually should be a class called "Token". In the
end, we decided to include it with the understanding that it would
probably have at least two rdf:type's most of the time. There is
nothing wrong with that. A digital image can be a dsw:Token and also
be a mrtg:MultiMediaObject, dctype:StillImage, and foaf:Image if one
cares to assign it all of those types directly, or indirectly via
making it the object of a property that has such a range declaration
(such as foaf:depiction). A Token can also be an IndividualOrganism if
it's a living specimen. I consider typing something to be a message to
users which informs them of what kinds of properties to expect to find
out about it. If a resource is a Token, we would expect it to have the
kinds of properties that evidence has, such as dsw:isBasisForId aor
dsw:evidenceFor and maybe dwc:catalogNumber. If it is also a
dsw:IndividualOrganism, then we expect it to have properties like
dsw:hasIdentification and dsw:hasOccurrence but if it's a still image
then it should have properties like dcterms:creator and intellectual
rights properties. <br>
<br>
Perhaps we do deserve a scolding for doing this. But as I have said
earlier, the purpose of DSW is to facilitate clear and unambiguous
communication in RDF, primarily for people who want to combine metadata
from different institutions based on diverse kinds of tokens (preserved
specimens, images, living specimens, observations, tissue samples,
etc.). That really isn't possible if each institution has their own
personal idea of what something like an Occurrence is. People who have
other objectives may be best served by creating a different DwC-based
ontology that meets their own needs. <br>
<br>
Steve<br>
<br>
Mikel Egaña Aranguren wrote:
<blockquote cite="mid:4DBA857A.10102@fi.upm.es" type="cite">
<pre wrap="">Using a domain for a property will only be a problem if disjoints are
stated. Even more, someone else could add further domains to trigger
further rdfs:type inferences.
We should be careful, nonetheless, when using domains.
I'm saying this cause the word "constraint" does not quite represent
what a domain is, and we should avoid it, since it creates confusion on
OWL newcomers.
Very good point though.
On og., 2011.eko apiren 28a 22:14, Bob Morris wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I´ve been in Ecuador for two weeks with only a few hours of internet
contact. Flying from Quite tonight. So I´ve only scanned the Design
Document and may have done so too hastily. I´ll have more time next
week to look at it and the ontology. However, meanwhile, I´ve posted
the following unsurprizing comment there, and hope that anyone who
responds here will also respond there.
-----
It´s a little hard to understand why DSW object properteries should
have domains but data properties should not. Keep in mind that the
formal semantics of rdfs:domain is that if rdfs:domain P C then any
use a P x forces a to have rdfs:type C. This constrains the
extensibility of P and probably of the use of other ontologies where P
might be useful. Specifying domains tends to close the world somewhat,
and I see no advantage to that....Indeed, this is more naughty than
anti'naughty sensu Bob Morris.
-----
--Bob Morris
On Wed, Apr 27, 2011 at 9:01 PM, 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="">Dear colleagues,
With the exciting development of Semantic Web technologies, many of us already need a way to consistently express DwC in RDF. In particular, we need it to meet the requirements for GUID resolution (as expressed in the TDWG applicability guide) and to be able to share and aggregate diverse kinds of biodiversity metadata in the Linked Open Data world.
After several months of development, stimulated by the tdwg-content discussions of last Fall, we would like to offer an
ontology for consideration, based on Darwin Core terms:
Darwin-SW:
General site: <a class="moz-txt-link-freetext" href="http://code.google.com/p/darwin-sw/">http://code.google.com/p/darwin-sw/</a>
Using namespace dsw = <a class="moz-txt-link-rfc2396E" href="http://purl.org/dsw/">"http://purl.org/dsw/"</a>
It is a candidate for general usage, but we do not claim it is _the_ solution, and greatly respect the efforts by others to develop similar ontologies, from which we have learned much. However, for DSW, we wanted to use existing DwC terms for classes and data properties whenever possible and only create new terms when there were no existing terms that would do the job. We did feel that there was a need for clarity in how resources should be typed (i.e. rdf:type property) and for object properties that expressed the relationships among classes unambiguously. Please see the Rationale, DesignPrinciples and ClassesAndTypes wiki pages at the above address.
In the ontology, we sought to embody relationships among classes based on our perception of the community consensus of what the classes represent and how they are related to each other, as expressed in posts to the tdwg-content list. Thus each class is documented carefully on the wiki with hyperlinked references to specific tdwg-content posts. We also sought
to clarify or resolve issues that were raised in the list discussion, most notably the relationship among Occurrences and the evidence that documents them (i.e. tokens), and the role of "individuals". See wiki pages for the Token, Occurrence, and IndividualOrganism classes.
The ontology is now in use at <a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu/">http://bioimages.vanderbilt.edu/</a>, and we intend to use it more widely. We would value your opinions on the fitness of this ontology as a general solution for consistently expressing DwC concepts in RDF.
Sincerely,
Steve Baskauf and Cam Webb
<a class="moz-txt-link-abbreviated" href="mailto:steve.baskauf@Vanderbilt.Edu">steve.baskauf@Vanderbilt.Edu</a>
<a class="moz-txt-link-abbreviated" href="mailto:cwebb@oeb.harvard.edu">cwebb@oeb.harvard.edu</a>
_______________________________________________
tdwg-content mailing list
<a class="moz-txt-link-abbreviated" href="mailto:tdwg-content@lists.tdwg.org">tdwg-content@lists.tdwg.org</a>
<a class="moz-txt-link-freetext" href="http://lists.tdwg.org/mailman/listinfo/tdwg-content">http://lists.tdwg.org/mailman/listinfo/tdwg-content</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<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>