Re: Contexts (was Classes vs. Instances)
Hi folks,
the only benefit I've got from SemWeb ontology languages like RDFS
and OWL is that they use frames, or class-property inheritance. It
is easier for a normal person to create an ontology with a
frame-based ontology editor than by using SQL tables. Sure, the
idea of frames existed long before SebWeb, but after working with
a large and messy SQL database for two long years, I would welcome
a frame-based SQL editor. That would surely help to build and to
use a database, since SQL databases are (imho) very much easier to
apply than RDF databases. I mean that when you have the data in a
SQL database and you understand its structure, it is very much
easier to get the data out of it and to use it in an application
than to get data out of an RDF(S) database, even though it is
easier to understand the structure of a frame-based database. SQL
tool are just so much better to date.
Adopting Popper's view that science proceeds towards the optimum
through learning from mistakes, then SemWeb languages have at
least two good features: they are frame-based and they are easily
shareable. I'd be better off with SQL that would accommodate these
two features. Then again the errors of RDF appear while one is
trying to use an RDFS ontology by working with e.g. JENA. It is
slightly amusing, but mostly painful.
A. Styrman
Quoting "John F. Sowa" <sowa@bestweb.net>:
> Folks,
>
> This discussion about the problems of adding context information
> and other features to OWL illustrates some fundamental principles:
>
> 1. A notation that is deliberately restricted in order to
> facilitate one kind of algorithm is not likely to be
> particularly good for purposes other than the one that
> the notation was specifically designed to handle.
>
> 2. OWL and other DLs are optimized for one kind of inference
> engine. Prolog, SQL queries, and some rule-based systems
> are optimized for backward-chaining inference engines.
> CLIPS, SQL triggers, and other kinds of rule-based systems
> are optimized for forward-chaining inference engines. Still
> other notations are optimized for other kinds of inference
> engines, statistical methods, learning methods, etc.
>
> 3. Although I have often been critical of some of the design
> choices underlying Cyc, I do support their idea of letting
> the knowledge engineers focus on representing knowledge in
> the most natural way for the application domain, and not
> forcing them to suboptimize their representation for some
> particular algorithm.
>
> 4. The differences between different versions of logic, such
> as propositional logic, Aristotle's syllogisms, binary
> relations vs. n-ary relations, description logics, Horn-clause
> logic, first-order logic, higher-order logic, modal logics,
> metalevel logics, context logics, etc., can be recognized
> very quickly and efficiently by a simple syntactic analyzer.
>
> 5. There's no need to force users who don't know logic very well
> to anticipate what inference engine should be used for their
> problems and to shoe-horn their thinking into some predefined
> pigeon holes. Instead, let them use the form of expression
> that is the most natural for them. Then let the computer
> analyze those expressions and select whatever subset of logic
> and whatever inference engine is suitable for the problem at
> hand. In fact, it's possible to have a dialog in which the
> users and the system negotiate and modify the representation
> through a cooperative design collaboration.
>
> 6. That is roughly what Cyc does: provide a very general notation
> that is supported by a variety of different inference engines.
> Given any particular problem, they let the system determine
> which subset of logic to use and what inference engine(s) to
> apply. My criticisms of Cyc are not that they should restrict
> their notation, but rather that they should be even more general
> and more flexible in the options they support. Among other
> things, I would put more emphasis on induction, abduction,
> and analogy. (I wouldn't discard deduction, but I'd treat
> it as just one of many methods of reasoning.)
>
> 7. And by the way, Cyc does support a version of contexts and the
> option of having multiple contexts with different subsets of
> the knowledge base available in each. It also supports metalevel
> reasoning about the contexts and what knowledge is available
> or should be added to any of them.
>
> Although I have been critical of Cyc, I am even more critical of
> the Semantic Web because that has gone in the *opposite* direction.
> Instead of learning from Cyc and doing something better, they have
> gone back to the pre-1984 technology that was the starting point
> when the Cyc project was begun.
>
> Cyc isn't the only thing that the SemWebbers ignored. They also
> ignored the lessons of SQL and UML -- two widely used technologies
> that are not as good as they should have been. Those two systems
> have not been improved, partly because the available tools have
> been constrained by the requirement for backwards compatibility.
> But the SemWeb broke compatibility without making any advances.
>
> The SemWebbers try to excuse themselves by saying that they are
> trying to do something less ambitious than Cyc in expressive power,
> but more ambitious than Cyc in the amount of data they process.
> But that sounds like Bush trying to explain the Iraq War.
>
> In fact, no design study for the SemWeb or Iraq examined all
> the options in order to determine what should be done or how
> to coexist with and interoperate with other systems. The *only*
> design document that was used for the SemWeb was Tim B-L's layer
> cake, which proposed Unicode, URIs, and XML at the bottom and
> expressed the hope that magic would somehow occur at the top.
> Unfortunately, there's no magic in either Iraq or the SemWeb.
>
> There's a lot more that could be said, and following are some
> pointers to related reading.
>
> John Sowa
> __________________________________________________________________
>
> The following slides discuss the continuum between informal and
> formal knowledge representations and some of the issues of mapping
> one to the other:
>
> http://www.jfsowa.com/talks/cmapping.pdf
>
> An analysis of the problems of knowledge representation in general
> and some of the limitations of current approaches:
>
> http://www.jfsowa.com/pubs/challenge.pdf
>
> A paper on contexts, metalevel reasoning, and modal logic:
>
> http://www.jfsowa.com/pubs/laws.htm
>