[taxon-data-model] Re: [taxon-model] Re: Owl polymorphism

Michael Browne m.browne at auckland.ac.nz
Sun Jun 10 23:48:03 CEST 2007

Markus' comment that he would like to use TDM to exchange species
distribution data prompts me to comment that the invasive species data
standard (IASPS) aims to do exactly that. 

It includes a few elements that are specific to the needs of the invasive
species community such as BioStatus which is comprised of Origin, Presence,
Persistence, Distribution (i.e. Widespread, Moderate, Localized, Unknown),
Abundance, Trend, Rate of spread, Harmful, Regulatory listing, plus
ImpactStatus and DispersalStatus, but otherwise its purpose is to facilitate
the exchange of species distribution data.


-----Original Message-----
From: taxon-data-model-bounces at lists.tdwg.org
[mailto:taxon-data-model-bounces at lists.tdwg.org] On Behalf Of Roger Hyam
Sent: Monday, 14 May 2007 9:35 p.m.
To: Markus Döring
Cc: Bob Morris; taxon-model at lists.tdwg.org
Subject: [taxon-data-model] Re: [taxon-model] Re: Owl polymorphism


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,


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 at 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 at lists.tdwg.org
>>> http://lists.tdwg.org/mailman/listinfo/taxon-model

taxon-data-model mailing list
taxon-data-model at lists.tdwg.org

More information about the tdwg-content mailing list