Alex, many thanks for your considerate and also thoughtful comments. (01)
But you have led me to give in to the temptation to ignore my resolve
(in my reply to Ed two days ago) to lie low until I have got that "5th
instalment" out! However, I do give in because you have elicited some
further useful background to that instalment. So thank you for the
prompt. (02)
> 1. AOS - any design document should be fine. I know one guy brave
> enough to create OS on his own. Do you think he should read
> installments? (03)
I will of course be saying a lot more about the role and function of
the MACK AOS (and more specifically my W.I.P. "Metaset" program,
intended to become the first such AOS). But that will mainly be after
the 5th instalment because its function will be much clearer then. (04)
I can however already say something on what is not its function. It
is designed to sit on top of a lower-level OS which handles the basic
resources of memory, cpu and i/o. That includes low-level window
management and transport-layer comms as well as session-level id- and
security-management. (05)
But the AOS does address application-level issues such as database
management, application initiation and control, window set-up and UI,
application framework-like functionality and broader or
application-level id- and security-management. (06)
Of course that sounds like a whole lot more than I should ever have
embarked on. But on such matters I can start by echoing, in respect
of myself, Duane Nickull's handy statement in his latest post to this
thread (Thanks Duane!): (07)
DN:
> If I said I knew the answers, I would be both arrogant and
> demonstrating a lack of understanding of the full complexity. I am
> more of a cowboy coder just code the next step then sit back and
> see what happens. (08)
So how can I escape the downsides of the cowboy label without merely
invoking "agility"? (though the word would certainly seem more than
somewhat incongruous in this particular long-running case!) (09)
The answer lies in the "Boot" or "Seed" label also on the AOS, whether
it's Metaset or any other initial AOS. The idea, as in the Open
Source movement, is to leverage the universal Internet by providing
for the MACK-compliant software market to bootstrap itself, and that
market naturally includes the AOS itself. I'll expand in detail on
that plan in later instalments. You will see how that market-seeding
and -bootstrapping will be greatly facilitated by the builtin
MACK-canonical and open-source IDE already targetted by Metaset as an
integral part of its core functionality. (010)
So this cowboy is merely planning to see what the open market does
with Metaset. His confident expectation is that that market will
rapidly get running with it. That's another reason for calling the
resultant medium the "Democratic Web". It assumes people generally
have their eyes open for how best to serve their own interests, and
are also able to adjust to what other people by their actions in
effect clearly vote as superior to other offerings, taking both
short-term and longer-term considerations into account. ((That
idealism, and its soon-to-be-proven realism, will shock lazy
politicians too.)) (011)
Another mitigation of the apparently exorbitant scope of my project is
this quote I have been using for years. It's from Heinz Zemanek, a
past chairman of IFIP: (012)
"An architect does not tell people how to live. He creates an
environment in which people can live their own lives creatively." (013)
> Why not create project on sourceforge.net? (014)
Some answers: (1) Metaset needs to be a more comprehensive bundle of
functionality before that would be productive. (2) With the MACK AOS'
builtin functionality it will itself be a far better open-source
environment and platform than sourceforge, as will become clearer
after some more instalments. (015)
> 2. You wrote "so my question to you related to software engineering,
> which is where those programmers enter the picture while you would
> keep them away from ontologies, and for very relevant reasons too."
>
> Consider DB engineering - is this a software engineering? For me it
> is a very special kind of practice. (016)
In a MACK world it will be difficult to separate the two. Both will
be ineradicably ontology-based or at least ontology-framed. (017)
> but answer itself may be:
>
> 2.1. Programmer needs language to query ontology. Well, now it is
> SPARQL. A language to manipulate I don't know for OWL. May be
> manipulating with RDF-triples is enough. (018)
Two interim comments: (A) With a running MACK AOS, as you might soon
be able to see better, some good advice at the beginning may be to try
to forget everything you have ever learnt about programming, dbms, db
query and automated inferencing. (B) On RDF-triples, you have
reminded me to go back to John Sowa's recent reply to my last reply to
you: (It's now at this point in his archived post:
http://ontolog.cim3.net/forum/ontolog-forum/2008-08/msg00048.html#nid022 -
and thanks John too!) (019)
JS quoting me (to you):
>> So what needs to be added to ontologies so that they can be
>> relevant to software engineering, yet without bastardizing that
>> essence you so rightly insist on?
>
JS reply:
>The short answer is "integration". But integration does *not* depend
>on adding something, but on removing barriers between different
>components and different ways of thinking about them.
>
>For example, there was no excuse for building RDF(S) on triples, when
>there had been 30 years of implementing and using n-tuples in the
>tables of RDBs. (020)
On that last point I can try to sidetrack John's fear by noting that
on that score Metaset internally is at present certainly closer to RDB
than to a typical RDF triple-store. Even logically, in the way joins
are applied automatically, it is more RDB-like. (021)
On John's first point, yes - certainly! - "integration" is the name of
the MACK game, only it has merely happened, in the normal MACK
need-meeting course of events, rather than having been a conscious
strategy. Though maybe in its ingratitude another word applies
better: "revolution". And I shall enjoy showing how that is not at
all incompatible with its "Mainstream" claims. On the contrary, it's
its truly Mainstream nature that will make it revolutionary ... and so
ride-able. (022)
> And I really think that DBs will evolve to ontologies. (023)
Yes, I agree, as a broad historical generalization. But in the MACK
future the direction will switch around, with the DB remaining
implicit and generally invisible to users, even with their application
developer hats on. But DB development will advance amd evolve more
rapidly on a properly Ontological foundation. (024)
> 3. You wrote "for me the Semantic Web should be about software
> engineering, and the W3C's famous "layer cake" certainly seems to
> present a long-hoped-for outcome of a major software engineering
> effort, or two, or many, and to want to provide for indefinitely
> more such efforts by developers everywhere"
>
> For me this "cake" has too much "fat" of software technology and
> only one math "berry" (hidden inside;) - Description Logic. (025)
Oh, no, I wasn't approving of the W3C's Semantic Web notion -- far
from it! I was merely pointing out that the W3C does seem to pitch it
into the SE arena at least as much as into KE, and you had most
interestingly suggested banning programmers (and maybe thereby others
in SE?) from drawing up ontologies. But I also think - as you seem
to - that that cake will never be realized. (026)
> Any child after 5 can ask questions and accept answers. Imagine that
> it is not only you but "Web" talks with him;)
>
> We'll get very educated population, I think;) (027)
I agree fully! (028)
Christopher (029)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (01)
|