Hi Renato,
On 13 Mar 2007, at 20:17, Renato De Giovanni wrote:
I'm curious to see how you're handling a CNS with multiple conceptual schemas. It may be interesting to allow users to choose which ones they want to map, but I'm not sure what would be the best way to do this. And it will also be necessary to include a new combo beside the field "additional schema to load" to specify a handler.
I am probably cheating here by treating a single CNS as a conceptual schema. I create a CNS from a view onto the ontology. As an example all the paths into the ontology from the TaxonConcept class (but preventing or limiting recursions).
This seems to be the way to do it from the point of view of the ontology. A CNS file with 200+ concepts in is generated from the OccurrenceRecord view of the ontology alone. If we merged this with CNS files of similar sizes for the other basic types we would end up with a CNS containing 1000s of concepts which would not be practical to present to the user.
Does this break anything in the ideas behind a TAPIR network? It is not likely to lead to a bad multiplication of CNS files as there are only likely to be around 10 maximum for the ontology. What do you think?
The alternative, as you say, is to change the interface and allow the user to choose between different [concept_source] blocks in one big file. I am not sure of the advantages of this though. Because of the nature of the CNS files I guess one could concatenate them together to get a single CNS for the whole ontology if needed.
I am not totally happy with presenting the user even with 100's of things to map. It would make my heart sink to see such a list. I am looking at ways to improve the documentation and try and target the most "important" or most needed properties to map first. This is the same problem that is faced by the ABCD guys I guess. I don't rule out UI changes to help solve this but may be able to do it with just carefully ordering of concepts. Ideas and suggestions would be welcome.
All the best,
Roger