On 06/05/2011, at 8:59 PM, Steve Baskauf wrote:
However, we went beyond that in the Taxon class. We declared that dwc:Taxon was equivalent to tc:Taxon (Taxon in the TDWG ontology, which is declared within the TDWG ontology to be the same thing as tc:TaxonConcept). Our motivation was to try to add some clarity to what exactly the dwc:Taxon class was (that wasn't exactly clear to us) and also to avoid having to try to describe the properties of the Taxon class since they were already described (to some extent) within the TDWG ontology.
I believe it is the case that if you declare two classes to be equivalent, then any restrictions migrate across both ways.
Hang on ... I'll write myself a little test case in protege. I declare tdwg and dwc Name and Taxon classes, and declare that the dwc Name and Taxon class are different to each other
(NB: I don't mean to imply that this actually is the case in DwC)
and equivalent to the respective tdwg classes - that in DwC, a name is not a taxon is not a name. When we do something that is ok in the tdwg space - declare that some individual is both a name and a taxon, then the HermiT reasoner straight away complains that the ontology is inconsistent.
If you have received this transmission in error please notify us immediately by return e-mail and delete all copies. If this e-mail or any attachments have been sent to you in error, that error does not constitute waiver of any confidentiality, privilege or copyright in respect of information in the e-mail or attachments.
Please consider the environment before printing this email.
If you say that dwc_Taxon "is equivalent to" tdwg_Taxon, then you are saying that anything you say about the one also applies to the other. The consequence of this is that you might not be able to pull in certain sets of data from hetrogenous sources. Bill's dataset may be a bit woolly about the Name/Taxon distinction, Bob's may use DwC and be quite strict. If the DwC vocabulary includes an equivalence, then if anything anywhere declares this disjoint relationship, the whole lot is inconsistent. If Bill's data contains information about genetics and Bob's contains data about distribution and you want to combine them .... you are out of luck.
One way to manage this situation is as I suggested: by rigging things up so that a user can select sets of inference rules that work together without having them automatically dragged in by the imports - by making just the declarations without any other rules available separately. This is more useful than it might appear, as those declarations will include any annotations that you want to put on your items: descriptions, labels and whatnot.
The alternative is to declare that a dwc_Taxon is a subclass of a tdwg_Taxon. Formally: if something is a dwc_Taxon then that means it is also a tdwg_Taxon. This makes the ontology consistent:
The price of this, however, is that everywhere you use Taxon, you have to decide which you mean, most particularly on range and domain declarations. If you define a DwC predicate that has a domain of dwc_Taxon (ie: it only applies to taxa that are DwC taxa), then if it is applied to anything then we infer that the thing that it is applied to is a DwC taxon. But heck ... if there's a DwC term that applies to "a taxon" (hasDwCDistributionitems), wouldn't it happily apply to things that are tdwg taxon objects, too? Sure it would! Mostly.
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.)