[tdwg-tapir] Mapping to CNS file

Markus Döring m.doering at bgbm.org
Wed Mar 28 12:09:20 CEST 2007 

Roger,
a nice simple diagram. thats good to have, great!

The simple temporary text format decision was pretty much mine cause  
I had an easy parser for it and its very readable and therefore  
manageable.
If it looks as if we are going to stay with it for a while I dont  
really mind to use some other RDF or XML format. Would this ease the  
development of the TapirLink configurator? It would mean some  
recoding of pywrapper and rogers scripts, but I guess that's still a  
rather small amount of work.

sorry for being lazy lately
--
Markus



On 22.03.2007, at 21:26, Roger Hyam wrote:

> Hi Dave and all,
>
> I actually meant more like:
>
> http://somehost/somepath/alias.txt#some_concept_source
>
> where it is identifying a complete section of a CNS file containing  
> many TAPIR concepts.
>
> My understanding of the whole RDF + CNS + TAPIR Concepts +  output  
> model is like a thunking layer to get from RDF to simple XML and  
> back again.
>
> There is a pretty picture here: http://wiki.tdwg.org/twiki/bin/view/ 
> TAG
>
> At the moment I have a script that takes a view on the ontology  
> that is defined in OWL and creates two things: A TAPIR output model  
> and a CNS file that lists the concepts in the output model (paths  
> through the ontology following the ObjectProperty relationships -  
> not the subclassing relationships). It creates the big schemas that  
> are reminiscent of ABCD but that map on to the ontology and RDF.  
> (It also creates some documentation).
>
> I am actually working on the output model not using namespaces but  
> only element naming conventions (e.g.  rdf_RDF == rdf:RDF)  A  
> simple XSLT then turns the resulting instance documents into real  
> RDF with all the namespaces and stuff correctly in place. A couple  
> of regular expressions would do the same job.
>
> It sounds like a bit of a hack but as the XML Schemas and instance  
> documents are really only used as part of the TAPIR configuration  
> and protocol layer I feel it is justified.  It gets around loads of  
> problems like recursion of XSD complexTypes, confusion over imports  
> of different complexTypes that represent the same object and having  
> numerous schema imports to cope with the different namespaces.
>
> I want to get the whole of this working and demo'd and then I'll  
> put a wiki page together on it.
>
> So the concepts exist in RDF/OWL already we are just discussing a  
> representation of them to map into TAPIR networks.
>
> It should be possible for TAPIR providers to appear like semantic  
> web applications - but not SPARQL servers.
>
> All the best,
>
> Roger
>
>
> On 22 Mar 2007, at 18:07, Dave Vieglais wrote:
>
>> Hi Renato,
>>
>> I suspect Roger was thinking more along the lines of:
>>
>> http://somehost/somepath/schema#someconcept
>>
>> At least that's what I read from "fragment identifier".
>>
>> On an aside, kind of, can someone elaborate on the decision to use  
>> a CNS file format (as described in the 1.0 spec) that is not in  
>> some form of xml, preferably RDF?
>>
>> thanks,
>>   Dave V.
>>
>> On Mar 22, 2007, at 12:28, Renato De Giovanni wrote:
>>
>>> 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
>>>
>>> _______________________________________________
>>> tdwg-tapir mailing list
>>> tdwg-tapir at lists.tdwg.org
>>> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
>>
>> _______________________________________________
>> tdwg-tapir mailing list
>> tdwg-tapir at lists.tdwg.org
>> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
>
> _______________________________________________
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
> http://lists.tdwg.org/mailman/listinfo/tdwg-tapir

More information about the tdwg-tag mailing list