Mark, Rich, and David, (01)
On the technical details in this thread, I agree with Pat.
But there are a huge number of design issues and wishes
bound up in very complex ways. Some fundamental comments: (02)
1. Complexity: An unfortunate aspect of large systems and standards
for them is that they put far too much into the core. The result
is a huge blob with an overwhelming amount of parts, details,
and terminology for them. (03)
2. SBVR: This happens to be the issue of the month, and it's
as good an example to start with as any. But the same issues
and complaints arise with large systems of any kind, including
operating systems, database systems, Semantic Web, etc., etc. (04)
3. Onions and layers: The single most important paper on how
to design a large system was Dijkstra's 1965 paper about the
T.H.E. operating system. All the commercial vendors said that
it was unrealistic for large systems. But of all the major
systems today, the most successful are the ones that come
closest to preserving the onion structure: BSD Unix is the
core of all the Apple systems, and Linux is the core that
supports the largest supercomputers, the largest server farms,
and the majority of cell phones. (05)
4. User interfaces: People once complained that Unix was
"user hostile". Ironically, the most user-friendly systems
today are based on some version of Unix. Systems that try
to put "user friendliness" into the core end up with a complex
mess that is unfriendly for both users and system developers. (06)
5. Implementation: Ad hoc changes in the core for some special
purpose are always a mistake. Windows NT version 3.5 had a clean
core (based on the OS/2 design). But Bill G. insisted on putting
the screen handler beneath the core for "improved performance".
As a result, NT 4.0 and all its successors are less secure and
more crash-prone. By contrast, the original Macintosh had a
great user interface supported by unmaintainable spaghetti code.
For the NeXT system and Mac OS/X, Steve J. built a better user
interface on top of BSD Unix. That decision was better for both
end users and system developers. (07)
ML
> The intended user set of both SBVR and the Date-Time Vocabulary
> is business analysts and maybe some business people, not
> philosophers or physicists. (08)
That excuse inevitably leads to disaster. Users never see the core,
and putting the user's point of view into the core helps nobody. (09)
It's interesting that you mentioned physicists, because Dijkstra
had a PhD in physics. That may have enabled him to see that what's
under the covers need not resemble the user interface in any way. (010)
RC
> Why solve problems that have already been solved another way for
> the calculated dates, times and durations? The only reason that
> occurs to me is based on inference or other logic. (011)
To answer the first question, there is an open-ended variety of
different ways of representing time. Any standard for dates and
times must support *all* of them and relate them to the common
conventions used in programming systems and everyday language. (012)
For the second point, logic is simpler and more general than any
programming language. Anything you can represent in any program
can be defined in logic in a way that's independent of the many
constantly changing features of NLs and programming languages. (013)
DW
> To my way of thinking, July is the name of the (infinite) set
> of all time intervals that can be classified as overlapping with
> the month of July in any year. (014)
That's one possibility, which may be useful for some applications.
But all applications should be able to share data that says
"The US Declaration of Independence was signed on 4 July 1776." (015)
Different systems with different "microtheories" and different
legacy software must accept data at that level of detail and relate
it to whatever reasoning or computational methods they use. (016)
Fundamental principle: Every large system of any kind must be
built on a very clean and simple logical core. That core should
*support* all the languages (natural and artificial) above it,
but it should never *depend on* the details of anything above. (017)
All the complexities of SBVR, Windows, the Semantic Web, and
many other system are the result of violating that principle. (018)
The SW layer cakes, for example, put XML, RDF, and URIs in the
foundation, and they put logic on top of them. That decision was
a mistake, and the W3C keeps redefining that so-called foundation. (019)
Notational and implementational details change constantly,
but the semantics of FOL has not changed in over a century. (020)
John (021)
_________________________________________________________________
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 (022)
|