Hi Roger,
Can you give an example of the URI using a fragment identifier for a concept source? Are you thinking about something like this:
http://somehost/somepath?cs=darwincore1.4
It will probably be the simplest solution now. The configuration interface (and the CNS handler) can be changed later to support URIs that don't specify a conceptual schema.
Best Regards, -- Renato
On 22 Mar 2007 at 14:23, Roger Hyam wrote:
I am trying to get my head round this and figure out if it matters or not.
When some one is running a configurator on a wrapper they need to pick sets of concepts (concept_source) that they will map for a particular endpoint.
The configurator needs to get these sets of concepts from somewhere that is managed centrally for any one thematic network so that it can be kept up to date.
The configurator will probably know about some sets of concepts when it is installed but the user needs to be able to specify other sets.
In the case of the set of concepts being contained in an XML Schema there is a 1:1 relationship between the set and a URI.
In the case of the set of concepts being contained in a CNS file (as currently specified) there is potentially a one to many relationship where the URI may refer to many sets of concepts in a single file unless we adopt a convention of using a fragment identifier in the URI to specify a particular concept_source within the CNS.
The advantage to having multiple concept_sources in a single CNS is that the wrapper can be distributed with the URI of a CNS that can subsequently contain new concept_sources that weren't known about previously.
I suspect that (although it would be good to have a system where the configurators lead people through choosing which concept_sources they might want to map things against) it is actually much easier just to have a web page that describes them and gives the URI to enter into the configurator.
My preference at the moment is to adopt the convention of using the fragment identifier to point out which concept_source within a CNS is used. The URI fragment == alias of the concept_source. This keeps the 1:1 mapping of URI to concept_source and the implementation simple. The wrapper can simply not support CNS mapping where the fragment isn't specified or it can load the whole CNS and ask the user to pick which concept_source they want to use.
A possibility for the TAPIRLink implemenation is to have the schemas.xml file loaded from a central location.
From the ontology point of view it makes sense to have a URI for each main object types that returns the CNS for that view onto the ontology - so I guess that is the reason I did it that way. I could always put together a uri that returned a concatenation of the CNS files for all the different entry points for the ontology if that was useful.
What do you think?
Roger