Ontology modules and namespaces

[Simon Reinhardt]

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

[Pierre-Antoine Champin]

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

[David Booth-6]

On Mon, 2009-10-26 at 15:25 +0100, Simon Reinhardt wrote:

> It is becoming somewhat popular for large ontologies to be split into
> a core ontology file and module ontology files . . . . I want to
> explore the idea of just using one namespace shared between the core
> and the modules.

My view:

 - Regardless of whether a shared namespace is used, using the same
local name in multiple modules or ontologies that are *intended* to be
used together is not a good idea, as it causes user confusion.
Therefore local names should be centrally coordinated to avoid collision
*if* it is feasible to do so.  A wiki (or semantic wiki) can be very
helpful for this purpose.  As a set of ontologies gets really huge there
will come a day when this will become infeasible, because different
domains really will want to use the same local name in different ways,
but the longer that day can be postponed the better.

 - From a user's perspective, there is a tendency to forget which module
contains which term.  This argues in favor of a single, shared
namespace.  On the other hand, the benefit of having the ontology split
into modules is that one does not have to load modules that are not
needed.  However, the need to do this is far less common than the need
to use the terms in the ontology.  Therefore, IMO it is better for users
if all terms are place in the same shared namespace.

 - A shared namespace can (by default) resolve to a file containing the
entire ontology, but that same ontology can *also* be made available in
multiple files for those who want finer granularity of control over
which parts they choose to load.


--
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.

[Bojars, Uldis]

A good question.

Forwarding the conversation to Ontolog-Forum and SIOC-Dev lists as their
subscribers may also have interesting insights.

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
>

[Ian Emmons]

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

[Holger Knublauch]

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

[Alan Ruttenberg-2]

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

[Andrea Splendiani-5]

Hi,

I think that if the need for modularization is real, it won't be a  
problem to have different prefixes, as these should map to distinct  
(hopefully) intuitive partitions of an ontology.
I think some simple trick as choosing less confusing prefixed would  
help.

ciao,
Andrea


On 26 Oct 2009, at 14:25, 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
>

---
Andrea Splendiani
Senior Bioinformatics Scientist
Rothamsted Research, Harpenden, UK
andrea.splendiani@...
[phone] ext 2004

[Holger Knublauch]

On Nov 8, 2009, at 7:03 PM, Alan Ruttenberg wrote:

On 11/4/09, Holger Knublauch <holger@...> 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*. 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 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.

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. 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. 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. 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. So I don't think there are substantial practical differences between what you outline and what we have implemented.

BTW I just downloaded Protege to see how it handles the case of multiple base URIs (owl:Ontology URIs) across multiple files. With 4.0.1, I did the following:

- Create file test.owl with URI http://example.org/test

- Add a class Person and save

- Create file test2.owl with same base URI as above

- Protege opens the old (!) file test.owl and no file (or warning) gets created !

- Since Protege does not allow me to create two files with the same URI, I

- create a file test2.owl with http://example.org/test2

- Protege opens the file

- Close Protege

- Manually edit test2.owl so that it has the same base URI

- Open test2.owl and add owl:imports to file test.owl

- Imports view now claims to import test.owl, but none of its triples show up

All this shows that the issue is not fixed at all in Protege, and the same kind of base URI/ontology confusion may arise like in TopBraid. IMHO it is still better to allow working with multiple files with the same base URI than just silently ignoring them and hoping for the best.

- I also tried to import http://rdfex.org/foaf/Person,firstName which TopBraid handles without problems, but Protege fails completely because there is no owl:Ontology declared. I guess such a strict interpretation of the OWL spec is not helpful if the OWL community wants to interoperate with RDF-based ontologies. And why should all RDF snippets in the world be forced to declare an extra triple only because some OWL tools are inflexible? OWL is based on RDF, not the other way around.

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.

How is this supposed to work in practice? My humble understanding of the owl:imports mechanism is that it is supposed to support importing ontologies, in particular from the web. The URL being imported should therefore align with the physical location of that file, following best linked data practice. If they are different (like in the infamous case of the SWRL ontology) significant problems arise. What is the use case of having distinct base URIs (physical location) and owl:Ontologies? I can certainly see the use case of working with local files (and we do this all the time), but for web-based ontologies this looks like a very bad practice?

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.

This could be an optimization for a future version. We have decided against persisting those mappings and instead compute the mapping at start-up because persisting them might introduce yet another thing that gets out of date. But I can see that Protege wants to cache those values because reloading all files to get their owl:Ontology is expensive.

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.

I don't think so, see above.

Regards,

Holger

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

[Alan Ruttenberg-2]

On Mon, Nov 9, 2009 at 2:14 PM, Holger Knublauch <holger@...> wrote:

>
> On Nov 8, 2009, at 7:03 PM, Alan Ruttenberg wrote:
>
> On 11/4/09, Holger Knublauch <holger@...> 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

[Jeremy Carroll-2]

Hi Simon

I have only just seen your question about namespaces  and saw that the
discussion so far has missed discussing the relevant namespace standards
(even the somewhat silly dispute about whether TopBraid Composer follows
the standards concerning namespaces and XML Base: for the record, it does).

Basically there are three: XML Namespaces [1], RDF Schema, and RDF/XML
Syntax. OWL, for example, defers to all three of these.

There is a foundational issue in that XML Namespaces were done in a bit
of a hurry, and then the way that RDF interacts with them isn't the same
as when they are being used in XML.

So first: from the point of view of the logical meaning of an RDF or OWL
document, namespaces are completely irrelevant.
The role of namespaces is to organize names into (informal) collections,
for the convenience of the user (in this case the ontologist).
Hence, if you find it more convenient to use one namespace instead of
several then you should.

There is quite a gap between the Namespaces in XML Rec. and RDF. The
former says simply:
[[
Definition: An *XML namespace* is identified by an IRI reference
[RFC3987] <http://www.w3.org/TR/2006/REC-xml-names11-20060816/#IRIRef>;
element and attribute names may be placed in an XML namespace using the
mechanisms described in this specification.
]]
so that a namespace is a collection of names.

RDF/XML [2] gives a mechanism for mapping namespace qualified names to
RDF URI References (intended to be compatible with IRI Refs), and hence
to URIRef nodes in an RDF graph.

RDF Schema [3] (the RDF Vocabulary Description Language) then gives
informal definitions to the various names in both the rdf and rdfs
namespaces. A key half paragraph giving insight into the relationship
between namespaces and vocabularies is found in:

[[ The core vocabulary is defined in a namespace informally called
'rdfs' here. That namespace is identified by the URI-Reference
http://www.w3.org/2000/01/rdf-schema# and is associated with the prefix
'rdfs'. This specification also uses the prefix 'rdf' to refer to the
RDF namespace
<http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/#section-Namespace>
http://www.w3.org/1999/02/22-rdf-syntax-ns#.
]]

The relationship between vocabularies (and ontologies) and namespaces is
informal. Often the terms in a vocabulary or ontology are defined in one
or two namespaces. There is no prohibition on using a vocabulary in
which every term is from its own namespace. The use of namespaces allows
us to use prefixes, which allows us to avoid writing cumbersome URIs too
many times.

Jeremy Carroll
TopQuadrant



[1]
http://www.w3.org/TR/2006/REC-xml-names11-20060816/

[2]
http://www.w3.org/TR/2004/REC-rdf-syntax-grammar-20040210/

[3]
http://www.w3.org/TR/2004/REC-rdf-schema-20040210/

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

[Jeremy Carroll-2]

Hi Alan

you seem to have forgotten yourself, or at least that bit of yourself
that read the OWL 2 documents.

Alan Ruttenberg wrote:
> As far as any of the semantic web technologies go xml:base *does not
> exist*. The specs know *nothing* about it. Nor should they.
>
>  
I read:
http://www.w3.org/TR/2009/REC-owl2-xml-serialization-20091027/#IRIs
/[[
MUST/ be resolved against the respective /base IRI/ as specified in the
XML Base specification [XML Base
<http://www.w3.org/TR/2009/REC-owl2-xml-serialization-20091027/#ref-xml-base>].

]]

I read
http://www.w3.org/TR/2009/REC-owl2-primer-20091027/#Ontology_Management
and see the second set of examples using xml:base in both the RDF/XML
and the OWL/XML

The automated converter for the OWL2 tests appears to add xml:base for
both RDF/XML and OWL/XML formats,
e.g. see
http://owl.semanticweb.org/page/Qualified-cardinality-restricted-int

The OWL1 test cases all have explicit xml:base


What is the role of an xml:base, well that is explained in RFC 3986,
section 5.1.1. This explicitly takes precedence over the retrieval URI,
when doing base conversions.

In particular, the function of TopBraid Composer which adds an
appropriate xml:base declaration to a file to allow a copy to be stored
locally, and for relative URI computations to be made correctly seems to
be the primary intended purpose.

(Of course, there is also a normative dependency from OWL2 to xml:base
via RDF/XML Syntax)

Jeremy

[Alan Ruttenberg-2]

On Tue, Nov 10, 2009 at 5:30 PM, Jeremy Carroll <jeremy@...> wrote:
> Hi Alan
>
> you seem to have forgotten yourself, or at least that bit of yourself that
> read the OWL 2 documents.

Don't think so.

>
> Alan Ruttenberg wrote:
>>
>> As far as any of the semantic web technologies go xml:base *does not
>> exist*. The specs know *nothing* about it. Nor should they.
>>
>>
>
> I read:
> http://www.w3.org/TR/2009/REC-owl2-xml-serialization-20091027/#IRIs
> /[[
> MUST/ be resolved against the respective /base IRI/ as specified in the XML
> Base specification [XML Base
> <http://www.w3.org/TR/2009/REC-owl2-xml-serialization-20091027/#ref-xml-base>].
> ]]

This is an aspect of syntax of some serializations of OWL. Not all
serializations have an xml base. Therefore I classify xml:base as
something to do with XML in particular and OWL and RDF only insofar as
OWL can be serialized using XML.

As you point out in your previous email, base and prefixes provide a
way to abbreviate URIs. There is no other specified purpose for them.
In my opinion, any other use for them is a bad idea at least because
xml:base does not exist in all serializations and we want stuff to
work independent of choice of serialization, if at all possible.

So I maintain: the "semantic" part of semantic web technologies, knows
nothing of xml:base.

> I read
> http://www.w3.org/TR/2009/REC-owl2-primer-20091027/#Ontology_Management
> and see the second set of examples using xml:base in both the RDF/XML and
> the OWL/XML

And not in the manchester, nor in the turtle.

> The automated converter for the OWL2 tests appears to add xml:base for both
> RDF/XML and OWL/XML formats,
> e.g. see
> http://owl.semanticweb.org/page/Qualified-cardinality-restricted-int

i.e. it serializes the ontologies properly, by which I mean it
correctly uses the facilities of XML.

> The OWL1 test cases all have explicit xml:base

So? xml:base is not required to be explicit in any XML document. If
not explicit it gets defaulted to the location of the document.

> What is the role of an xml:base, well that is explained in RFC 3986, section
> 5.1.1. This explicitly takes precedence over the retrieval URI, when doing
> base conversions.
>
> In particular, the function of TopBraid Composer which adds an appropriate
> xml:base declaration to a file to allow a copy to be stored locally

zing. The disconnect, as I see it, is the connection between "adds an
appropriate xml:base declaration" and "allow a copy to be stored
locally". There is no such thing in the specification as "allow a copy
to be stored locally". There *is* such a thing as an XQuery giving the
same answer when posed against different XML files.

>, and for relative URI computations to be made correctly seems to be the primary
> intended purpose.

Sure. But making decisions other decisions based on the value of the
xml:base isn't part of the spec, and this is what is being done.
Decisions on what files to import (at least in OWL) are based on the
ontology URI, not the xml:base, except to the extent that in XML
serialized files, the xml:base *might* have been used to parse the
value of the ontology URI.

> (Of course, there is also a normative dependency from OWL2 to xml:base via
> RDF/XML Syntax)

A dependency of certain OWL2 *serializations* on xml:base via both the
RDF/XML syntax and the XML serialization. But OWL the language is
independent of any particular syntax, and so the attempt was to define
the behavior of imports in a way that did not depend on a particular
syntax.  There is a single exception to this goal, there for backwards
compatibility with OWL 1, which has to do with the way that imports of
RDF documents are handled.
http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Resolving_Included_RDF_Graphs

Regards,
Alan

[Jeremy Carroll-2]

>> Alan Ruttenberg wrote:
>>    
>>> As far as any of the semantic web technologies go xml:base *does not
>>> exist*. The specs know *nothing* about it. Nor should they.
>>>
>>>      
Alan - the above statement is simply false. You really should have the
good grace to admit that you have been caught out.

> This is an aspect of syntax of some serializations of OWL. Not all
> serializations have an xml base. Therefore I classify xml:base as
> something to do with XML in particular and OWL and RDF only insofar as
> OWL can be serialized using XML.
>
>  

If you bothered to read the reference to RFC 3986, 5.1.1 you would see
that section 5.1 explains how all Web retrievable documents that involve
relative IRIs have a base.


> So I maintain: the "semantic" part of semantic web technologies, knows
> nothing of xml:base.
>
>  
Quite a change in your position. (I agree with this statement).
Since we were talking about  pragmatic issues to do with managing
ontologies and namespaces, what is semantically relevant in a semantic
web document is somewhat of a side issue in this conversation.

>> The automated converter for the OWL2 tests appears to add xml:base for both
>> RDF/XML and OWL/XML formats,
>> e.g. see
>> http://owl.semanticweb.org/page/Qualified-cardinality-restricted-int
>>    
>
> i.e. it serializes the ontologies properly, by which I mean it
> correctly uses the facilities of XML.
>
>  

Use of xml:base is always optional, and the developers of the test case
infrastructure chose to use that option.

> zing. The disconnect, as I see it, is the connection between "adds an
> appropriate xml:base declaration" and "allow a copy to be stored
> locally". There is no such thing in the specification as "allow a copy
> to be stored locally". There *is* such a thing as an XQuery giving the
> same answer when posed against different XML files.
>
>  
Now that is a disconnect. XQuery concerns the actual syntactic structure
of an XML document. This has very little to do with the semantics, and
except with a lot of care and attention, the systematic use of XQuery
with semantic web documents will get you into trouble.

(I take it that the implementations you use do not make any local copies
at all of any of the documents you use ... hmmm ... they must be very
fast. Here's another part of the OWL2 spec that you seem to have failed
to read:
http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Imports
[[
For example, in order to access the above mentioned ontology document
from a local cache,
]]
which is other words for allowing a copy to be stored locally. Alan,
please read the specs before making further groundless bold assertions.)

>> , and for relative URI computations to be made correctly seems to be the primary
>> intended purpose.
>>    
>
> Sure. But making decisions other decisions based on the value of the
> xml:base isn't part of the spec, and this is what is being done.
> Decisions on what files to import (at least in OWL) are based on the
> ontology URI, not the xml:base, except to the extent that in XML
> serialized files, the xml:base *might* have been used to parse the
> value of the ontology URI.
>
>  

It generally is, but yes - reading the xml:base alone on arbitrary web
content could result in error.

>> (Of course, there is also a normative dependency from OWL2 to xml:base via
>> RDF/XML Syntax)
>>    
>
> A dependency of certain OWL2 *serializations* on xml:base via both the
> RDF/XML syntax and the XML serialization. But OWL the language is
> independent of any particular syntax, and so the attempt was to define
> the behavior of imports in a way that did not depend on a particular
> syntax.  There is a single exception to this goal, there for backwards
> compatibility with OWL 1, which has to do with the way that imports of
> RDF documents are handled.
> http://www.w3.org/TR/2009/REC-owl2-mapping-to-rdf-20091027/#Resolving_Included_RDF_Graphs
>  

That's an interesting para, thanks for the pointer.
I didn't find the text in the OWL2 specs that actually talks about
dereferencing the imported IRIs ... do you have a pointer please.

> Regards,
> Alan
>  
Jeremy

[Alan Ruttenberg-2]

On Wed, Nov 11, 2009 at 2:48 AM, Jeremy Carroll <jeremy@...> wrote:

>
>>> Alan Ruttenberg wrote:
>
>> This is an aspect of syntax of some serializations of OWL. Not all
>> serializations have an xml base. Therefore I classify xml:base as
>> something to do with XML in particular and OWL and RDF only insofar as
>> OWL can be serialized using XML.
>
> If you bothered to read the reference to RFC 3986, 5.1.1 you would see that
> section 5.1 explains how all Web retrievable documents that involve relative
> IRIs have a base.

5.1.1 describes one of four ways that a base URI can be established,
in this case by embedding a declaration of it explicitly in the
content.  When I said "Not all *serializations* have an xml base." I
meant not all documents use the method described in 5.1.1.  I referred
to  the method in 5.1.3 elsewhere in my message.

> Since we were talking about  pragmatic issues to do with managing ontologies
> and namespaces,

There are ontologies to manage. I contest that there are namespaces to manage.

> Now that is a disconnect. XQuery concerns the actual syntactic structure of
> an XML document. This has very little to do with the semantics, and except
> with a lot of care and attention, the systematic use of XQuery with semantic
> web documents will get you into trouble.

The point was to demonstrate that there are, at the level of XML
itself, mechanisms to determine equality of documents that goes beyond
the surface syntactic structure. OWL's (via RDF/XML) use of XML
similarly is at a level that does not depend on some details of the
surface syntactic structure.

> (I take it that the implementations you use do not make any local copies at
> all of any of the documents you use ... hmmm ... they must be very fast.

I am involved with development of OWL ontologies on a daily basis and
have to deal with performance issues of a variety of sorts. A search
of google will find a reasonable amount of detail on such efforts.

I do use local copies. It is a royal pain. Having different tools
inject idiosyncratic behaviors, such as ignoring owl ontology names
makes it even more difficult, such experience being the impetus behind
my first email in this round.

I proposed, within the working group, that we make this easier, but it
was not considered to be something appropriate for the working group
to undertake in full. There is at least *some* mechanism available
now, via the versionIRI, to make this possible in a supported way.
http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Versioning_of_OWL_2_Ontologies

In addition there is rich support for caching associated with the http
specifications, should your ontologies be the sort that are on the
web.

> Here's another part of the OWL2 spec that you seem to have failed to read:
> http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Imports
> [[
> For example, in order to access the above mentioned ontology document from a
> local cache,
> ]]
> which is other words for allowing a copy to be stored locally. Alan, please
> read the specs before making further groundless bold assertions.)

I'm sorry, I don't believe I made any assertions which would
contradict this. Could you please cite what I said that makes you
think so?

>>> , and for relative URI computations to be made correctly seems to be the
>>> primary intended purpose.

Really? That section says nothing about relative URI computations.

> I didn't find the text in the OWL2 specs that actually talks about
> dereferencing the imported IRIs ... do you have a pointer please.

http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_Documents

Ontology documents are not represented in the structural specification
of OWL 2, and the specification of OWL 2 makes only the following two
assumptions about their nature:

* Each ontology document can be accessed via an IRI by means of an
appropriate protocol.
* Each ontology document can be converted in some well-defined way
into an ontology (i.e., into an instance of the Ontology UML class
from the structural specification).

http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#IRIs discusses
other details, including:

* Each IRI must be absolute (i.e., not relative). [speaking of IRIs in
the structure specification]

* If a concrete syntax uses this IRI abbreviation mechanism, it should
provide a suitable mechanism for declaring prefix names. Furthermore,
abbreviated IRIs are not represented in the structural specification
of OWL 2, and OWL 2 implementations must exhibit the same observable
behavior as if all abbreviated IRIs were expanded into full IRIs
during parsing. Concrete syntaxes such as the RDF/XML Syntax [RDF
Syntax] allow IRIs to be abbreviated in relation to the IRI of the
document they are contained in. If used, such mechanisms are
independent from the above described abbreviation mechanism. The
abbreviated IRIs have the syntactic form of qualified names from the
XML Namespaces specification [XML Namespaces]; therefore, it is common
to refer to PI as a namespace and rc as a local name. This
abbreviation mechanism, however, is independent from XML namespaces
and can be understood as a simple macro mechanism that expands prefix
names with the associated IRIs.


-Alan


>
>> Regards,
>> Alan
>>
>
> Jeremy
>
>

[Jeremy Carroll-2]

Alan Ruttenberg wrote:
>
>> Since we were talking about  pragmatic issues to do with managing ontologies
>> and namespaces,
>>    
>
> There are ontologies to manage. I contest that there are namespaces to manage.
>
>  

Personally, I agree with you here. However, I find that lots of other
people (including my customers) do want to manage namespaces. The specs
certainly do not prohibit that, and at least partially encourage it (it
is not required). On the Jena team one of the on-going battles between
the developers and the users was that the users want to preserve their
xml namespace prefices. Of course, in most serious disagreements between
the specifications and customers, the customer is right.

>
> I do use local copies. It is a royal pain. Having different tools
> inject idiosyncratic behaviors, such as ignoring owl ontology names
> makes it even more difficult, such experience being the impetus behind
> my first email in this round.
>
>  
This is a legitimate complaint.
I think there are certain use cases, involving transferring files
between multiple tools, where I can see the approach in the TopBraid
Suite is not quite right.
We do have code that scans the file looking for the Ontology element and
find the ontology uri from that, but we try to use it as little as
possible, since it is more efficient to cache the result.
(Essentially we write an xml:base into an RDF/XML file, or a comment
into an N3 or turtle file, which caches the result of that computation.
This is flawed in the case in which we import a file with an xml:base
which differs from the identifier of its main ontology).

The OWL2 versioning stuff is very nice, and we should be making more of
it in our tool set. I'll try and think up a design that scans just a
little more frequently, and has better support for the versioning
mechanisms of OWL2.
Prior to OWL2 versioning, the vast majority of cases the retrieval URL
and the Ontology identifier are identical - no great surprise since the
triple <URL> rdf:type owl:Ontology says that the resource identified by
the URL is an ontology, hence the usual idiom

<rdf:RDF xml:base="http://example.org/ontology">
   <owl:Ontology rdf:about="">   <!-- same document reference to
http://example.org/ontology -->

> I proposed, within the working group, that we make this easier, but it
> was not considered to be something appropriate for the working group
> to undertake in full. There is at least *some* mechanism available
> now, via the versionIRI, to make this possible in a supported way.
> http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Versioning_of_OWL_2_Ontologies
>
> In addition there is rich support for caching associated with the http
> specifications, should your ontologies be the sort that are on the
> web.
>
>  
>  

Thanks for these pointers about dereferencing - fortunately no great
surprises

Jeremy

>> I didn't find the text in the OWL2 specs that actually talks about
>> dereferencing the imported IRIs ... do you have a pointer please.
>>    
>
> http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#Ontology_Documents
>
> Ontology documents are not represented in the structural specification
> of OWL 2, and the specification of OWL 2 makes only the following two
> assumptions about their nature:
>
> * Each ontology document can be accessed via an IRI by means of an
> appropriate protocol.
> * Each ontology document can be converted in some well-defined way
> into an ontology (i.e., into an instance of the Ontology UML class
> from the structural specification).
>
> http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/#IRIs discusses
> other details, including:
>
> * Each IRI must be absolute (i.e., not relative). [speaking of IRIs in
> the structure specification]
>
> * If a concrete syntax uses this IRI abbreviation mechanism, it should
> provide a suitable mechanism for declaring prefix names. Furthermore,
> abbreviated IRIs are not represented in the structural specification
> of OWL 2, and OWL 2 implementations must exhibit the same observable
> behavior as if all abbreviated IRIs were expanded into full IRIs
> during parsing. Concrete syntaxes such as the RDF/XML Syntax [RDF
> Syntax] allow IRIs to be abbreviated in relation to the IRI of the
> document they are contained in. If used, such mechanisms are
> independent from the above described abbreviation mechanism. The
> abbreviated IRIs have the syntactic form of qualified names from the
> XML Namespaces specification [XML Namespaces]; therefore, it is common
> to refer to PI as a namespace and rc as a local name. This
> abbreviation mechanism, however, is independent from XML namespaces
> and can be understood as a simple macro mechanism that expands prefix
> names with the associated IRIs.
>
>
> -Alan
>
>
>
>