I forwarded a copy of my note of Dec 3 to the OMG AESIG forum.
It stimulated some discussion there, and following is my reply
to various notes that were posted there. (01)
John Sowa (02)
-------- Original Message -------- (03)
JA:
> ... there are lots of Sem Web orgs/developers working to address
> many of the issues being raised wrt OWL/RDF as a future technology.
> It's actually hard to imagine how ignoring that and building something
> new in OMG is going to deliver similar capability in less than 5-10 years. (04)
I completely agree. I would never suggest that the OMG should compete
with or replace the Semantic Web technologies. The OMG must support
*all* the Semantic Web technologies, current and future. (05)
PD:
> ... the backward compatibility issue is completely omitted from these slides.
> Will this force the existing tools on the market to redevelop entirely
> their infrastructure in order to support the exact same level of end user
> visible features?
> ...
> Will this destroy the so important MIWG work and the current painfully
> reached interoperability level between tools? (06)
I certainly hope not. The OMG should support compatibility with the
Semantic Web, but it must also support compatibility with its own tools. (07)
The fundamental assumption of the OWL philosophy is to *restrict*
the expressive power to a limited range of applications. It is
not possible to translate any of the following into OWL: (08)
1. OCL -- because OCL has the expressive power of first-order logic. (09)
2. SQL constraints -- because they have the expressive power of FOL. (010)
3. Many of the UML diagrams -- because UML can model structures that
have cycles, and OWL (in its current incarnation) is limited to
models that have a tree structure. (For example, it's not possible
to define a triangle in OWL -- because a triangle is not a tree.) (011)
Point #3 is a very serious limitation -- a "showstopper" as they say. (012)
Please note that Leo, Elisa, and others use OWL as part of a *hybrid*
with rule-based languages -- because OWL alone is inadequate. (013)
JFS:
>> SQL runs the world economy and most commercial web sites. SQL is
>> not going away, and any new proposal must be upward compatible. (014)
DP:
> First sentence and half the second are accurate. However most Web app
> frameworks now completely hide that fact by wrapping SQL into an OO
> paradigm to be compatible with their favorite programming language
> (e.g. Hibernate or Rails). (015)
I agree that SQL has many flaws that should be deprecated, and new
applications should avoid them. But coexistence with SQL will be
necessary for a long, long time. That means OMG tools must support
(a) interoperability with legacy software, (b) a growth path for
the future, (c) methods of reverse engineering legacy software,
and (d) methods for mapping legacy software to future systems. (016)
DP:
> ... Sem Web orgs/developers working to address many of the issues being
> raised wrt OWL/RDF as a future technology. It's actually hard to imagine
> how ignoring that and building something new in OMG is going to deliver
> similar capability in less than 5-10 years. (017)
Yes of course, and definitely! (018)
Since OMG must support *both* its own tools and the technologies of
the Semantic Web, the foundation logic must be a *superset* of both.
OMG doesn't have to develop it because there is already a standard
that meets the requirements -- ISO 24707 for Common Logic. (019)
There is already an OMG project that demonstrated the ability of CL
to specify the semantics of UML diagrams -- a task that OWL cannot do: (020)
http://www.omg.org/spec/FUML/1.0/Beta3/ (021)
There is also a superset of Common Logic, called IKL, which was
developed under DoD contracts and verified for interoperability
by round-trip tests that are more demanding than anything we have
been discussing. See the following report: (022)
http://nrrc.mitre.org/NRRC/Docs_Data/ikris/IKRIS_Evaluation_Report_31Dec06.doc (023)
JFS:
>> Common Logic, by default, is untyped, but it supports restricted
>> quantification by allowing monadic predicates to specify the
>> range of quantification. That supports a version of weak typing,
>> in which type violations cause the sentence (or clause) to be
>> false rather than syntactically invalid. (024)
RM:
> Would you be able to say what advantage is gained? On face value strong
> typing would seem to have support. Would you be able to provide a
> pointer to papers that elaborate on this approach to type systems? (025)
A system with weak typing is more general than a system with strong
typing. Z notation, for example, has strong typing. Anything stated
in Z can be mapped to CL, and from CL back to Z. But it is not
possible to map an arbitrary statement from CL to Z, because it
might not fit the tighter constraints of Z. (026)
It is true that strong typing, which can be checked statically, can have
some advantages in efficiency. However, the Z constraints (or something
similar) can be enforced on CL statements, if desired. Such conventions
would allow a static type checker to verify that those constraints hold
for a given collection of CL statements. (027)
In short, CL can support tools for static type checking (as in Z),
but it can also be used to support dynamic type checking. (028)
RM:
> But Russell's paradox is a paradox of sets. And the Kleene-Rosser
> paradox on the untyped lambda calculus led to the development of the
> simply typed lambda calculus. And a lot of great work followed that. (029)
There are many related paradoxes. My example showed (a) a similar
kind of paradox can be stated in terms of types instead of sets
and (b) the CL semantics avoids those paradoxes. (030)
I agree that some interesting theoretical work has been done with
many different variations of lambda calculus. But I am not aware
of any practical applications that require expressive power beyond
CL + IKL. If any exist, I'd love to see them. (031)
RM:
> Wouldn't OWL and FOL be precluded under 2) [System F] above ? (032)
I was claiming that CL is a superset of System F, and CL has
already been shown to be a superset of OWL and FOL. (033)
In any case, Common Logic and/or CL+IKL can represent a superset
of all the Semantic Web languages plus the OMG modeling languages.
OWL can't even be used to represent the full range of languages
that are being used for the Semantic Web. (034)
Following are the slides of an invited talk I presented at the
RuleML conference in October (which also included fans of other
rule-based languages such as RIF and SBVR): (035)
http://www.jfsowa.com/talks/clruleml.pdf (036)
CBC:
> One of the reasons for a UML centric option is to build on the existing
> assets and experience of building language specifications in UML.
> ...
> The primary alternative is to build on the semantic web and ontology
>technologies. (037)
There is a third alternative: To adopt a superset that (a) can
represent anything from the past or present and all known plans
for the future, (b) enable them to coexist and interoperate,
and (c) support an open-ended path of innovation. (038)
AC:
> ... our proposal is for the OMG/AESIG to support two parallel,
> independent, and collaborating paths, one incremental and one leaping. (039)
First of all, an OWL-based plan is not "leaping". It's a dead end that
can't even support the full range of Semantic Web languages. That's
why I was invited to present Common Logic at the RuleML conference. (040)
Common Logic was designed to support *everything* in an integrated
fashion. The IKL project extended CL and showed that IKL could
support interoperability among systems that are far richer than
anything that has been done with OWL or FOL. (041)
Bottom line: Common Logic is being considered as a foundation for
rule-based languages for the Semantic Web because OWL is inadequate.
Any leap should go forward, not make us fall on our face. (042)
John (043)
_________________________________________________________________
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 (044)
|