SUO: A fabric of many threads
This message from Christopher Spottiswoode cms@metaset.co.za bounced so
here it is again:
Many of the threads on this list provide handy lead-ins to a rephrasing of
my earlier postings, with subject-line "Responding to the 2nd call, an
alternative", of 26 & 27 July. The rephrasing had been suggested by Mike
Uschold, most reasonably looking for a coherent picture without having to
read the many references cited. (Thanks, Mike, for the further stimulus!)
So this time I hope I better address the list's objectives and membership,
and more meaningfully propose future collaboration.
As you will see, or as you might well have concluded from those earlier
postings, my proposal to this list seems so strange and even self-satisfied
that I must forestall the quite reasonable suspicion that it might be some
crazy kind of takeover bid. So I open by congratulating Jim Schoening on
his chairing of the list. He has been handling an exceptionally difficult
undertaking with impressive circumspection, insight and application. I look
forward to his continuing leadership. (Those sentiments are genuine and
sincere too!)
My own personal objective with this posting is almost the opposite of a
takeover bid: I shall invite the list's participation in my present
ontology work, or that of some of you at least, with a view to your takeover
of it. There are enough professional and commercial opportunities in it for
you, while such a transaction would enable me to pursue my long-stated plan
to become a mere user (though also enthusiastic advocate!) of the eventual
product of our joint efforts.
The most immediately-obvious benefit to all parties would be a provisional
yet most significant SUO, defined and launched for further evolution in the
widest market within one year, in contrast to the much longer timeframes
that generally seem to be envisaged.
- - - - - - - - - - -
Up to the SUO
- - - - - - - - - - -
Many major SUO-list themes have most relevantly revolved around the
definition of "Scope and Purpose" with practical or "engineering" concerns
in mind (to copy John Sowa's insistent label on one of the hats he wears).
The question is clearly central, but answering it is far from simple: our
aim must be practical, but better practicality tends to enable better aims.
On the basis of my own practical IT and commercial experience, for example,
I have long criticized the distinction between "analyst" and "designer" with
the observation that 'We don't know what we want until we know what we can
get.' The quandary is even fundamental to the way the market works: in
practice, supply and demand shape each other before they accept a match.
(Human beings have evolved to be hugely adaptable, given the many leaps yet
also imperfections of creativity, invention, implementation and deployment.)
Well, in my own insignificant but temporarily relevant personal case, there
has been a continuous, many-streamed, and - in retrospect - not unduly
jagged 40-year-long progress of such demand/supply dialectic. It started in
that order, the demand having been for better collaboration or - as we may
now call it - interpersonal and intercultural interoperability. That need
not surprise (I am a South African), but interoperability in general *is*
heavily emphasized in the Scope and Purpose, and there seems to be no
dispute at all on that responsibility. So the demand horse was properly in
front of the supply cart, while the cart itself at that stage, lagging far
behind its eventual definition involving a SUO, was merely one of scientific
and mathematical method. (For the metaphor to continue fitting, we have to
imagine the cart, by now with an Internet undercarriage, eventually getting
an appropriate engine and the horse climbing into the driver's seat!)
About 5 years ago the long-evolving supply far more closely matched the by
now more generalized demand. That took place in the terms of an uncannily
SUO-based projected endproduct (There's that engine!) which I insist we
could now finish together and launch in a 6 to 12 month timeframe.
As we shall see, the fuel in that engine is harnessed human creativity, to
be gathered from throughout the widest market using some quite radical
technology. Its extreme genericity, acceptable to all, will make the most
of individual differences and insights.
Thus I have already largely designed and progressed significantly with the
programming of "Metaset", which could (from the horse's perspecive) be
called an ontology-based product. It is designed as a "Boot" product with
which an open market of millions then billions of thereby-empowered
developer/users will bootstrap itself. In other words, as a "Seed" product
in a fertile soil it will generate a flourishing exponential growth in every
domain, and primarily - of course - in the domain of ontology-based
information products.
The Metaset work-in-progress was later refined and more closely reprogrammed
towards becoming an implementation of a proposed new standard for
distributed end-user-driven applications, the "Mainstream Architecture for
Common Knowledge", or "MACK". Historically, therefore, the Metaset chicken
came before the MACK egg was abstracted out of it.
Upon launch, Metaset will thus, in our currently exceptionally fertile
market, spawn an Internet-leveraging infrastructure for the full-cycle
marketing of MACK-compliant applications, covering functions ranging from
needs awareness, through collaborative product design and implementation, to
deployment and support, thus looping back to needs awareness.
Any other kind of product will of course be marketable on it too, and much
better than over present Internet-based media. But the most spectacular
difference will be with MACK-compliant hence SUO-based information products
or applications of all Internet-leveraging kinds.
A key part of that process will be its intrinsic reflectivity directed at
its own improvement. Thus as a marketing vehicle Metaset itself will also
help exemplify, teach, propagate and evolve MACK, and be the basis and
infrastructure for its own eventual supersession by better implementations,
starting with specializations for the obviously many and varied niches.
Well fitting that role, basic MACK as an architecture for an open and
transparent market is simple and reasonably relatable to every kind of user.
So, and thanks to MACK's extreme simplicity, genericity and reflectivity,
some plain and simple database-related programming can create an adequate
basis for ensuring the correctness (though not necessarily the
appropriateness...) of implementations and compliant applications. The
presentation of relevant aspects of that database to all those various kinds
of user with their varied needs is likewise catered for in terms of MACK's
simple fundamentals (in a way which is comparable to but much easier and
more natural than XML+XSL/XSLT, for example).
Such largely self-managed correctness means that no conventional symbolic
logic is required for the Boot product (even though MACK's very essence is
logic, even "plain logic", as I insist).
But as the MACK-supported population grows, and its use of the marketing
medium grows accordingly, we shall be creating one enormous multi-agent CAS
(Complex Adaptive Systems) world, so unpredictable in its emerging
behaviour. While MACK's inherent reflectivity will help us follow such
unpredictabilities and formulate appropriate concepts in whose terms we
might identify them and incorporate them for feedback, correspondingly
enormous scalability will become a major issue. Simulations (or "possible
worlds"...) will become ever more important in helping us all keep a
democratic handle on our futures. (As usual, "The price of freedom is
eternal vigilance.") So we may be certain that more formalized and
mathematical techniques will need to have flourished by then.
In those and other ways, the Boot or Seed approach seems to accord at least
with the gist of Bill Burkett's idea as Jim Schoening took it up on 8 August
as the "Comment #1" for resolution (though as we can see, it was in
parentheses, and was rather lost in the subsequent discussion on the number
of terms to be expected in a SUO):
> (One may argue that it's possible to understand larger models
> with the aid of a meta-level organizing structure - and I agree - but then
> *this* structure becomes the upper level ontology.)
Later in his original posting ("RE: Call for vote on SUO Scope and Purpose"
of 27 July), Bill emphasized the importance of recognizing the merely
provisional nature of any SUO, commenting that:
> (5) The SUO should have some provisions for the evolution of the SUO over
time.
That touches on those thorny issues which are constantly overlooked, namely
identity, versioning and smooth migration. They have to be dealt with in an
integrated way, and not just as an added patch or afterthought, as is too
often the case. Such genes, as we shall see below, are in this Seed product
too.
I would imagine that the logical basis of the initial form of MACK as
required for a canonically-implemented Boot Metaset also accords at least
largely with Eric Peterson's idea of "Structural Axioms" which Jim took up
again on 16 August as the "Comment #4" for resolution, and as it has been
developing in that thread (though, still echoing Eric, while "inheritance
axioms, relations, [... and] range constraints" are also basic to MACK, I
warn you to ignore any further preconceptions as to both form and content of
MACK's axiom-equivalents!)
Thus I have, since 1996, been talking of "MUCK", or "Metaset Universal
Common Knowledge", which is in effect the SUO to help lead to all subsequent
interoperable ontologies. In defence of such a strange name - and
conceit! - I pleaded in these words:
"Such alleged universality is a heavy claim, so that's where the "muck"
theme comes in, with the message that it's something continously renewable,
especially with the help of creative seeds that can flourish in it. It's not
to be treated with any reverence. On the contrary, it's to be regarded as
homely, to be trodden on and trodden in, replete with associations of fuming
fertility."
(That was in [2] (and find "muck" there), but please don't follow any of
these inline references during a first reading! (I prefer to hope for a
second...) First try to trace this whole coherent outline with me.
(Meanwhile, yes, as you might have deduced from my artisanal and
agricultural metaphors, I did grow up on a farm!))
In that spirit I add that I prefer to avoid the word "ontology" because of
its historical associations and their potentially stultifying metaphysical
or idealist pretensions (and too-easy misinterpretations by absolutists or
dictators of so many kinds, now also proliferating under the wings of
e-commerce...). Thus I have referred dismissively to the "ontology myth"
[7], also to emphasize the very unconventionally-mathematical form and
function - or representation and semantics - of the nearest MACK equivalent.
I first used the term "typology", indicating a coherent set of types and
their metadata, but I have since adopted the plainer "model", implicitly
MACK-canonical, and inclusive of its MACK-canonical interpretational aspects
(See [9#epistemology], that is, point your browser to [9], and enter again
with "#epistemology" appended to the url).
So the collection of "Boot-MACK-MUCK models", if adopted in principle and
refined and completed by the members of this list, is hereby proposed as the
initial and provisional SUO that this project seems to be aiming for.
What's more, their full "Scope and Purpose", along with all "documentation",
will be expressed in canonical MACK form (greatly mutatis mutandis from the
present SUO Scope and Purpose, of course!) In that form it will be the
integrated driver of all implementations such as Metaset. There is in fact
some very satisfying epistemology in that design and consequent
reformulation, but for now I'll just add that it fulfils the expectations or
hopes of John Sowa and Mike Uschold as apparent in the thread "Formalizing
SUO Purposes" started by Mike on 18 August.
- - - - - - - - - - - -
Beyond the SUO
- - - - - - - - - - - -
But the MACK project is bolder even than a mere SUO claim implies, as a
simple example indicates. (And the bolder project is what I have in mind
for the 6 to 12-month concluding timeframe I have mentioned.)
I preface the example by recalling that Metaset's initial collaboration or
human interoperability objective has since been fully generalized to provide
for all forms of IT interoperability too. (That quality, along with
"interoperate", occurs four times in our present SUO Scope and Purpose!)
The "Comment #3" chosen by Jim on 15 August for resolution revolved around
Sofia Pinto's concern as to the relationship between a SUO and XML. In
effect, a SUO should not be unduly constrained by XML's limitations. The
MACK position (asserted already in 1997 [7]) is that it will be effectively
trivial to map XML documents to MACK models, metadata-wise and data-wise,
but that the inverse mapping in all interesting cases will be so problematic
in so many ways that it will simply not be worth it. Therefore there will
tend to be a one-way migration from an XML world to a MACK world!
(Corollary: XML is generally expected to greatly facilitate the integration
and interoperation of all legacy applications, therefore MACK will even
better leverage legacy databases and applications, and will in due course
become the architecture of choice for all distributed or Internet-leveraging
applications.)
Now that is indeed a very bold position! Even foolish, as I preemptively
suggested in the first heading ("Where angels fear to tread") of my opening
Web page in 1996 [1].
But before questioning such an exorbitant or way-out "Scope and Purpose" as
already seems implicit, let's first look at the full extent of it as it
might be gauged from these few dense and blunt points (And please do not
allow ontology-clashes to combine with author-verbosity-induced impatience
to cause jumps to easy but hasty conclusions! Rather let's find better
wording and refine our joint marketing...):
(1) MACK will be the new distributed-application or Internet-leveraging
architecture, integrating development approaches with federated repository,
database and run-time management. Metaset as an "application operating
system" will be a free and MACK-canonically Open-Source product, though
there will be some chargeable service implications, automatically
administered by MACK-compliant applications. Once initially-undertaken
marketplace functions have been specialized and spun off, there will remain
a small residual function which I have called "MUCK-cultivation"[2]. It
will be undistributable or irreducibly-central hence indivisible. (There we
see some carrots in my offer to potential close collaborators!) The
ontology-like "model" is of course the main application specification
device, but while it is obviously very mainstream in some respects - and of
course traceably "Mainstream" in most if not all respects! (For example, I
believe it fully in line with the essence of semiotics, so put forward by
John Sowa and other relevantly-deep modern thinkers such as Joseph Goguen) -
it is highly significantly different from most present conceptions.
However, its details are not set out here, on account of a motivated
trade-secret position and other provisional tactics (which I regret and beg
you to overlook provisionally).
(2) MACK will widely facilitate the substantial confluence - already
burgeoning elsewhere - between two major streams in computing, namely AI/KR
and IS/DBMS. Both will benefit enormously. (However, the present Boot
makes no claim whatever to any NLU.) The main initial MACK contribution to
both sides involves its central and vital exploitation of the notion of
"context".
(3) Conventional OO, which has tended to lie somewhere between AI and IS,
is absorbed to the extent that we shall not need to talk about it any
longer, as it becomes mere "plain logic". OO's long-proclaimed though unmet
objectives of dramatic improvements in component reusability, application
interoperability, and portability of both, will at last be fulfilled in an
integrated manner. Thus a function of Metaset as a MACK-implementation
might, in conventional terms, be called component glue and workflow
management, where the component is the MACK model. But application design
and building will be radically different, becoming far more market-based,
transparent, fast and often spontaneous. And yet it will also be
industrial-strength in operational areas such as exception-handling,
resilience, availability, resource-efficiency, application flexibility and
smooth version migration. And still it will be light and pleasing, with its
design and operational functionality well describable as "orchestrating
components and choreographing interactions." [12#NewParadigm].
(4) It is in the essence of the very structure of MACK for the entire area
of access security, privacy, confidentiality, trust, virus-proofness, etc,
to be resolved more easily and naturally (though only finally once the later
evolution mentioned in point (6) below has progressed). The resolution
springs from key MACK notions such as "context", "identity", "relativity"
and "transformation", all of which are integral to major areas as diverse as
view-mapping, message semantics, persistent storage, and transaction
definition and management. Thus also, relativity fully resolves the "rigid
properties" definition and use problems discussed in the SUO-list thread of
that name. The problem of identity too. "Identity," as Chris Menzel
comments, "[...] is a minefield." (in "Re: Rigid Properties" on 6 July) It
has indeed confused philosophers - or their pupils - at least since
Heraclitus with his well-known paradox, "You can't fall into the same river
twice." In terms of MACK's relativity, however, the very workable and
natural resolution is fully in accordance with that so-valid cliche, "It
depends on your point of view." And it is not only philosophy, it extends
down to nitty-gritty areas such as resource conflict management, where the
phrase "automatic reflective predicate-locking" well indicates the natural
approach that so well mirrors familiar manual practices.
(5) Most present distributed applications, including the Web, e-mail,
usenet and other groupware, as well as existing application packages and
underlying tools such as DBMS and UML, will start a massive migration to the
simpler and safer architecture. As already mentioned above, MACK's
similarities with XML give it the budding first-generation - or XML-based -
semantic web's ability to deal with data from legacy systems, while thanks
to the major leaps by MACK the evidently better new environment will tend to
make legacy-interfacing a one-way movement.
(6) MACK-implementations such as Metaset in effect forming an "application
operating system" as a layer above more basic host operating systems and
windowing systems, the role of conventional procedural programming languages
will be narrowed and simplified by relieving them of many system-level
requirements. Metaset is presently being programmed in plain C for
Microsoft Windows, but the design is of course completely portable and
initial launch will provoke a plethora of more complementary and fine-tuned
languages, host operating systems, and UI approaches. Particularly,
security as mentioned in point (4) above will finally be resolved in the
MACK-boosted marketplace, democratically, even naturally, via the usual
inevitable dilemmas and compromises, but without the artificial loopholes
left by present operating system architectures. Metaset/MACK's prime
function of "helping people simplify complexity" has brought with it a far
more appropriate conception of "complexity-hiding" [9]. More properly
handling complexity, from both human-engineering and technological points of
view, further enables an intelligent scalability which can build on
considerations from across the artificial barriers between the tiers of the
traditional 3-tier architecture.
(7) As a development environment, MACK does not entail a given rigid
framework as is associated with 4GLs. Its extensibility and the resulting
compliant application flexibility - and all the other "-ilities", especially
scalability in every dimension - will be dramatically higher than anyone
would realistically expect. Thanks to its inherent reflectivity, MACK will
greatly benefit from the entire "patterns" movement, and further support it
in spectacular ways.
A brief consideration of the above aspects will reveal that, together, they
will be very synergetic and self-leveraging, so there is vast scope for
rapidly exponential growth on such a basis, and across the widest
application fronts in the most general market.
All that is of course a big bill to fill. For example, what about the
familiar yet difficult and even crucial questions in the use of ontologies,
such as how divergences in theory-lattices are to be handled with due
sharing, how their unification will respect and handle "essential"
differences, and how the canon itself will provide for smooth yet safe
migration as ontology versions advance?
Indeed, all such questions remain unanswered also by glib SUO-aimed
proposals for identifying commonalities between existing upper-level
ontologies, or merging lexicons, or moving to next-generation or XML-based
EDI.
Thus I heartily endorse John Sowa's echoing (in his essay "Ontology,
Metadata, and Semiotics" at
http://www.bestweb.net/~sowa/peirce/ontometa.htm)
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fwww.bestweb.n
et%2F%7Esowa%2Fpeirce%2Fontometa.htm%29> of Simon Phipp's "Meaning
not markup" article. I have myself been quoting it since last February (In
that version of [12] (the latter is dated January 2000), my source was
http://www-4.ibm.com/software/developer/library/meaning.html,
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fwww-4.ibm.com
%2Fsoftware%2Fdeveloper%2Flibrary%2Fmeaning.html%2C> of December
1999). Phipps, billed as "Chief XML and Java Evangelist, IBM", pointed out
that it is not in commonalities but in differences where the real problems
and opportunities lie. Thus his penultimate paragraph concluded with this
sentence:
"We should not assume that XML is a panacea, nor that the standardization of
vocabularies will automatically bring interoperability. XML provides us with
a medium to express our understanding of the meaning of data, but we will
still have to first discern realities and differences of meanings when we
exchange data."
But present architectures have even deeper-lying problems. A central theme
in [12] contrasts MACK with how XML fails in its semantics pretensions by
having a merely document- or message-centric architectural approach,
necessarily going only so far as offering syntactic, tag and limited
structural commonality, with real semantics remaining chiefly in the eye of
the programmer. Even further, [12] lumps the Web's document-centric
architecture together with the self-proclaimed mainstream of
distributed-object architectures in the form of old-fashioned RPC and its
descendants such as Microsoft's COM+ or .NET, the OMG's OMA/CORBA, Java's
RMI or EJB, and XML-RPC or SOAP.
In the MACK Mainstream, however, with its extensive philosophical,
epistemological, technological, psychological, sociological and other
tributaries, those architectures are not even sidestreams: they are
deadends.
[9] even identified a programmer-psychological reason for the persistence of
those misconceived architectures and thence even of the ineffective wider
organizational structure of the software industry. Thus that paper's very
subtitle claimed that MACK would help our industry and our users "escape the
Divine Programmer Syndrome"!
MACK, on the contrary, turns that interface-based approach inside-out by
addressing the application first, and in the most generic and unprejudicing
way, as also intimated in points (6) and (7) above. Only in such a way will
we get a firm and proper handle on semantics, including data semantics and
message semantics.
Thus, as I have pointed out elsewhere (Find "Koestler" in [7]), an important
role in the design of MACK was played by that other cliche, "The meaning of
a message is implicit in its context." The way abstract or axiomatic
systems are given meaning by their interpretations was for me the original
model of that process. The consequences have been far-reaching. (I enjoy
pointing out the cliche-ridden nature of MACK, as it emphasizes The
Mainstream.)
Thus for example the way our conceptions are continually given new meanings
is central to the very functioning of a MACK world. [9#context] and [12]
(find "The detail of MACK" there) expand on the key role of
ontology-mediated creativity.) An equivalent of Multiple Inheritance is
implicit there too.
At the higher or application level, my original emphasis on interpersonal
interoperability or groupware, as related at the outset above (and as taken
as a point of departure in [8]), has expanded into inter-application or in
general inter-agent interoperability. That is most natural: natural
language message semantics, in a practical world, is likely to remain
unclear, dissipative and otherwise ineffectual (as it all too often is!) if
it is not more closely related to the associated nitty-gritty practicalities
of organizational and administrative semantics in the wider market. (As
related in [11], that was even why, in 1969, I went into IT in the first
place.)
So, to summarize, Metaset/MACK's "Boot"-based approach has followed what I
take as Bill Burkett's project, namely, as a duly-modest start to develop
that "meta-level organizing structure" which would help lead to the rest.
Then Metaset's own MACK-canonical nature is such a reflective cherry on the
infrastructurally-empowered-market cake that there can be no question that
the package seems as if it could be a promising match of supply and demand.
But, in the light of the product's incompleteness and associated
trade-secret implications, how on Earth can I expect you to believe all
that?
- - - - - - - - - - - - - - - - -
Plausibility at this stage
- - - - - - - - - - - - - - - - -
My problem is severe, but every SUOer has it too, to a degree, as possibly
confirmed by the reported lack of success in attempts to obtain funding.
Bill Burkett has perhaps faced related frustration in calling (in point (3)
of his above-mentioned posting of 27 July re the SUO Scope and Purpose) for
some answer in the Scope and Purpose to the question "*How* should the SOU
be used?"
There is no escaping that undeniable "original sin" of even considering such
a conceit as a SUO, whether or not the scope is enlarged to the extent I am
finding practical. Any SUO-like ambitions, to be worth their many troubles,
do have implications far beyond our apparently modest and down-to-earth
Scope and Purpose, so do call for serious reconsideration at every turn.
(So I also trust my various attempted self-justifications are not rather too
much...)
I do not underestimate the extraordinarily vast scope of the MACK project.
My central answer is, I think, the extraordinary genericity of MACK as an
architecture and of Metaset's MACK-compliant internals, and the way that
that favours reflectivity. But since I am not revealing such details yet, I
have to rely on two other strategems: philosophical and autobiographical;
that is (and more helpfully): abstract coherence and resulting confirmed
prediction.
I have a whole gamut of supporting philosophical and epistemological
considerations, and you may find them in all the various references at the
end. The briefest broad indication.is perhaps at [6#table]. [1] is still a
good introduction. [9] is perhaps the most complete high-level view, while
[12] points back to all the rest and is in easier language.
That abstract view is intertwined with my own story of how it has come
about. [11] sets out that story from the IT point of view, and links back
to [9] for the more philosophical and personal aspects.
I hope that the coherence of those stories and lines of argument is
apparent. However, I have suggested you not read my references yet, so I
shall try to continue by relying only on the coherence of this posting...
Fortunately, by now all that coherence in the mere abstract is further
buttressed by some empirical realities of the most significant kind, namely,
predictions, made on the basis of all that abstract coherence, and
subsequently proven true. [12#background] is perhaps the best lead-in to
them (and if you stick to that "Background" section you would not be unduly
distracted on a first reading (Otherwise, just believe me for now...)).
Those predictions were all highly relevant to the software-architectural and
broader political scene addressed. Rather unashamedly, I suggest them as
fair confirmations of my judgment from both abstract-aesthetic and practical
points of view.
However, I clearly do have to confess to this great weak point: I am
obviously not good at representing these very novel and abstract positions
to those who do not share much of my most unusual background ... and that
includes almost everyone!
So my planning has long relied on the eventual comprehensive use of Metaset
as a selling, instructional and educational medium. Hence my third echoing
of Bill Burkett (at the opening of this section). Jim Schoening - and
others on the IEEE Learning Technology Standard Committee - might take note
of the "Philosophy and Education" title of the lecture course I gave in 1975
(Find "1975" twice in [11]).
My entire strategy also relies on the launched Metaset's expected clear
superiority as a UI and platform for a marketing medium in general, and for
itself in particular. But all such planning begs its own question, that of
Metaset's incompleteness at this stage.
So let's break out from all such conundrums! There are some further
technological points that I have not made previously in public and which
might help bring out both the novelty and uniqueness of MACK, and its
central appropriateness to the emerging world that a SUO must address.
Those lines of argument can start from my above-mentioned wariness of that
word "ontology". I shall argue that words, and more specifically, names,
are the source of many of the problems with existing architectures.
[6#table] (already referred to above) confirms that central though
ambivalent attitude, and portrays many of its aspects.
More immediately, those problems are in evidence in the present
controversies at the W3C concerning namespaces (see e.g.
http://xml.com/print/2000/05/17/deviant.html),
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fxml.com%2Fpri
nt%2F2000%2F05%2F17%2Fdeviant.html%29%2C> which are clearly also
relevant to the very concept of ontologies, particularly in our situation of
wide distribution and rapid change. Naming problems are also virtually
inevitable in the message-centric nature of existing distributed-object
architectures: What does that class- or method-name mean? What does that
named parameter mean? (More deeply: What is that particular form of
"complexity-hiding" hiding? What secrets - unrecognized even by the
programmer - are hidden under the convenient guise of "encapsulation"?) The
organizational culture that had earlier implicitly fixed such meanings no
longer applies on the wildly-distributed Internet with what should be its
lively software component-integrating market. Under such circumstances
there can be no trust with the old architectures.
The core problem with names is that their meanings shift. That is even the
core of the identity and versioning problem-areas too.
Well, there is a very radical way out of that problem: the denotation of
names, like identities, must shift too! That is what we do every day in our
dealings on fresh matters. It is basic to any learning. It happens with
any creative expansion of our understanding. And of course, it is even the
very fitting resolution of Heraclitus' paradox. It is implicit in my
favourite definition of abstraction, as that which communicating partners,
or different situations, are deemed - for now - to have in common. So it is
part of the essence of the "Common Knowledge" basis of MACK. It obviously
ties in with OO's abstraction/refinement basis. And it is basic to MACK's
entire approach to commonality and difference, as already identified in the
Sowa/Phipps-triggered observations above. Furthermore, it is implemented in
terms of transformations between "relativistic viewpoints", already noted
(in point (4) above) as the handmaiden of that other core notion, "context".
But does that not place everything on a quicksand? No, quite the contrary,
and this is now the most fundamental point:
Complexity is an opportunity, not a problem,
and its abstract equivalent is interconnectedness.
And interconnectedness characterizes the "semantic web" that so many of us
are already working towards, so greatly aided by that enormous Internet. So
this is how The Mainstream of human knowledge and technology can simply
solve a whole set of artificial or non-real problems: identity is merely a
plain and familiar function of the interconnections that constitute context.
And of course, as some of the latest threads on this list are asking (cf.
John Sowa's fertile "World's largest individual organism" thread of 8
August), those interconnections must include the various users' purposes or
intentions as the users themselves are best expressing them at the
particular time and might re-express them the next moment. That is the
prime relevance for a user, and the database as a marketplace full of urgent
suppliers will as usual "help" in all such experimental formulation and
expression. And that brings us back to the philosophical or epistemological
and reality-creating function of the market, with which in this posting I
opened my introduction to my conception of a SUO. And technologically,
"relativistic viewpoints" mediate that always-indispensable
"complexity-hiding", all done in a more transparent, assimilable, reliable
and trustable way than conventional distributed application architectures
could ever hope to achieve [9].
That is why the repository/database must be lively and builtin, why the
application rather than the interface is key, and why an interface- or
source-based emphasis will not work as our total application volume,
integration, ubiquity, penetration, pervasiveness, dynamism and other
complexities increase.
Total application meaning resides in that vast and increasingly
self-descriptive database. (That has long tended to be the case, anyway,
thereby undermining those poor vain efforts via those incomplete
"interfaces".) A world-wide SUO-standard-based database is virtually a
persistent and living though extremely federated entity. (Much larger than
John Sowa's "World's largest individual organism"!) All additions and
changes are linked-in (digested!) piece-wise, and we must focus on the
end-product, not the mere changes. The creature is where the complexity
lies, rather than in its food. But such an enormous challenge can be
managed surprisingly easily by facing it and taking the bull by the horns.
It is, after all, our own creation, and the supply must be congenial to the
demand. Of course there is still interfacing between the federated units,
but the precise form of any message serializing to that end is one of its
easiest aspects.
Therefore for the viewing of that meaning, and our accommodation with it, we
need a representational tool such as Metaset with its "MVC-like" aspect and
its ever-relativistic internals. That also helps explain why I do not show
you any "MACK source": its Entity-Relationship basis, so familiar and
deceptively simple at the atomic level, does not by itself portray real
meaning in a way that would bring out MACK's uniqueness, nor does it help us
get a handle on those interconnectedness aspects, so it does not help you
see how it can be the basis of the resolution of so many problems. The MACK
metadata, still trade-secret, is unique in its interconnection and
granularity features, that is, in the molecules rather than the atoms, all
the way up to product-granularity and user-context-granularity and
shared-database-granularity. That includes all their dynamics or
time-dimensioned aspects too, which is where "relativistic context" enters
the picture. (Meanwhile, I have yet to see any "mathematical logic"
representation which gives a comparable "thinking without thought", as
Bertrand Russell has characterized the power of mathematics.)
Oh yes, such an approach invites many practical problems! The old salts
among you will immediately identify the apparent fragility of that massive r
epository/database, not assisted, for example, by any of the human-readable
debug-aid and fail-safe characteristics of the W3C markup-language lineage
with its Unix text-stream roots. So, clearly, the MACK database's practical
real-life viability demands unusual robustness and resilience. But once
again, there is a central ... intrinsic, inherent, fundamental, etc ...
consideration nailing that one: it is MACK semantics again. If the
semantics of that highly yet relevantly interconnected web is explicit and
clear, there is the basis of a usually-automatic equivalent of those
so-human coherent-context-based redundancy and meaning-recovery processes
that our communications and our memories are always relying on. A simple
form of consistency-checking-with-coherence-seeking as a basic and permanent
strategy even ensures that such resilience is the very modus operandi of a
MACK implementation. It will also help ensure the relevant spontaneity of
that more congenial and democratic market [12#ArtificialCreativity] which
will in due course evolve out there in that widest world.
Well ... sorry again! ... at this stage it is not so easy to see all that
either. But do please start now on another reading of this posting, this
time following the references, and maybe then, bit by bit, it will all start
hanging together as the coherent whole I insist it is (as it is The
Mainstream after all, in so many ways).
Anyway, it will eventually hang together for you, even though later. That
will be at the latest with a launched Metaset's help, when it will cohere,
as an altogether cogent and compelling whole, as simple and as complex as
life itself. Various natural knowledge processes have continually inspired
MACK's development and helped me ensure that it is reasonably fully in The
Mainstream of evolution, and capable of being made as congenial to everybody
as such a would-be universal standard as a SUO should inevitably and
admittedly be.
Now I just have the final tail to add: How can you or anyone else be part
of this whole exciting process now? (And help speed it up too!)
- - - - - - - - - - - - - - - - - - - - - - - - -
Some possibilities for a joint project
- - - - - - - - - - - - - - - - - - - - - - - - -
The big assumption here is that the wide logical coherence and by now quite
extensive reality-correspondence in the above, together with the references,
are sufficiently convincing for you to want to take part in the Metaset/MACK
project, or a better kind of project that you might propose as more
appropriate yet still consistent with the various needs and opportunities.
I have elsewhere insisted (at [12#ProjectEstimate], after setting the
background from [12#Start]) that if you would take me up into a small team
with a good manager and two top programmers, in a well-supported
environment, we could get a Boot Metaset into Alpha test within 3 months,
and with some further help in setting up the online service, we could launch
it in 6 months. In this posting I have applied the first part of the old
formula and doubled that to "6 to 12 months".
The context of the proposal made in [12] implied a "Plan B" approach, in the
terms of my public invitation in [10]. That foresaw one organization taking
over the project, with a view to eventual considerable direct profit and
major strategic advantage for itself. I have been mentioning an ultimately
derisory upfront price to such a company of US$2million for all the
work-in-progess and other intellectual assets, including my availability for
employment in their new project to finish and launch a Boot Metaset. That
sum would also be my insurance in case of non-performance by such a partner,
adequately insuring my own pursuit of either Plan A or Plan C (the latter
being my present solo-programming course).
As stated in [10] (under the heading "Digging together"), Plan A is my
preference. It would put everything in the public domain straightaway. I
prefer it for all the familiar Open-Source considerations such as tapping
indefinite intellectual resources and affirming intangible intellectual
values for all their immediate and wider benefits. But the usual
Open-Source precondition of a running product to start with does not
pertain. I do not regard that as fatal, however, as I believe my existing
code plus further supporting documentation, plus the extreme simplicity of
the concept in itself, plus the excitement of the entire course, so in line
with The Mainstream, could substitute for it. The very existence of this
SUO list significantly encourages such an approach. However, I still would
not want to expose everything unless I could be sure that I was not merely
casting my bread upon the waters. I cannot do that on the basis of mere
reassurances. So I would not take such a course without a comparable
financial demonstration of conviction and commitment from some quarter, such
as some public-interest body, or a consortium of such bodies, whom one or
more of you might convince and mobilize to that end. That would convince me
that my story had got across eventually, and to a sufficient degree. That
is obviously not a foregone conclusion! But without such a demonstration I
would be inviting the further dissipation of my own energies in wasteful
public involvement, possibly fatal for Plan C, and I would be precluding any
eventual Plan B.
In the event that some agreement of the indicated kind could be concluded,
such a Plan A in this SUO context might develop in this way (which is fully
in accordance with the various design considerations as discussed in this
posting):
1. With discussion remaining on this conventional list basis, and with your
advice and help, I would put my existing code plus better-tuned
documentation on the IEEE SUO website. Access to that website should - I
guess - require some contractual commitment to the MACK-canonical
Open-Source design and its successors.
2. While open discussion on this list proceeds, one or more teams springing
from this list would aim for an Beta-test Boot Metaset (or otherwise-named
MACK implementation) as a MACK-canonically designed and implemented product,
that is, it would itself be fully ontology-based (and I believe that I have
already largely cracked "that" booting problem...). This list would
presumably produce many highly-suitable Beta-test volunteers.
3. Once usable Boot products became available with basic groupware
functionality, discussion would shift to the thereby-mediated
proto-marketplace. Such collaboration should rapidly spread to code-sharing
and all the other activities on the rest of the marketing cycle. Since even
initial MACK-compliance will entail reasonable provision for smooth
interoperability and version migration, everything would take off from
there.
If I don't hit the Plan A jackpot, some negotiated Plan B would be simpler
to conclude. [12#Start] sets out one such scenario. In it find "Happy
Ending Y" to see the suggestion that that scenario might apply with little
corresponding change to other types of company too.
Or do you have any other suggestions - of any kind - as to how to take this
work further?
Thanking you all for the many insights from the list discussion so far
(and looking forward to finally understanding those I may seem not have
understood yet...),
with warmest regards,
Christopher
------------------------------------
Some Web pages by this author, most of them referred to above:
[1] http://jeffsutherland.com/oopsla96/spottisw.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla96%2Fspottisw.html>
[2] http://jeffsutherland.com/oopsla96/spotfaq.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla96%2Fspotfaq.html>
[3] http://jeffsutherland.com/oopsla96/spotcrit.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla96%2Fspotcrit.html>
[4] http://jeffsutherland.com/oopsla97/spottiswoode.html,
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla97%2Fspottiswoode.html%2C> introduced on
http://jeffsutherland.com/oopsla97/index.html#truelove
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla97%2Findex.html%23truelove>
[5] http://jeffsutherland.com/oopsla97/spottiswoodebgrd.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla97%2Fspottiswoodebgrd.html>
[6] http://jeffsutherland.com/oopsla97/SpottiswoodeByndBO.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla97%2FSpottiswoodeByndBO.html>
[7] http://jeffsutherland.com/oopsla97/spotcomm97.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla97%2Fspotcomm97.html>
[8] http://jeffsutherland.com/oopsla98/spottiswoode.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla98%2Fspottiswoode.html>
[9] http://jeffsutherland.com/oopsla98/SpottComplexity.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla98%2FSpottComplexity.html>
[10] http://jeffsutherland.com/oopsla98/SpottSimplification.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla98%2FSpottSimplification.html>
[11] http://jeffsutherland.com/oopsla98/SpottBioComp.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla98%2FSpottBioComp.html>
[12] http://jeffsutherland.com/oopsla99/Spottiswoode/MACKfuture.html
<http://webmail.juno.com/juno/ext_link.jhtml?goto=http%3A%2F%2Fjeffsutherlan
d.com%2Foopsla99%2FSpottiswoode%2FMACKfuture.html>
(And no, the major protagonists in that latest drama have not responded.
(But in its Executive Summary I did not bet that they would,
and right at the end I more explicitly cast my net wider...))