John, thanks for all the warnings and hints from over a week ago.
My responses are inline below. (01)
----- Original Message -----
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
To: <ontolog-forum@xxxxxxxxxxxxxxxx>
Sent: Sunday, April 18, 2010 7:12 PM
Subject: Re: [ontolog-forum] Re Foundation ontology, CYC, and Mapping (02)
> Christopher,
>
> I sympathize with the basic idea:
>
> CS> "MACK" (my long-time though bad acronym for "The Mainstream
> > Architecture for Common Knowledge" which I am still working
> > to pitch to this list in an acceptable way)... (03)
You sympathize with that? I can't say I have the impression that this list
doesn't follow _your_ admirably clear expositions! Anyway:.. (04)
>
> Most people have no clue about what happens inside the hardware
> or software of the computers they use every day. The architecture
> that supports a knowledge-based system will be just as invisible
> to 99.9% of the people who use it every day. (05)
My expectation of MACK-realizations is not far different from that: most of the
time (whether 99.9% or 90% is immaterial here) the architecture will be
invisible. But for most of the remaining minority of cases the accessible and
constructively helpful architecture will make all the difference. That will be
when the user wants to discover and take better control of his or her own
destiny rather than be a mere cog in someone else's machine (or wear a face
drawn with fixed lines, or be drawn badly into books written by others).
That's
a key one of the carrots I refer to below. (06)
>
> CS> So perhaps my point is that one must not go overboard in
> > "lattice-ifying" our most basic ontologies? Perhaps there is
> > no harm in assuming a wider and still universally-acceptable
> > degree of commonality? Wider bases of agreement can uncomplicate
> > more detailed discussion where it is more important.
>
> The lattice is just a way of looking at the relationships among
> theories. By itself, it imposes no constraints on what is being
> related. I wouldn't even mention the more esoteric issues in a
> user guide to the tools and methodologies we propose or develop. (07)
I agree strongly with the principle of the lattice of ontologies. A similar
notion is even implicit in the MACK-canonical networking I have long foreseen
(though the initial form would be tighter than what you seem to have in mind).
But I do expect that a large amount of Common Knowledge, given a suitable
online
environment, will soon crystallize out and form a wider and higher platform for
more effective collaboration and discovery of difference. (08)
>
> On the OMG list, which is dealing with related semantic issues,
> the SCS (Small Community Syndrome) was discussed. By a yardstick
> that makes the OMG small, Ontolog Forum is tiny. For the SIO
> project, I've been searching for a common basis that is able to
> support both while being acceptable to a much larger community. (09)
I've been insisting on the Web since 1996 that universality is my target. That
aim must of course be implicit in any apparent conceit that claims to identify
and leverage some supposedly universal phenomenon labelled as "The Mainstream"
in a fully inclusive sense! (010)
>
> Following is a note that I sent to the OMG list on these issues. (011)
My comments are embedded in it below: (012)
>
> John
>
> -------- Original Message --------
> Subject: Re: SCS (small community syndrome)
> Date: Sun, 18 Apr 2010 12:32:59 -0400
> From: John F. Sowa
> To: AESIG <architecture-ecosystem@xxxxxxx>
>
> Folks,
>
> As I was going through several threads on this list, I kept
> thinking about how they relate to SCS. No matter how perfect
> and glorious we design the grand vision, it will be irrelevant
> if it is ignored by everybody outside a tiny community.
>
> The issues of listing requirements and defining what is a
> modeling language are important. The idea of getting very
> clear about the big picture and presenting it accurately is
> also important. The goal of a smooth migration path from
> where we are today to where we should be going is essential. (013)
Coincidence (or maybe not...): smooth migration is also stated repeatedly as a
requirement (and strong feature) in my various web pages going back to 1996.
However, I have emphasized that data migration will be much easier than process
migration, though I have added that process conversion will tend to be the
preference, given the process support in the envisaged new "application
operating system" environment. (014)
>
> But none of that will matter if we don't have a strategy for
> breaking out of the SCS. The following suggestion is OK as
> a design strategy, but it doesn't address the legacy data
> *or* the legacy implementers:
>
> JA> We need to balance open and closed world. We do that by
> > establishing our scope - closing the world - in order to
> > be able to focus on something achievable that addresses
> > a specific set of concerns that drive business value.
> > These concerns should be captured in the RFP requirements.
>
> The goal of breaking out of the SCS is hard to formulate
> in an RFP. I can't quarrel with the following point:
>
> JA> But we need to be smart. We recognize that we live in
> > a rapidly changing global, networked context. So we should
> > leverage effective information sharing concepts in order
> > to address our specific set of concerns in the chosen
> > domain, scope, time horizon and level of detail.
>
> I'd like to cite three examples of things that grew rapidly:
> Spreadsheets, AJAX, and Linked Data. All three have good
> user interfaces and well-defined APIs. Programmers latch
> onto those features very quickly. They'll ignore semantics
> unless they find an immediate use for it.
>
> For the Semantic Web, the only architectural document was
> Tim Berners-Lee's layer-cake diagram:
>
> http://www.jfsowa.com/figs/timbl.gif
>
> Many of us have complained that the upper levels should have
> been the foundation. But the highly successful Linked Data
> gang latched onto just those bottom layers (Unicode, URI,
> XML, and RDF). And some people are now making it possible
> to ignore the RDF and use JSON or even CSV:
>
>
>http://www.epimorphics.com/public/presentations/ldapi/egov-presentation.html#(1)
>
> My initial response was negative because they had no semantics
> of any kind. But I now realize that any migration path will
> require such tools. I followed some of the pointers from
> that site, which led me to XML tools for handling CSV, JSON,
> and spreadsheets:
>
> http://xlwrap.sourceforge.net/
>
> Long before the Semantic Web, spreadsheets undermined the power
> of the DB Administrator. Large enterprises faced a culture clash
> of corporate databases tightly controlled from the top down by
> DB administrators, while thousands of employees who couldn't
> spell DBMS were feeding them spreadsheets from the bottom up.
>
> This brings me back to a mantra I keep repeating:
>
> If you want people to be virtuous, you have to make
> virtue the path of least resistance. (015)
That's a good one. And here are some related positions from my old papers on
the web: (016)
1. MACK is for people as they are, not as we may wish them to be. (017)
2. People do not resist change. It is confusion that repels. (018)
3. Of the "sticks and carrots" cliché, I prefer to emphasize the carrots of
simplicity, relevance, and naturalness or congeniality, all in the sense of
appropriateness of control, in its turn cultivating self-confidence in the use
of the medium. (But more words on such lines don't help much: it's the system
in action that will convince -- so I must get on with it! ... though first I
must sketch the broad picture, as I'm trying to do at the moment with my
soon-revamped website.) (019)
>
> People aren't going to use, insert, or even understand
> semantic metadata unless it helps them do their job.
> Any methodologies that define, develop, verify, organize,
> and use the semantics must be integrated with the tools that
> people (developers and users) find convenient and familiar. (020)
Yes indeed, and it is salutary for us on this list to consider these figures
from Scott (Agile) Ambler's recent results from his survey on Enterprise
Architecture in practice (see
http://www.ambysoft.com/surveys/stateOfITUnion201001.html), and in particular
these figures on the takeup of platforms and strategies: (021)
* Service Oriented Architecture (SOA) 65%
* Common Frameworks 55%
* Business Process Management (BPM) 52%
* Components 43%
* Software as a Service (SAAS) 37%
* Product Line Architecture 31%
* Cloud Computing 22%
* Semantic Architecture 14% (022)
>
> I've been talking about a lot of esoteric logic and math,
> but I also appreciate the value of simple, readable diagrams.
> Of all the UML diagrams, the two oldest are still the most
> widely used: type hierarchies and E-R diagrams.
>
> Type hierarchies were drawn by Porphyry in the 3rd century AD,
> and E-R diagrams evolved from Bachman diagrams in the 1960s.
> The other diagrams are important, but those two are sufficient
> to specify RDFS and the core of any ontology in Common Logic.
> To supplement them with a linear notation, I'd recommend
> Controlled English instead of OCL.
>
> Instead of resisting the Linked Data crowd, we should co-opt them.
> We can help them support type hierarchies and E-R diagrams in their
> tools. They can map those diagrams to RDFS, OWL, or Common Logic.
> Other tools can relate vocabularies and terminologies to those
> diagrams and add more UML diagrams as people see the need for them.
> Controlled English could be introduced as structured comments with
> tools that link the words and syntax to the vocabularies and UML
> diagrams.
>
> I definitely do *not* want to give up the grand vision of
> representing and using well-defined semantic knowledge. But
> there must be an incremental strategy for building tools that
> bring the much larger community from where they are today to
> where they find it easy and natural to use the great semantics. (023)
100%, allowing subjective interpretations of "incremental"! (024)
Christopher (025)
>
> John Sowa
> (026)
__________ Information from ESET Smart Security, version of virus signature
database 5068 (20100428) __________ (027)
The message was checked by ESET Smart Security. (028)
http://www.eset.com (029)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (030)
|
