W3C home > Mailing lists > Public > semantic-web@w3.org > November 2009

Re: Ontology modules and namespaces

From: Alan Ruttenberg <alanruttenberg@gmail.com>
Date: Mon, 9 Nov 2009 14:37:31 -0500
Message-ID: <29af5e2d0911091137h5c2fa5d7yf3f4f3fd320d81f1@mail.gmail.com>
To: Holger Knublauch <holger@knublauch.com>
Cc: Ian Emmons <iemmons@bbn.com>, Simon Reinhardt <simon.reinhardt@koeln.de>, semantic-web@w3.org, public-lod@w3.org
On Mon, Nov 9, 2009 at 2:14 PM, Holger Knublauch <holger@knublauch.com> wrote:
>
> On Nov 8, 2009, at 7:03 PM, Alan Ruttenberg wrote:
>
> 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.
>
> Thanks for sharing *your opinion*.

You are *welcome*.

> The original question was about
> modularizing ontologies so that resources from the same namespace can be
> organized across multiple files. Many users are confused about the
> difference between ontology URIs and namespaces, and I was addressing this.

You have addressed it poorly. There is no connection between the two.
Suggesting otherwise does a disservice.

> You seem to be switching topics now to whether base URIs are a valid
> mechanism to identify those (multiple) files or whether the URIs of
> owl:Ontologies should be used only.

As far as any of the semantic web technologies go xml:base *does not
exist*. The specs know *nothing* about it. Nor should they.

> 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.
>
> Comparing TopBraid and Protege is like comparing apples with oranges.

They were compared because they share the same bug, and because parts
of the protege code base were written by the same developer. Protege 3
and Protege 4 have the same problem in this regard.

> Protege 4 has been designed as a native OWL 2 tool, and it generally cannot
> correctly handle RDF files. TopBraid has been designed as a semantic web
> technology tool with a focus on RDF-based languages including, but not
> limited to, OWL. Many RDF files do not even declare owl:Ontologies, making
> your suggested solution not attractive in general.

I only commented on the OWL case, but since you mention it, the use of
xml base in RDF is similarly unjustified.

> In practice however
> TopBraid makes efforts to make sure that base URI (written as xml:base in
> RDF/XML) and the owl:Ontology remain synchronized.

Tools need to live in the world defined by the specification, so that
artifacts that are generated according to the specification will work
with them. I, and I presume many others, are not interested in
idiosyncratic, tool specific, solutions.

> It will add missing
> owl:Ontology triples if a file gets saved from the web, to maximize OWL
> compatibility. TopBraid also provides a warning if there are more than one
> owl:Ontologies in a file, and has a button to fix this scenario. For most
> back-ends (such as databases), TopBraid also checks for the owl:Ontology to
> learn about the base URI.

These have *nothing* to do with each other.

> So I don't think there are substantial practical
> differences between what you outline and what we have implemented.
> BTW I just downloaded Protege

As far as I know these fixes have not yet been pushed out.

-Alan
Received on Monday, 9 November 2009 19:38:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:03 UTC