Markus,
I agree but...
TDWG does have a "Plant Occurrence and Status Scheme" though it isn't linked to from the existing site it soon will be and perhaps we should have a RDF/OWL version of it for backwards compatibility if nothing else. I was just looking at it as I am trying to map a database that uses the codes it contains along with codes from other of the older schemas.
In the main exchange ontology we should restrict as little as possible. If some one want to define another ontology that does restrict the values and is used together with the main ontology then they can. If the additional, restricting ontology is useful then it can be standardized.
If the main exchange ontology is more strongly typed then we have to loosen it up later which I believe is harder and will prevent the flow of data.
To use a cowboy analogy. If we are going to lasso a cow we should start with a loose loop of rope and then tighten it. If start with a tight loop we will never get it over the cows head.
A classic example of this is the 'year' field in TCS. It should contain a year so we restricted it to being a gYear but we received strong feedback saying "We want to use TCS but can't because we want to put a range of years or a measure of uncertainty in that field". It would have been better if we had not restricted that year field so that more people could use the standard as a whole.
Hope this helps,
Roger
On 11 May 2007, at 15:47, Markus Döring wrote:
Im not sure why we are talking about inheritance.
My primary goal is to see how useful TDM is for data exchange and integration. I am very interested for example to use TDM to exchange species distribution data. If every application defines its own occurence status terminology noone would be able to merge datasets. So I was hoping TDWG would at least define a default standard for those kind of things. I am aware that some communities will use a different standard, but if they want to be interoperable with the outside world how can you see this happen if we dont define a common terminology? Reason over hundreds of SameAs statements? It would be nice to have at least a standard "backbone" where you can relate your terminology against.
And if we agree that this is needed, why not have a strongly typed property for the respective InfoItem classes that only allows terms of the recommended terminology? But maybe I misinterpreted the purpose of TDM and/or are still too heavily influenced by xml schema ;)
cheers
Markus
On 11.05.2007, at 13:56, Bob Morris wrote:
Alas, for some of the intended audiences, there are requirements of practice, or even of law, to use particular controlled vocabularies. Often, there are several in wide use. This is especially true in the invasive species community, but also, I believe, for many agriculture, public health and other communities.
My inclination is to share Roger's concern about an inheritance tree adding complexity that might add to the complexity of either application building or adoption. (I can't believe I'm agreeing with Roger in this domain... :-) ). Unfortunately, my intuition is that two related problems will quickly arise:
(a). The inexperience, and a small stake in the outcome, of the various communities will quickly lead to an undisciplined inheritance tree in which most people derive from the base, not from other derivations. This in turn makes effective and easily extended polymorphic application programming difficult or impossible to put in place. If the utility of polymorphic programming is compromised, there seems small point accepting the maintenance hit of polymorphic ontology. It's a little like the difference between tags and property lists. You can go an awfully long way with the former even though they just float by like clouds.
(b)For similar reasons to (a), even when disciplined extension lineages emerge, there will be rooted at them further undisciplined derivations as above, and that these will lead to \semantic/ multipaths through the inheritance trees as people map undisciplined leaf nodes in one branch to those in another.
For a number of the TDMTerm categories there are already multiple well established controlled vocabularies. Many of the relevant subcommunities are communities of practice, not of theory, and feel more constrained to "get on with it" about their work than to make sure it is easily related to the vocabularies of other subcommunities much less apparently unrelated communities. I believe this is especially true where ecology, public policy, commercial or health data are in play. It is a little regrettable that the list and wiki name got abbreviated from Taxon Data Model to Taxon Model. The latter might give taxonomists the mistaken (I hope) view that TDM is about a theory of what a Taxon is.
On 5/11/07, Markus Döring m.doering@bgbm.org wrote:
Roger, this was not targeted directly at TDM. I was mainly exploring OWL and definitely not suggesting multiple inheritance!
But in regards to TDM I was thinking about the consequences of allowing any defined term as a "controlled" value for InfoItems.hasValue. Is this desired? Having individual classes for the InfoItem categories now would allow us to define a specific controlled vocabulary for each category - or None if we dont think this is a good idea. These vocabularies, like CyclicityTerm, can easily be extended by anyone who really needs to. And all InfoItems are allowed to contain uncontrolled values via the hasContent property in any case. -- Markus
On 11.05.2007, at 11:30, Roger Hyam wrote:
Hi Markus,
Sounds like interesting and complex stuff and exactly what I am trying to avoid ;)
If this is for exchange standards we want to keep things as simple as possible. We also need our ontology to entail as little as possible so people can understand it and (if they are up on the technology) import it into their own business ontologies.
The role of the exchange ontology is to denote the meaning of simple fields it is not to enable connotations but to avoid them.
This is why I was sticking to simple properties with domains and ranges. Really just one up from RDFS. If it is important for a consumer to assert a hierarchy of properties then they can do that in their own ontology and import it. Who is to say that all consumers will have the same notion of that hierarchy and what is the business case for trying to impose one at this point?
If there were polymorphism of properties (overriding them in sub classes) then it would get confusing because of the multiple inheritance. I am not sure what would happen to meaning with the diamond problem - where the same property is inherited via several routes but has it's meaning changed differently on each route. It is always possible to subclass the property though and it may be possible to forbid the use of the parent property in a class - perhaps - but this is getting beyond my reading level.
Not sure if this helps,
All the best,
Roger
On 11 May 2007, at 09:54, Markus Döring wrote:
Roger, is it possible with OWL to have polymorph class properties? As properties are global and only bound to classes via range/ domain it doesnt seem to be possible to me, but maybe Im wrong. Can I redefine a propertys range depending upon the class it belongs to, so its domain? Well, that would mean to declare the same property twice with different domains and ranges. Probably impossible. It is different from classic OO thinking... -- Markus
taxon-model mailing list taxon-model@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/taxon-model