[tdwg-tapir] Mapping to CNS file

[Roger Hyam]

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



On 19 Mar 2007, at 18:34, Renato De Giovanni wrote:

> Hi Markus,
>
> The issue is that the configuration interface was developed in a way
> that it expects each conceptual schema to have its own individual
> address. Changing the interface can be a bit tricky, but I'm sure we
> can find some workaround. One way would be something similar to what
> you suggested: a CNS address with multiple schemas would make the
> configurator download them and display each one in the existing list
> of pre-defined schemas that can be selected by the user. Another way
> could be to include a fake parameter in the CNS address to specify
> the conceptual schema (this one doesn't look so nice but it somehow
> simulates a real service).
>
> Regards,
> --
> Renato
>
> On 19 Mar 2007 at 16:29, Markus Döring wrote:
>
>> Hi guys,
>> nice to see you are progressing!
>>
>> An important idea behind having multiple schemas inside a CNS is
>> that
>> it acts as a single entrypoint. Remember that we intended to replace
>> the CNS alias.txt file with a real webservice. Having only 1
>> entrypoint gives you one really big advantage. As soon as you update
>> this file, all providers are aware of this! In the case you want to
>> add a new CNS file, every service has to be reconfigured. Thats easy
>> to do, but someone has to do it and it will take a long time til it
>> spreads through our entire network. We could surely have another
>> registry of CNS files, but that sounds to me a bit over the top. Can
>> you explain to me again why having separate alias.txt files is
>> important for TapirLink? Couldnt you just read the entire file and
>> locally split it into cached separate alias.txt files?
>> --
>> Markus
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir