I'm generally sympathetic to this approach except for c) and not only because of my familiar whine that mindlessly putting domains on predicates constrains extensibility to no salutary effect other than to constrain extensibility. That being a stated goal of Steve and Cam, a more important issue might be that the tdwg ontologies in their present form have an ambiguous future. To my knowledge, the TDWG adoption process has never even been begun for them, and indeed http://code.google.com/p/tdwg-ontology/ seems to have been dormant since December 2009, and the earlier (2007!) http://rs.tdwg.org/ontology/voc/TaxonConcept seems to carry a warning that the google site is more authoritative. IMO, one may consider the vocabulary at least socially, if not actually deprecated. Steve raised this issue in the earlier post in this subject.
So the question remains: what advantage of subclassing tc:TaxonConcept accrues to users of the specification? If there is actually data coded to tc:TaxonConcept, then applications that wish to integrate with such data, e.g. LOD apps, can make the subclass declaration as part of the application, and integration with what, if anything, replaces tc:TaxonConcept will not be impeded.
Bob Morris
On Sun, May 8, 2011 at 9:34 PM, Paul Murray pmurray@anbg.gov.au wrote:
[snip]
So, I'd suggest the safe way to go would be
a) yes, import the tdwg classes by all means b) declare your classes to be subclasses of the tdwg ones c) declare that your predicates have a domain/range of the TDWG classes
(An *even safer* way to go is to create a completely generic "TaxonThingy" superclass and to declare (in your vocabulary) that tdwg_Taxon is a subclass of that ... but this is so safe that it doesn't accomplish anything useful. You may as well not have range and domain declarations at all.)
tdwg-content mailing list tdwg-content@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content