Christopher, (01)
I sympathize with the basic idea: (02)
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)
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. (04)
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. (05)
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. (06)
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. (07)
Following is a note that I sent to the OMG list on these issues. (08)
John (09)
-------- 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> (010)
Folks, (011)
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. (012)
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)
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: (014)
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. (015)
The goal of breaking out of the SCS is hard to formulate
in an RFP. I can't quarrel with the following point: (016)
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. (017)
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. (018)
For the Semantic Web, the only architectural document was
Tim Berners-Lee's layer-cake diagram: (019)
http://www.jfsowa.com/figs/timbl.gif (020)
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: (021)
http://www.epimorphics.com/public/presentations/ldapi/egov-presentation.html#(1) (022)
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: (023)
http://xlwrap.sourceforge.net/ (024)
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. (025)
This brings me back to a mantra I keep repeating: (026)
If you want people to be virtuous, you have to make
virtue the path of least resistance. (027)
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. (028)
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. (029)
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. (030)
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. (031)
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. (032)
John Sowa (033)
_________________________________________________________________
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 (034)
|
