[taxon-model] Re: [tdwg-tag] Re: TDM Ontology
roger at tdwg.org
Wed May 9 10:37:50 CEST 2007
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,
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
> 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
> 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,
> PS: I'm sorry for crossposting. I'll send any follow-ups only to the
> new taxon-model mailing list:
> On 8 May 2007 at 9:35, Roger Hyam wrote:
>> 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
>> 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,
> taxon-model mailing list
> taxon-model at lists.tdwg.org
More information about the tdwg-content