OK, I think I get what you are saying.
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.
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: https://code.google.com/p/tdwg-rdf/issues/detail?id=10
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.
Steve
Bob Morris wrote:
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@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@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@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