Ontologies in elvin notifications

Julian Boot julian at dstc.monash.edu.au
Fri Oct 5 13:40:20 EST 2001


 
a repost summarising one discussion at the end of teh ticker workshop,
although not by any means meant as minutes...

trying to define "group" would be even harder than user ;-(

-J

------- Forwarded Message

Date: Mon, 17 Sep 2001 10:36:16 +1000
From: Julian Boot <julian at dstc.monash.edu.au>
Subject: [elvin-dev] notification naming conventions
Sender: owner-elvin-dev at dstc.edu.au
To: elvin-dev at dstc.edu.au
Cc: agerber at dstc.edu.au
Reply-to: julian boot <j at pobox.com>
Message-id: <200109170036.f8H0aG729336 at xevious.dstc.monash.edu.au>
Content-transfer-encoding: 7BIT
Precedence: bulk
X-Scanned-By: MIMEDefang 1.0 (http://www.roaringpenguin.com/mimedefang/)
X-Virus-Scanned: by AMaViS perl-11


Someting that has been bugging me for sometime is how the dynamic nature
of elvin can be managed better accross different applications.

Notifications in elvin are by design free-form.  however, while this 
provides desirable characteristics in terms of loose coupling, it also
leads to clashes in terms of semantics accross applications.

An example of this would be a "User" field which is used as a nickname
in a messaging application, but a unix UID in a filewatcher.  while
we have traditionally ignored these instances "as the nature of elvin",
I don't think this attitude is counter-intuitive and a simple alternative
is possible.

In a global[0] elvin network, it is desirable to receive information
on a single user, eg "contains(User, 'Smith')".  If you have two
differnt notification formats, we have a problem.  eg:

- ---
CoffeeBiff: 1
User: "Smith"
Timeout: 10
- ---
FileWatcher: 1
User: 666
UserName: "Agent Smith"
File: "/etc/passwd"
Action: "edit"
- ---

A single consumer that wishes to track smith must be aware of all the
different fields in which "Smith" appears (as elvin does not allow for
a subscription of "contains(*, 'Smith')").  The consumer needs to use
"contains(User, 'Smith') || contains(UserName, 'Smith')".  For a network
with even more applications, this consumer is going to struggle to route
the content of interest.  It implies a level of coupling which is not
desirable and begs the question of how useful is content routing accross
multiple applications or domains?

There are any number of ways to try and reduce this problem.  I would like
o propose a simple and I think possibly the most useful way of maintaining
the semantics of notification attributes accross applications.

For common english words (we only allow 7-bit ascii in attribute names)
I would like elvin.org to maintain a registry of definitions which
define a single semantic for each word.  So:

   User: Informal name of a person interacting with a system component
   UID:  A numeric user id used to define a user

This registry would serve the same purpose as RFC 2119 for internet
drafts.  If an application has a user-like field, the developer
can check existing definitions and decide the best name to use.
A notification which obeys such rules could be tagged with a flag,
such as schema.elvin.org: "1.0" to indicate to consumers that it
can expect sane values in the delivered notification.

I expect this to be contentious, but believe it to be necessary.
Comments?

- -J

[0] where global is any elvin network with more than one application
using elvin.
- ----
          julian boot <j at pobox.com>
))X((     senior research scientist 
elvin     http://elvin.dstc.edu.au


------- End of Forwarded Message






More information about the ticker-dev mailing list