Re: Ontology modules and namespaces

On 11/4/09, Holger Knublauch <holger@knublauch.com> wrote:
> 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.

It does not.

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

This is simply wrong and causes problems in practice. Thankfully it is
finally being fixed in Protege. The xml:base has no status whatsoever
in OWL. owl:imports in both OWL 1 and OWL 2 are based on the ontology
URI. The only way to determine the ontology URI is to fully parse an
OWL file. In doing so one must recognize that certain

:x rdf:type owl:Ontology

triples are the result of serialization of owl:import statements and
so their subject is not the name of the ontology. Once these are
discounted, there should be a single triple of the above form, and
whatever is in the place of the :x is the name of the ontology.

In order that a user not pay the price of this computation I suggest
that you cache the ontology name somewhere based on either the file
date, md5, or some other easily computed value that can indicate that
a file has changed.

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

Also problematic, see above.

Regards,
Alan

> 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 Monday, 9 November 2009 03:04:03 UTC