[tdwg-content] Add a Full Example: Re: Public comment on the Darwin Core RDF Guide

Sat Dec 13 16:54:12 CET 2014

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
<steve.baskauf at vanderbilt.edu> wrote:
> 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
> <steve.baskauf at vanderbilt.edu> 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] https://code.google.com/p/tdwg-rdf/wiki/DwcRdfOccurrences
> [2] https://code.google.com/p/tdwg-rdf/wiki/DwcRdfExamplesDarwinSW
>
> 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.
> http://bioimages.vanderbilt.edu
> http://vanderbilt.edu/trees
>
> _______________________________________________
> tdwg-content mailing list
> tdwg-content at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-content
>
>
>
>
>
> --
> 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.
> http://bioimages.vanderbilt.edu
> http://vanderbilt.edu/trees
>

-- 
Robert A. Morris

Emeritus Professor  of Computer Science
UMASS-Boston
100 Morrissey Blvd
Boston, MA 02125-3390

Filtered Push Project
Harvard University Herbaria
Harvard University

email: morris.bob at gmail.com
web: http://efg.cs.umb.edu/
web: http://wiki.filteredpush.org
       http://wiki.datakurator.net
       http://taxonconceptexplorer.org/
http://www.cs.umb.edu/~ram