W3C home > Mailing lists > Public > public-owl-dev@w3.org > January to March 2007

Re: axiom URIs

From: Bijan Parsia <bparsia@cs.man.ac.uk>
Date: Mon, 22 Jan 2007 20:48:03 +0000
Message-Id: <69E86A11-739F-48D0-80E2-46D1E2A359C4@cs.man.ac.uk>
Cc: public-owl-dev@w3.org
To: Matthew Pocock <matthew.pocock@ncl.ac.uk>

On 22 Jan 2007, at 10:59, Matthew Pocock wrote:

> Hi,
>
> I've been browsing arround the OWL 1.1 draft spec. It's much more  
> readable
> than the 1.0 spec.

Yay! Kudos to Boris and Benardo.

> The UML diagrams realy help me. Where would I send any
> typos I find?

Here is fine. We monitor the list. We have a slightly fresher set of  
the documents that will be posted shortly, but we'll take your  
comments into account.

> Axiom is associated with annotations, which is great. Would it be  
> possible to
> associate an optional URI with every axiom?

A tool could do this (portably) with axiom annotations. Or one could  
layer it on top of the current specs.

But I think there are two things: One is can you associate an axiom  
with a URI. Of course, you can do that now. Two is *is* there a URI  
associated with each axiom (derived from the document etc.). At the  
moment no. Of course, in the xml format you could probably use XPointer.

One question to my mind is whether these identifers persist through  
mutation. I'd rather they didn't I think :)

> This would allow tools to `
> uniquely 'pull out' an axiom from an ontology without needing to  
> know its
> structural identity.

Well, I'm not such a fan of this, I guess. If the identifier is  
independent of its structural identity, what happens when "That"  
axiom's structural identity changes?

> This is specifically intended to provide a mechanism for `
> axiom naming/identification that stands seperate from and  
> orthogonal to
> concept naming.
>
> The use-cases I have are allong the following sorts of lines:
>
> * An application is working with an ontology, and selects some  
> axioms that it
> wishes to mark as interesting. It places their URIs into a message  
> that gets
> sent to a server. The server also contains a copy of the same  
> ontology, and
> using the URIs, it now knows which axioms the client is interested  
> in. A
> variation on this theme is where there are several ontologies (or  
> just axiom
> sets) in an application, and parts of each one are aggregated by URI
> reference into a merged axiom set.

Is there a *huge* advantage of this over either pulling the axioms  
out or marking them in the ontology with an annotation?

> * An ontology is being commented on in a blog/wiki/[insert own  
> external
> document here], and the author wishes to comment on a specific  
> axiom in the
> ontology. They can write down the full URI of that axiom and  
> comment on it
> cleanly, without needing to duplicate it or refer to the concept it
> contributes to.

This is interesting.

> * During versioning, axioms are added or removed from a concept. It is
> necisary to keep track of this, and to annotate the axioms  
> themselves with
> the rational for editing them, in addition to any comments on the  
> concepts.
> However, this information is held in a bug-tracking or source  
> versioning
> application, not within the OWL-XML.

Yeah, I'd have to see some of that to determine whether it's better  
to have a pointer or to keep copies. I could go either way, really.

> Best practice would, I guess, be to define an xml namespace prefix  
> for axiom
> URIs that is distinct from the xml namespace prefix for the concepts

I don't see that. An XPointer scheme would be easy enough.

> introduced. It would probably be very important for people working  
> with these
> things to keep axiom URIs seperate from concept URIs just for the  
> sake of
> sanity.

Perhaps, yeah.

> Also, it would be unfortunate if the axiom URI xml attribute name
> clashed with the concept URI xml attribute name.

We shouldn't do that ;)

I would think that the first step to this is to simply define a  
mechanism. I can think of a number of simple xpointer schemes that  
would work and that would provide a nice basis for exploring the  
design space.

Cheers,
Bijan.
Received on Monday, 22 January 2007 20:47:39 GMT

This archive was generated by hypermail 2.3.1 : Wednesday, 27 March 2013 09:32:54 GMT