<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
OK, I think I get what you are saying.  <br>
<br>
Just to clarify, in general, the basic Darwin Core vocabulary includes
very few machine-interpretable semantics (domain, range, subclass,
subproperty, sameAs).  I think that the subproperty declarations for
the "ID" terms are just about all that is left.  The RDF Guide
similarly remains silent on these kinds of relationships, except where
they exist in "adopted" terms from Dublin Core.  The guide really just
attempts to frame known best-practices in terms of how they would apply
to the DwC vocabulary, and to deal with the quirks that have been
introduced by DwC originally being designed to facilitate spreadsheets
and flat database tables.  <br>
<br>
My feeling was that there was a consensus that once the basic layer
(the vocabulary itself) was cleaned up with clearer definitions and the
guide (a second layer) was in place to apply well-known best practices
to that layer, there would be a subsequent attempt to determine how
these two "layers" could be used by higher level layers (i.e.
ontologies) to generate actual usable RDF graphs.  This determination
would be based primarily on use cases and how successful various
possible approaches would be at facilitating those use cases.  So the
question of whether there are valid reasons why ontologies should
impose rdfs:domain properties should be part of that next discussion,
and on the level of the RDF Task Group rather than the whole
tdwg-content list.  We already have this as an open issue in the RDF
Task Group issue tracker:
<a class="moz-txt-link-freetext" href="https://code.google.com/p/tdwg-rdf/issues/detail?id=10">https://code.google.com/p/tdwg-rdf/issues/detail?id=10</a><br>
<br>
So I think this is an important issue, but I think it's veering out of
scope for the discussion about the guide.  Returning to the original
question of examples, my feeling is that it just isn't practical to
include what are likely to be highly mutable examples in what's going
to become a non-normative part of the standard.  As you suggested in a
later email, I think having back links from the examples on GitHub to
particular sections of the guide would be the way to go.  <br>
<br>
Steve<br>
<br>
Bob Morris wrote:
<blockquote
 cite="mid:CADUi7O49tJppk-3GvqpfKxrBf1ZH5V6=sMwfv-Dbo90SRy3gQg@mail.gmail.com"
 type="cite">
  <pre wrap="">Sorry if what I wrote was either irrelevant or unclear, or both. My
intent was to say this:  You gave examples where there have been
ongoing arguments in favor of  two answers to a question of the form
"to what class should a predicate P be applied."  But in my view there
is often no reason to settle that question in a guidance document or
spec, perhaps unless the intent is to settle the arguments. To me,
your discussion of dwc:EventDate  seems like an example of such, at
least because there have been arguments on the table that have not(?)
been successfully contradicted. The point I too cryptically mean to
raise is: it is a common problem that such arguments are, in the case
of rdfs reasoning, often settled de-facto when ontologies impose
rdfs:domain. Settling an extensive argument in an ontology should not
be taken lightly, if for no other reason than that forestalling
arguments is one of the main accomplishments of a well-crafted
ontology.

Hope that is clearer.  If so, it doesn't bother me if it is declared irrelevant.
Bob

On Sat, Dec 13, 2014 at 7:49 AM, Steve Baskauf
<a class="moz-txt-link-rfc2396E" href="mailto:steve.baskauf@vanderbilt.edu">&lt;steve.baskauf@vanderbilt.edu&gt;</a> wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Umm.  I don't understand why what you said is relevant. Nobody that I know
of has assigned domains to any of the existing Darwin Core terms.  If you
have Darwin-SW in mind, it only assigns domains to object properties that it
mints and I don't see how that would prevent supporting either or both kinds
of use.  The problem in my mind is figuring out how to do queries that would
catch both kinds of uses, e.g.

SELECT ?Occurrence WHERE {
  ?Occurrence dwc:eventDate "2014-12-13"^^xsd:date.
  ?Occurrence dwc:locality "Smith Pond".
  }

which would work for the simple version, but not Darwin-SW.  Obviously, one
could easily create a more complex query that would work in simple cases
like this example, but the complexity would expand greatly if one wanted to
require matches with 3 or more patterns.
Steve


Bob Morris wrote:

Ah, Steve, your examples well illustrate the reason to avoid assigning
rdfs:domain, as well as why both are perfectly good illustrations
neither of which should be deprecated.  Communities of practice can
exploit either or both, and the only communities that are nailed are
those that labor under an rdfs:domain for such things as dwc:EventDate

Bob

On Fri, Dec 12, 2014 at 10:59 PM, Steve Baskauf
<a class="moz-txt-link-rfc2396E" href="mailto:steve.baskauf@vanderbilt.edu">&lt;steve.baskauf@vanderbilt.edu&gt;</a> wrote:


Paul,
That's exciting that you are trying to generate RDF using real data!

I think we initially considered including something in the guide like
what you have suggested, but the problem is that what constitutes "an
Occurrence record" varies depending on the model one has in mind when
serializing the record as RDF.  Historically, "occurrences" were
considered to be a superclass that included specimens, and any property
remotely related to a specimen could be included as part of an
occurrence record.  A provider exposing an occurrence record might give
it properties such as dwc:eventDate, dwc:preparations, and
dwc:locality.  However, a different provider might consider
dwc:eventDate to be the property of a dwc:Event instance,
dwc:preparations to be the property of a dwc:PreservedSpecimen, and
dwc:locality to be the property of a dcterms:Location instance and link
those instances to a separate Occurrence instance via object properties.

Which of these is correct?  At this point there is no consensus as to
whether one of these approaches is better than the other.  We avoided
putting extensive examples within the guide document itself, since the
guide will become part of the standard and will probably not be changed
frequently, whereas best practices for deciding the types of resources
with which properties should be associated is likely to develop over
time and with the experience of usage.  For that reason, we have
included examples in the ancillary documents that are associated with
the guide, but which do not form part of the standard.  The "examples
using 'pure' Darwin Core" [1] and "Examples using Darwin-SW object
properties" [2] illustrate the extremes that I've described above.

Steve

[1] <a class="moz-txt-link-freetext" href="https://code.google.com/p/tdwg-rdf/wiki/DwcRdfOccurrences">https://code.google.com/p/tdwg-rdf/wiki/DwcRdfOccurrences</a>
[2] <a class="moz-txt-link-freetext" href="https://code.google.com/p/tdwg-rdf/wiki/DwcRdfExamplesDarwinSW">https://code.google.com/p/tdwg-rdf/wiki/DwcRdfExamplesDarwinSW</a>

Paul J. Morris wrote:


As I've been working through implementing RDF generation in a few
applications and seeking to conform to the guide, I've found myself
spending a good bit of time hunting through the document looking for
guidance on particular situations, this leads me to a suggestion for
the guide: Include, at the end of the guide, a single comprehensive
example of an Occurrence record, annotated to point to relevant
sections in the guide.  This could serve both to quickly answer
questions and as a visual index to the rest of the guide.

-Paul



--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences

postal mail address:
PMB 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) 322-4942
If you fax, please phone or email so that I will know to look for it.
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://vanderbilt.edu/trees">http://vanderbilt.edu/trees</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>





--
Steven J. Baskauf, Ph.D., Senior Lecturer
Vanderbilt University Dept. of Biological Sciences

postal mail address:
PMB 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) 322-4942
If you fax, please phone or email so that I will know to look for it.
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://vanderbilt.edu/trees">http://vanderbilt.edu/trees</a>

    </pre>
  </blockquote>
  <pre wrap=""><!---->


  </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:
PMB 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) 322-4942
If you fax, please phone or email so that I will know to look for it.
<a class="moz-txt-link-freetext" href="http://bioimages.vanderbilt.edu">http://bioimages.vanderbilt.edu</a>
<a class="moz-txt-link-freetext" href="http://vanderbilt.edu/trees">http://vanderbilt.edu/trees</a>

</pre>
</body>
</html>