Re: Ontology modules and namespaces

Hi Simon,

basically, I agree with you: having a single namespace makes the
ontology easier to use, even if the terms are described in separate modules.

More generally, there is not reason why the "physical" splitting into
modules should necessarily result in a "logical" splitting into
different namespaces.

(note that on the other hand, nothing prevents somebody to describe
terms from several namespaces in a single file, and to serve that file
for all the involved namespace URIs).

Le 26/10/2009 15:25, Simon Reinhardt a écrit :
> 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.

Entirely agreed.

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

Is this really a disadvantage?? If the modules are part of a coherent
whole, it seems like a bad idea for the whole to provide names that
differ only by their namespace.

> 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).

Right, but '#' namespaces are preferable for small ontologies anyway
(since they force you to get the whole ontology). So if you have the
need to modularize your ontology, you probably also have the need to use
a "/" namespace.

Of course, this makes the modularization of existing ontologies, using
'#', harder...

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

Another advantage is that users using only some modules do not have to
load the whole ontology into their reasonner. But that puts a burden on
the ontology designer: they have to ensure that no inference will be
missed btw 2 modules by omitting a third one.

For example :

module 1 states:
 A is a class

module 2 states:
 B is a class

module 3 states:
 A subclass of B

if you import only modules 1 and 2, you would miss some inferences.
This is a an easy to fix example, but I suspect more complex ones may exist.

  pa

Received on Monday, 26 October 2009 15:31:17 UTC