Re: Ontology modules and namespaces

Since TopBraid Composer [1] was criticized here, please allow me  
explain that it can very well be used in the scenario below. I will  
let the people on this list decide whether it behaves well or not. The  
mechanism it uses has been stable for the last three years, and I  
think it has worked quite well so far.

If users are editing files from their hard drive, TBC will associate  
each file with a base URI. This base URI is later used to resolve  
owl:imports, so that the system can figure out whether it has local  
copies of web resources without going to the web. The base URI is  
retrieved from the files by looking into the first few lines - if it's  
an RDF/XML file then it uses the declared xml:base, for N3/Turtle  
files it uses the URI of the first owl:Ontology, or a base URI comment  
in the head, etc. In any case, some base URI is needed to make files  
importable. If multiple files have the same base URI then the system  
allows users to pick a "primary" file to resolve conflicts. But this  
case is rare and can be easily worked around.

It is perfectly valid in TopBraid to split a namespace across multiple  
files, and thus edit different snippets. As long as all snippets are  
somehow distinguished with unique base URIs (maybe http://example.org/project/snippet1 
, snippet2 etc) then it's possible to open them in isolation or have a  
master file that imports them all. A simple union graph export  
(possible via SPARQLMotion) can then be used to merge the various  
smaller files, or, in the other direction, to split an existing large  
file into multiple snippets. TopBraid makes a clear distinction  
between the base URI and the unrelated concepts of default namespaces  
and other namespaces. This means that all smaller files may contain  
instances from multiple namespaces, or the same namespace. Editing  
them in TopBraid is no problem, as long as you are aware of how the  
system maintains its file-to-base URI mapping. I am more than happy to  
discuss this further, but as this might be off-topic I suggest moving  
to the TopBraid Composer mailing list [2].

By the way, the idea of using different base URIs (owl:imports  
locations) for serving resources from other namespaces has been  
implemented in the RDFex service [3], which can be used to import only  
selected snippets from larger namespaces.

Thanks,
Holger

[1] http://www.topquadrant.com/products/TB_Composer.html
[2] http://groups.google.com/group/topbraid-composer-users
[3] http://rdfex.org


On Nov 2, 2009, at 8:48 PM, Ian Emmons wrote:

> Some tools, such as TopBraid Composer, do not behave well when the  
> namespace-to-file mapping is not 1-to-1.  This fact doesn't say  
> anything about the right or wrong of your proposal, of course --  
> only about how easy it will be in practice.
>
>
> On Oct 26, 2009, at 10:25 AM, Simon Reinhardt wrote:
>> Hi,
>>
>> It is becoming somewhat popular for large ontologies to be split  
>> into a core ontology file and module ontology files (which import  
>> the core). Normally each module then gets its own namespace for the  
>> terms defined in it. I was wondering though if that is too  
>> complicated for users of the ontologies. I have seen confusion of  
>> "sioc" and "sioct" (the prefixes for the SIOC core and the SIOC  
>> Types module namespaces) and when such vocabularies get higher  
>> adoption by people not so well versed with ontologies I can see it  
>> happen a lot more often.
>>
>> So as an alternative I want to explore the idea of just using one  
>> namespace shared between the core and the modules. The advantage  
>> would be not having to guess which namespace to use. One  
>> disadvantage for the developer(s) of the ontology is that a "local  
>> name" can only be used in one of the modules or core, you can't use  
>> the same "word" under a different namespace with a different  
>> meaning. Another disadvantage is that if you want the terms to  
>> dereference to the ontology files they have been defined in then  
>> you can only do that with a "/" namespace (and you have to set up  
>> lots of redirects).
>>
>> My questions: What do you think of that idea? Can you see any other  
>> advantages or disadvantages? Do you think several namespaces are  
>> not confusing at all? And what are the main advantages to splitting  
>> up ontologies into modules other than being easier to organise? Do  
>> they justify a higher burden on the ontology users?
>>
>> Thanks,
>> Simon

Received on Wednesday, 4 November 2009 05:17:48 UTC