Ontologies etc [ was Re: Attribute Naming ]

[Bill Segall]

I'd like to broaden this thread so I've cross-posted this to elvin-dev and
ticker-dev and sent followups to elvin-dev as I think the ramifications are
broader than just the tickertape application. I've been on holidays so
please excuse my late entrance to the debate.

Starting from a philosophical background, I believe when it comes to
ontologies we're always going to be left with imperfection because the
world is a complex, illogical, and poorly defined place. Any spoken
language is a good example of this and I'll leave the ontological
implications of Godel's proof for someone with more talent in both fields
(maths and linguistics) than myself.

That aside, what we seem to be trying to achieve is a simpler but still
quite difficult task - a set of naming principles and recommendations for
application naming and versioning.

A desirable set of attributes would seem to be:
* clarity
* applicability to all applications
* applicability to multiple simultaneous applications
* Implication of a set of semantic constraints

Within Elvin it is not nor will it ever be possible to enforce semantic
constraints based upon some particular attribute being specified. (i.e,
subscribing to a specific attribute cannot guarantee the presence or
absence of others). This is very desirable in terms of flexibility and
keeps the notion of Elvin being dynamic in terms of both publishing and
subscribing. It means we don't require pre-publication of formats,
metadata, or MIB style nonsense. If you don't agree with this then Elvin is
not the droid you're looking for :-) It's fundamental to Elvin's model,
performance, and scalability.

So, no attribute can mandate that merely subscribing to that attribute will
give you correctly structured messages. This is a good way of crashing (or
raising an exception for those (blighted souls :-) who believe in
generosity of languages) because someone else didn't obey the rules.

We will endeavour to support the rules by being "strict in what we send and
generous in what we receive" - who said this and in what context? The end
result is that we shouldn't be using these attributes as subscription
fodder but should be using the underlying fields we really expect to be
there. It's the only way to be sure and obeys the Elvin principle of
subscribing on the content you want rather than a topic or channel.

This leaves us with using things like protocol version numbers and names as
a mark of conformance and of making things readable. This is highly
desirable and also addresses clarity from the intent side.

My difficulty with the current use of something like:
  org.elvin.tickertape: 1.1
  ... tickertape attributes
is that the attribute is not shared and subscribable without knowing it's
name. 

My difficulty with:
  protocol.name: "org.elvin.tickertape"
  protocol.version.major: 1
  protocol.version.minor: 1
  ... tickertape attributes
is that I can't support two versions of the same protocol or two different
protocols in the same notification. (Whether we split major/minor or make
it textual is one of those difficult things - rpm uses the textual approach
and it hurts).

If we had a message that supported two different protocols we might do
something like:
  protocol.names: "org.elvin.tickertape biz.elvin.coffeebiff"
  protocol.version.org.elvin.tickertape: 1.1
  protocol.version.biz.elvin.coffeebiff: 2.0
  ... tickertape attributes
  ... coffeebiff attributes

If someone wanted to subscribe to a particular protocol they would be
forced into using a regular expression (or wildcard) on protocol.names but
I'm hoping that I've successfully argued that this is a bad thing
regardless.

Having an attribute like "protocol.version.org.elvin.tickertape" is
exceptionally ugly. Could we compromise this to a mix of Julian and David
like this?
  protocol.names: "org.elvin.tickertape biz.elvin.coffeebiff"
  org.elvin.tickertape: 1.1
  biz.elvin.coffeebiff: 2.0
  ... tickertape attributes
  ... coffeebiff attributes

We could add in things like the spec via:
  org.elvin.tickertape.spec: "http://..."
(and I kind of like the reference in the events although every time we do
this we soak up bandwidth).


To finish, I think it's really important that we define a set of
recommendations, possibly in the form of an RFC but at least initially just
as as html on the Elvin web. It needs examples (hopefully for xtickertape)
that helps people. I'm not really happy with any of the compromises above
so what might be better?  What extra information (liek spec references) do
we want to track? How do we want to represent versions?

I'll write this up somewhere if we can reach some sort of consensus. I
think this is sufficiently important that we need to reach some form of
agreement on a v1 spec for this in the short-term.

Bill.