Randall and Ian, (01)
I have some agreements, disagreements, and qualifications to your
recent notes in this thread. And I'd also like to include a note
below, which I contributed to a discussion on an OMG email list. (02)
RS> UML is a language for modeling systems. The diagrammatic portion,
> as popular as it is, is really not the essence of UML. (03)
IB> I'm afraid I've got to disagree with you. When you look at how
> UML is actually *used* all you can really say about it is that
> it's a notation. The diagrams *are* the essence of UML because UML
> is used for so many different purposes (e.g. data modelling,
> software modelling, system modelling, military architecture,
> services, ontologies, etc.) there is little in the way of common
> semantic across the various uses of the language. For particular
> uses of it (e.g. UPMS, MODAF M3, SysML, etc.), there may be
> formal semantics, and even some ontological commitments (e.g.
> SysML and MODAF M3 commit to physical entities in the real world),
> but for UML in general, you'd be struggling to find a common thread. (04)
I agree with Ian on this point. Any notation can be used in an open-
ended number of ways, and it's essential to distinguish the notation
from the way it is being used. That is one of the main themes of the
note below. (05)
RS> Diagrammatic languages and other visualization schemes appeal to
> a very large majority of humans 'cause of our outsized visual cortex,
> but ultimately visual languages very limiting. They scale very poorly,
> which is a large part of why visual programming languages have never
> gotten any traction beyond a few limited settings. (06)
I agree that human factors are an important aspect of any notation,
graphic or linear, starting with face painting, rock carving, on up.
But there are many other contributing factors: (07)
1. Technology. How well does the notation lend itself to varying
methods for reading, writing, and transmission? Consider the
development of cuneiform with clay tablets, Chinese characters
with different media and writing tools, European fonts with the
printing press, and recent computer displays and I/O devices. (08)
2. Algorithms. Consider the enormous simplification of human
computation with Hindu-Arabic numerals instead of Roman numerals.
But Roman numerals are still preferred for movie copyrights
because they can better disguise the age by flashing MCMXCIV
instead of 1994. (09)
3. Structure. Some notations have a simpler mapping to and from
the subject matter, including the relations among the elements.
Tables, for example, are a hybrid graphic-linear notation that
use the rows and columns to highlight certain relationships.
The structure can also have a major effect on the choice of
algorithms -- spreadsheets, for example. (010)
Point #3 about structure is key to the human factors of the various
UML diagrams and to the reason why there are so many of them.
Each diagram highlights one or more kinds of relations among the
elements, but there are too many different kinds of relations for
any single diagram type to highlight all of them equally well. (011)
Randall's point that graphic notations "scale very poorly" depends
on what is being scaled. If the cost of paper is a major concern,
then linear notations have been far better than graphic notations
for centuries. With computer displays, the cost is less important,
but there are still human factors of organizing huge graphs (but
organizing huge amounts of linear notations also creates problems). (012)
Some notations, such as LISP and XML, were deliberately designed
around the algorithms for processing them. Petri nets reflect
both the structure of the processes and the algorithms for
computing them. Frege's Begriffsschrift and Peirce's existential
graphs were designed to support different proof procedures.
See Section 3 of the following article on that point: (013)
http://www.jfsowa.com/cg/cg_hbook.pdf (014)
That article also shows the use of different notations for conceptual
graphs: The linear CGIF takes the same amount of space on the printed
page (or computer storage) as CLIF. The graphical display form has
a direct mapping to and from CGIF, but has some advantages in human
factors for graphs of reasonable size. And the pure graph form has
important computational advantages for certain algorithms. See (015)
http://www.jfsowa.com/talks/pursue.pdf (016)
John (017)
-------- Original Message --------
Subject: Re: Common Logic Foundations
Date: Thu, 25 Feb 2010 17:58:34 -0500
From: John F. Sowa <sowa@xxxxxxxxxxx>
To: architecture-ecosystem@xxxxxxx (018)
Jim, Cory, and Andre, (019)
I agree with Jim's opening point with qualifications: (020)
JA> As a practical matter, OMG has to specify a standard exchange
> format for modeling languages, as model interchange between tools
> is one of the key requirements and value propositions. I believe
> however that information integration has much higher value than
> just information interchange between tools that do the same thing.
> Information integration implies exchange, but exchange generally
> doesn't address integration. (021)
The knowledge is more fundamental than any notation. (022)
JA> I agree with your point that multiple exchange formats will be
> required. So I don't really think it matters that much which one
> is picked as the normative standard. XML is as good as any I suppose. (023)
The point I was making is that notation is part of the secondary
architecture, not the primary architecture. The primary architecture
should be totally independent of any notation of any kind. There
is no need to choose *any notation* as normative -- but there can
and should be an open-ended family of recommended notations, which
anybody could extend as needed for any purpose. (024)
XML is fine for many purposes. But any choice of notation tends
to bias the semantics. See slides 1 to 5 of the following talk: (025)
http://www.jfsowa.com/talks/cl_sowa.pdf (026)
Note the many different ways of saying "A cat is on a mat" in slides
2 and 3. And note slide 5, which shows that the Big Blue Box is
independent of any of the notations that link to it -- but it
defines the semantics of *all* of them. (027)
I strongly agree with Cory's point: (028)
JFS>> When you get to semantics, the difference between a graph
> representation and a table representation is totally irrelevant. (029)
CC> Perhaps from a semantics point of view they are equivalent, but
> not from an information management point of view... (030)
Absolutely. I can't emphasize that point strongly enough. (031)
CC> ... in that the way tables are (typically) used they are very
> closed and overly structured - exactly the problem we are having
> with more flexible and integratable language definition. (032)
Yes, indeed. And that is a second point I want to emphasize: (033)
Language developers are always tempted to mix so-called "practical"
information with the semantic information. (034)
The practical issues are of the utmost importance for any application.
But the following point is another fundamental principle: (035)
So-called "practical" considerations for one type of application
may be totally *impractical* for other kinds of applications. (036)
That is why it is essential *not* to mix the two kinds of information.
If we have any hope of developing a universal knowledge representation
for *all* applications -- past, present, and future -- we must recognize
that point: different applications that use the same knowledge may use
it in totally different ways. An "optimization" tailored for one kind
of application may be a hopeless disaster for another kind. (037)
One example of this point is the choice of RDF(S) and OWL by the
Semantic Webbers. Those are fine languages for what they can do.
But their proponents have led people to think that those languages
are adequate for all applications of ontology. (038)
In my earlier note about the distinction between model checking
and theorem proving, I noted that the SemWebbers are correct in
saying that full first-order logic can be inefficient for theorem
proving. However, note that model checking for FOL can be very
efficient (polynomial time at worst, and linear or even logarithmic
time for many practical cases). (039)
As an example of model checking, I cited the use of full FOL for
database constraints and queries. Those techniques have been
routinely used in efficient ways in RDBs for many years. They
could also be used for the SemWeb -- except for one minor flaw:
RDF and OWL are too limited in their expressive power to take
advantage of the opportunity. (040)
That is just one of many examples of the short-sighted kinds of
"practical thinking" done by people who are looking at a single
kind of application. For further discussion, see (041)
http://www.jfsowa.com/pubs/fflogic.pdf
Fads and fallacies about logic (042)
By the way, that paper was published in a journal edited by
Jim Hendler, who has been a very strong proponent of the
Semantic Web. Jim liked the article very much, because I
made an effort to be fair to all points of view. (043)
Fundamental principle: The semantic foundation must support
any and every possible application -- past, present, and future.
That implies that "practical" considerations and the knowledge
representation must be clearly distinguished. (044)
AC> What is the issue at stake here, adopting JSON because Google
> uses it or adopting RDFS because it sounds cooler than MOF, as it
> has the word "semantics" attached to it? Is it not figuring out
> the best paradigm to model and manage knowledge so that we can
> integrate modeling dialects and provide knowledge modelers and
> modeling tool developers with effective long term standards? (045)
I strongly agree that we must look for "the best paradigm to model
and manage knowledge." That is why we must support every notation
that anyone has ever found useful and avoid any bias toward any
specific preferences that various groups have expressed. (046)
AC> XML is the one that best meets all your requirements, better
> than RDFS. (047)
I certainly agree that XML is better than RDFS. But any choice
of notation is a *premature optimization*, which as Don Knuth and
others have said many times, is "the root of all evil." (048)
John (049)
_________________________________________________________________
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 (050)
|