[taxon-model] Re: [tdwg-tag] Re: TDM Ontology
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
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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/taxon-model
Hi, 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:labelTaxon Biology Info Item</rdfs:label> dc:titleTaxon Biology</dc:title> base:definitionAn account of the biology of the taxon.</ base:definition> <rdfs:subClassOf rdf:resource="http://rs.tdwg.org/ontology/voc/ TaxonDataModel#InfoItem"/> <rdfs:isDefinedBy rdf:resource="http://rs.tdwg.org/ontology/ voc/TaxonDataModel"/> </owl:Class>
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 -- Markus
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@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/taxon-model
taxon-model mailing list taxon-model@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/taxon-model
Markus Döring wrote:
Btw, is there any online validator anyone would recommend to validate our ontologies?
Try the W3C RDF Validation Service at http://www.w3.org/RDF/Validator/
Cheers,
Ricardo
Better(?) is Mindswap's Pellet Owl Consistency Checker http://www.mindswap.org/2003/pellet/demo.shtml
If I am not misusing it, I believe that so far TDM requires OWL Full, but it looks like maybe trivial adjustments are necessary to make it DL.
May a plague rain down on the Open World Assumption. It provides misplaced comfort to OWL newbies like me. The Mindswap tool seems to add some medicine to cure my OWL sneezing.
Bob
Ricardo Pereira wrote:
Markus Döring wrote:
Btw, is there any online validator anyone would recommend to validate our ontologies?
Try the W3C RDF Validation Service at http://www.w3.org/RDF/Validator/
Cheers,
Ricardo
taxon-model mailing list taxon-model@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/taxon-model
participants (5)
-
Bob Morris -
Markus Döring -
Renato De Giovanni -
Ricardo Pereira -
Roger Hyam