Re: axiom URIs

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.) or require me to encode the 
whole structure of the axiom into the xpath, or require me to have a 'flag' 
annotation e.g. axiomIdentityAnnotation that the XPointer can glom on to. 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.

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. This would tie naive applications to an in-memory 
representation that is very close to the DOM.

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

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.

Related to this is wether the axiom URI contributes to the structural identity 
of the axiom. I don't really have an opinion here. For consistency, it 
probably should do. I can think of a couple of cases where things could get 
interesting e.g. if you store sets of axioms and there are two otherwise 
identical ones with different URIs. Without defining 'merge' operations for 
these cases, it's easier to just make the axiom URI part of the sid.

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

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

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

>
> Cheers,
> Bijan.

Matthew

Received on Monday, 5 February 2007 14:15:26 UTC