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

Re: XML Base (was Re: Ontology modules and namespaces)

From: Jeremy Carroll <jeremy@topquadrant.com>
Date: Thu, 12 Nov 2009 21:55:13 +0100
Message-ID: <4AFC7631.2050904@topquadrant.com>
To: Alan Ruttenberg <alanruttenberg@gmail.com>
CC: Holger Knublauch <holger@knublauch.com>, Ian Emmons <iemmons@bbn.com>, Simon Reinhardt <simon.reinhardt@koeln.de>, semantic-web@w3.org
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
>
>
>
>   
Received on Thursday, 12 November 2009 20:55:54 UTC

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