WOW-GRS: scalability

> >
> >The scalability requirements ought to be sensitive to small
> >ontologies also (or more precisely, highly granular distributed
> >ontologies) ala purvasive sensors/actuators and other small devices
> >that may describe themselves via ontology and be linked to other
> >devices where the conglomerate is also an ontology.
>
> Is, or is connected via ? The idea that a conglomerate of devices IS
> an ontology is an interesting and (to me) novel idea.
>
> >An "ontology web"
> >or "web of ontologies" has been mentioned on the list. Is scalability
> >the one word that captures all this?
>
> Yes, I wonder quite what 'scalability' is supposed to mean. Maybe an
> example of something that isn't scaleable would be helpful (?)
>
>

I can do that one! (A true story)

Suppose we are an ice cream manufacturer with subsidiaries throughout
europe.

Each subsidiary runs Oracle 8.3 (I don't whether there is such a version),
and puts their business data such as a table of wholesale and retail outlets
and the number of each product sold through each.

The table schemata are designed independently.

The table and coloumn names are of course in different languages.

They do not match up.
Even if we 'translate' them, the information in the various databases is
incompatible.

A core problem being the SKU (Stock keeping unit - approx. how many ice
creams go in a box).

A second problem being that the ice-cream consumption prediction algorithms
vary across Europe and the parameters for these algorithms vary too.

There is no viable way of wrapping the various DBs to allow
interoperability.

Result: we have spent a lot on rebranding each subsidiary to have the same
logo.
We have redesigned all our packaging to have no natural language information
on it.
It is theoretical possible to have cross border movements of ice cream, but
the information systems can't handle it.

[Cross border movements of ice-cream in Europe would be rational since
European weather is more constant than the weather in any one country].


====

My view of the requirements is:
+ we should expect different people to describe similar things in different
ways, putting emphases on different aspects.
+ we enable multiple independently developed ontologies to interoperate
+ we should allow/encourage the same data to be expressed in multiple ways.


Given that that is hard, simply being able to name the ontologies and all
their parts is a good thing.

I beleive that in the first instance the interoperability sought will come
from code not dissimilar to legacy wrapping code, i.e. pretty horrible.


So, in my example, I see the Italian ice-cream data being expressed in the
Italian gelato ontology. For interoperating with the French ice-cream data,
we can overlay the Italian data with additional links expressed in the
French glaces ontology. This overlay is produced (in my model) by a load of
unprincipled and essentially ad hoc code.

For me, the inconsistency issue then arises since the description of the
French glaces ontology will have arisen in a mono-cultural context, and is
likely to be self-consistent. The Italian data conforms with different
assumptions and the overlay according to the French ontology is unlikely to
be perfect. It is likely to have mistakes. If we view ontology as a
classical logic exercise every bug is fatal, since contradictions are
non-local. However, experience in integrating IT systems suggests that
conversely bugs are usually local, and that most of the time inconsistency
is bad but not fatal.

Jeremy

Received on Tuesday, 11 December 2001 05:09:58 UTC