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

Mon Jun 11 11:46:10 CEST 2007

Michael,
you are right that IASPS is covering pretty much the same domain.  
TDWG really does need more integration of the multitude of  
"standards" that have been produced, though most of them are rarely  
seen in production. This is why I am hoping for the TDWG lsid  
vocabularies which so far have been under tight control by Roger and  
are integrating a diverse mix of data types. The SpeciesProfileModel  
serves the purpose for our distribution data while at the same time  
being integrated with other standards, most importantly TCS, through  
the ontology. Maybe we should think of bringing IASPS into the ontology?

--
Markus

On 10.06.2007, at 23:48, Michael Browne wrote:

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