Hi Roger,
I'll try to answer your questions below...
How can we use such as CNS file to configure the configurators of the wrappers and is this desirable?
For TapirLink, as you already know it will first be necessary to write a CNS handler to load concepts in this format. PyWrapper can deal with CNS.
I believe the current configurators assume that the full name of the concepts is resolvable to the documentation for the concept. The concept paths generated form the ontology are not resolvable in this way. I could write a script that generated a documentation page when it was passed one of these paths. Would this be a reasonable thing to do?
There's a recommendation that concepts should try to be globally unique and also resolvable to something that helps understanding what they are. But this should not be assumed.
In TapirLink it's up to the conceptual schema handler implementation to know how to get documentation or not. The Darwin schema handler stores a link to documentation only if it finds a xs:annotation/xs:documentation/@source node inside the concept definition. A generic CNS handler could probably try to check if the concept identifier is resolvable, and in this case store the identifier itself as a link to documentation.
There are lots of concepts in this file (138) and it will get a lot bigger when I add in the general properties. We really need a way of organizing the mapping process into a hierarchy browsing process. Could we have a pre-mapping phase where someone browses the ontology and creates a list of concepts that they want to map. They could then use this much shorter list in the configurator. Would this be more productive? I have started mocking something up along these lines but will abandon it if there is another way forward.
I don't know if PyWrapper already has some kind of hierarchical mapping facility. In the case of TapirLink, you need to know that the original design was to work with simple DarwinCore-like schemas (one or more flat schema), and also to work with "almost" tabular data behind the scenes. So before trying to implement such hierarchical mapping in TapirLink, it would be important to know if it really makes sense to have underlying tabular data being mapped to complex data models.
Anyway, even providers with tabular data could make use of an ontology browser to select the concepts that they want to provide. I'm thinking about how this could be used by TapirLink...
Perhaps the ontology browser could be a separate application that in the end would generate a link to a conceptual schema (in some specific format) whose concepts could then be loaded by a corresponding handler in the configurator.
I was thinking of writing a script to automate the production of output model structures in much the same way as creating the CNS but I ran into an interesting problem with preventing recursion. ... What do you think?
I'm not sure I understood the problem - it's late here too... :-)
I would ask you a more basic question first: are you sure you need to automate response structure creation from parts of the ontology? What kind of structures do you have in mind? RDF stuff for LSID resolution?
One different thing that would be intersting - especially considering the amount of time that it took to build output models during the workshop - is an output model designer application. It would receive as an input a response structure and one or more conceptual schemas. The application would parse the response structure and display an interface to map all nodes against the concepts. But I realize that in this case the response structure would be an input, not an output as you want.
Best Regards, -- Renato