[tdwg-tapir] Mapping to CNS file

Renato De Giovanni renato at cria.org.br
Mon Mar 12 03:54:35 CET 2007

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

> 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,

More information about the tdwg-tag mailing list