Re: axiom URIs

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

I want to identify the axiom, not the axiom in a particular document. If we 
had different sub-sets of axioms from a single 'parent' ontology, or from the 
same ontology as other axioms are added and removed over time, then locators 
based upon document structure are brittle.

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

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

You are pre-supposing that the OWL data-structures at some point go anywhere 
near a parser. Any sane solution for identifying axioms should be independent 
of any representation or parser, but be serializable faithfully to all 
representations. Many of the interesting uses of OWL 1.1 that I can envisage 
never involve an OWL-XML document being forged, but still may require some 
ability to refer to an axiom by reference, not value.

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

To do this, we would need a spec for ordering axioms. I see structural 
identity defined, but not a total ordering operator, but I haven't read that 
bit of the spec too closely yet. Regardless, as I pointed out above, ordering 
fails to identify an axiom seperate from the bag of axioms it currently finds 
itself in.

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

After the change to the ontology and to the axiom, it is still the 'covering 
axiom'. Regardless, we are now arguing about an application/community 
specific use of axiom identification, which has 
application/community-specific restrictions about when the URI becomes 
invalidated. Not our problem.

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

Again, we're getting lost in the applications side of things, but all of what 
you just said could be supported fairly trivially by a minor tweak to websvn 
and your favorite bug tracker. The very fact there are these choices to be 
made argues that we shouldn't be making them but letting other people have 
the tools to try stuff out.

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

Again, defer this to the community using the axiom URIs. It isn't our problem 
to legislate this kind of thing. It is our job to give people the tools to be 
able to try this stuff out themselves. If the community decided that C and D 
where of equivalent importance to them, then it probably would not make sense 
to carry the ID over in this case. If C was very nearly A, but D contained a 
tiny refinement, then they may chose differently. Their call.

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

Sure. So, I would settle for a community-agreed annotation property providing 
a unique ID to an axiom that was recognised as having no direct association 
with what the axioms meaning, but is there to allow external referencing. I'd 
prefer a full URI associated with the axiom as this captures what I am 
intending to say better.

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

Take a guess :) go on.

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

With mutable data it is /even/ more important to pass-by-reference. It means 
that if you are in a mutable world, you must take account of this either in 
the references themselves, or in the reference resolution process, rather 
than magik and hope. Again, we are wandering into a specific 
application/community question, rather than the base level functionality of 
being able to identify axioms.

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

Fine - I propose owl11:axiomID of type URI as an xml annotation on all axiom 
elements (modulo naming conventions with underscores) where owl11 expands to 
the owl 1.1 xsd. If you'd like to chose an annotation property name, and 
place it into the appropriate namespace, then we have two proposals that we 
can get people to agree on.

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

Perhaps not. When I click on a link in my web browser, it doesn't unpack the 
link string into the next page, but retrieves the resource identified by that 
link URI. Perhaps your web is different.

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

It's also tied to that document. IDs are relative to the document they are in, 
so not that good for identifying the axiom as a stand-alone. Realised I made 
the same mistake in my last post :)

> Two you could define an annotation "axiom id" then 
> use an xpointer scheme that is sensitive to that.

Which would probably work, especially if we could all agree on the name 
of "axiom id" and plop it into the bag of stuff you get for free (like Thing 
and Literal).

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

Matthew

Received on Monday, 5 February 2007 16:56:56 UTC