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, 5 Feb 2007 16:00:04 +0000
Message-Id: <FD154C4E-45DF-4DC1-B811-2FE983CF8931@cs.man.ac.uk>
Cc: public-owl-dev@w3.org
To: Matthew Pocock <matthew.pocock@ncl.ac.uk>

On 5 Feb 2007, at 14:15, Matthew Pocock wrote:

> HI,
>
> Sorry for the delay in getting back to you. We had ISMB paper  
> deadlines to
> meet.
>
>>> 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.
>
> All the naive ways I can think to do this with XPointer are either  
> brittle to
> the document structure (order of elements etc.)

Why is this brittle? In RDF/XML it is brittle because reserializing  
can do all sorts of awful things to the order. But that's why I  
pointed to the XML format.

Obviously, even in the xml case this could be brittle, but absent  
some content based move I don't see what one can do for the implicit  
id case.

> or require me to encode the
> whole structure of the axiom into the xpath,

Or a hash. But that's not the easiest to work with.

> or require me to have a 'flag'
> annotation e.g. axiomIdentityAnnotation that the XPointer can glom  
> on to.

An ID, sure. That reduces to the "associate" an axiom with a URI.

> The
> primary reason for me wanting a URI to an axiom is so that I can  
> refer to it
> without needing to know anything about its innards.

Iunderstand.

> Additionally, in an application's in-memory representation, to  
> identify an
> axiom with a URI, it shouldn't be a requirement to go through  
> modelling the
> xml-representation.

Er...couldn't they do that on parsing?

> This would tie naive applications to an in-memory
> representation that is very close to the DOM.

Not really. If it were order based, it just requires maintaining  
order. In either case, functional syntax is pretty close to XML  
syntax and I would imagine many in mem representations will stick  
close to the functional syntax (see owl API).

>> One question to my mind is whether these identifers persist through
>> mutation. I'd rather they didn't I think :)
>
> There are case where I'd rather they did. For example, if there is  
> a class
> that is the disjoint union of a finite list of named child  
> concepts, and
> during editing we add another child concept, I'd want the relevant  
> axiom that
> will now need to list an extra child to have the same URI, as  
> externally in
> my wiki, I still want to say it's the axiom that makes sure all the  
> children
> are disjoint and covering.

You mean this semantically? Or as a comment? I would prefer that the  
very meaning of the axiom expressed this, and as it probably needs to  
be an extension, then an annotation makes sense. But then I'd want it  
attached to the axiom.

> Similarly (and even more likely), if the
> annotation associated with the axiom changes, external comments on  
> the axiom
> are very likely still to hold, so invalidating the URI would be
> counter-productive.

I understand these uses, but I think it's pretty tricky and highly  
tied to the particular set of annotations. For example, "last  
modified", if external, would get out of synch. And then you'd  
probably want a set of versions of that axiom so that you could  
eventually maintain those external annotations correctly.

Or what happens if I have an axiom like:

	A subclassof C & D

with an external comment: "Bijan's bestest axiom!!!"

And then I decide to split it:

	A subclassof C.
	A subclassof D.

Which is "the" axiom?

In other words, out of band annotation is just tricky. I'd like to  
see worked out examples before getting to hot and bothered by a fully  
robust id mechanism. I mean, you can always pop an id in an anotation  
at the moment.

> However, this kind of decision is probably better left to  
> communities to
> decide. I'm sure that best (and worst) practices would quickly  
> emerge, with
> structural identity, semantic import, semantic intent, anything- 
> goes being
> common levels at which groups choose to change axiom URIs.

I don't know what most of these are :)

I'd rather have specific applications to guide design.

[snip]
>> Is there a *huge* advantage of this over either pulling the axioms
>> out or marking them in the ontology with an annotation?
>
> Not *huge* but certainly cleaner. Pass-by-reference is always nicer  
> than
> pass-by-value.

Not really, esp. when things are mutable.

> Using annotations would require some community-wide agreement
> about what annotations are axiom-identifying annotations, which  
> seems like a
> potentially fraught and time-consuming process to go through when  
> all we need
> is something like an xsd:ID typed attribute named something like
> owl11:axiom-id, which by its very declaration/definition answers  
> all of these
> questions.

? This just is an annotation :) Or rather, an xml based mechanism  
that works with XPointer. It won't, currently, round trip through rdf  
whereas an annotation will. I don't see that technically there's a  
huge debate to be had either way. either you can do it already (via  
xml standard moves), or you can add it in via an annotation.  
Agreement is good, yes, but I don't see it'd be that hard to get  
agreement.

>> 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.
>
> I would always tend to pointers (with strong resource versioning  
> contracts on
> the URIs, if that is an application-level requirement) or else you  
> end up
> quoting stuff verbatum when you meant to refer to it, which isn't  
> really the
> point of the web.

Are we on the same web?

>> 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.
>
> Cool. Could you give a couple of examples?

Well, one you could use an xml:id like xpointer which is sorta tied  
to the xml format. Two you could define an annotation "axiom id" then  
use an xpointer scheme that is sensitive to that. Another would be to  
allow order sensitive xpointers (e.g., axiom 1, axiom 2). Or some  
combinations of all of these. If you grab axiom 1 and it has a  
different axiom id, then you know there was a shuffling of the document.

Another way would be to relativize them to an entity (plus some  
lexical normalization). So, you might have a scheme that let you get  
all the axioms which mention A. Or had A on the right hand side.  
These, obviously wouldn't be entirely order or modification  
independent, but  you could consider an ordering, e.g., first in  
strict lexical order, or lexical order given some sort of normalization.

(I didn't say they were deep :))

In general, for the associate mechanism, it pretty much devolves to  
annotation or some XML thing, and I think annotation is better.

Cheers,
Bijan.
Received on Monday, 5 February 2007 15:59:41 GMT

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