[taxon-model] Re: [tdwg-tag] Re: TDM Ontology

Markus Döring m.doering at bgbm.org
Thu May 10 18:59:37 CEST 2007

I volunteer and have just updated the ontology. Every TDMTerm  
instance now is a class like that one here:

    <owl:Class rdf:ID="TaxonBiology">
       <rdfs:label>Taxon Biology Info Item</rdfs:label>
       <dc:title>Taxon Biology</dc:title>
       <base:definition>An account of the biology of the taxon.</ 
       <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/voc/ 
       <rdfs:isDefinedBy rdf:resource="http://rs.tdwg.org/ontology/ 

Roger, could you check if I didnt do any stupid move?
Btw, is there any online validator anyone would recommend to validate  
our ontologies?

best wishes

On 09.05.2007, at 10:37, Roger Hyam wrote:

> Hi Renato,
> There was something bothering me about this discussion and it just  
> occurred to me what it was...
> It really doesn't matter whether we go down the route of  
> subclassing InfoItems. From the point of view of the ontology  
> perhaps this is a place where we should do it.
> People working in pure semantic web way should be able to work out  
> that anything that subclasses InfoItem is an info item.
> People working in pure XML will prefer to have separately named  
> elements to use.
> People who want to produce serializations of RDF type data that  
> look like tagged InfoItems can just use the rdfs:type property to  
> tag their InfoItem instances.
> So I am converted! In this case lets have subclasses of InfoItem.
> We just need some one to volunteer to update the vocabulary files -  
> or they will get put on the end of my do-list.
> All the best,
> Roger
> On 8 May 2007, at 21:25, Renato De Giovanni wrote:
>> Hi Roger,
>> I'm not sure I share this vision of a "law of conservation of pain".
>> It's true that one of the points in the other message was to ease the
>> process of sharing data, but this doesn't mean that clients will
>> necessarily have trouble (I hope not!).
>>> From the TAPIR perspective, we handle extensibility by allowing
>> providers to work with multiple conceptual schemas. If you produce a
>> list of concepts from the TDM terms, anyone is free to produce other
>> complementary lists in the future, without breaking compatibility.
>> You know that in TAPIR it's also possible to produce outputs in
>> different XML formats, even RDF. This should facilitate the work of
>> clients.
>> I suppose that clients will usually request data in formats that
>> include elements that they know something about. But anyway, nothing
>> prevents them to request things that they don't have any knowledge
>> about. The TapirLink browser that I demonstrated during the TAPIR
>> workshop is one of those clients: it dynamically builds an output
>> model based on what the provider declared to have, and it simply
>> displays this data in a tabular form.
>> Now let's assume that we decide to work with a generic conceptual
>> schema with two main concepts, category of InfoItem and InfoItem
>> value. Let's also assume that providers will be able to easily share
>> their data according to this conceptual model. In TAPIR, the output
>> formats will be very limited - they will need to follow this generic
>> approach. But let's suppose that this will not be a problem.
>> What is going to happen is that clients will get amost anything from
>> there - basically values of things that can be categorised in many
>> ways. If clients want to perform validation they will need to do it
>> themselves (the output format will be too generic, so we cannot use
>> XML validation). Perhaps RDF validation will offer more
>> possibilities, but then you're only considering data exchange in an
>> RDF world. The meaning of InfoItems you would get from a dictionary
>> of categories, in the same way that you could get the meaning of
>> elements from a dictionary (DarwinCore for instance, or some
>> ontology).
>> In this case, it's not clear to me what would be the big benefits of
>> using the generic model approach, but maybe I'm missing something.
>> The more knowledge you have about the elements or concepts, the more
>> interesting and powerful the applications will be. It's a
>> philosophical issue.
>> If we decide to avoid the more "traditional" way of structuring and
>> modelling data because we feel it somehow limits our applications,
>> then I think we first need to clearly understand what are these
>> limitations. Otherwise, by doing things in a very different way we
>> may miss the opportunity of using existing tools and resources - but
>> still running the risk of facing again in a different road the same
>> data structuring issues that we tried to avoid.
>> Best Wishes,
>> --
>> Renato
>> PS: I'm sorry for crossposting. I'll send any follow-ups only to the
>> new taxon-model mailing list:
>> http://lists.tdwg.org/mailman/listinfo/taxon-model
>> On 8 May 2007 at 9:35, Roger Hyam wrote:
>>> Renato,
>>> Thanks for your comments. That is an interesting view of the problem
>>> and I think you may be  correct for the supplier databases (though I
>>> don't have first hand knowledge of these database schemas).  
>>> Generally
>>> the nearer the exchange format is to the supplier's schema the  
>>> easier
>>> it will be for them to publish. Taking the approach Markus suggests
>>> would produce the result you are after I believe.
>>> There is just one problem that you didn't address.
>>> Who wants to consume the data and what do they want to do with it?
>>> To have something that is easy to produce, easy to consume and easy
>>> to extend is more or less impossible. There has to be some pain
>>> somewhere!
>>> What is your vision of a client application? How would it handle
>>> elements it hadn't seen before - or is this not a requirement?
>>> All the best,
>>> Roger
>> _______________________________________________
>> taxon-model mailing list
>> taxon-model at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/taxon-model
> _______________________________________________
> taxon-model mailing list
> taxon-model at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/taxon-model

More information about the tdwg-content mailing list