Thanks Leo that looks like a useful list
of papers, but it will take me a while to read them. I was speaking from
practice, having used that technique of storing and retrieving facts and rules
by context myself in my English Logic Kernel.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Obrst, Leo J.
Sent: Friday, August 10, 2012 4:26
PM
To: [ontolog-forum]
Subject: Re: [ontolog-forum] Ontologies, knowledge model,
knowledge base
Rich,
Yes, you can index
ontological expressions contextually, logically, in a number of ways, e.g.,
using IKL or labelled deduction/hybrid logic. See the following papers:
Andersen, Bill; Fabian
Neuhaus. 2009. An Ontological Approach to Information Access Control and
Provenance. Proceedings of the 2009 International Conference on Ontologies for
the Intelligence Community (OIC-2009, now STIDS). Fairfax, VA, USA, October 21-22, 2009, Paulo
Costa, Kathryn Laskey, Leo Obrst, eds. CEUR Workshop Proceedings, Volume 555. http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-555/.
Neuhaus, Fabian; Bill Andersen. 2011. Speech Acts and Tokens for Access Control and Provenance
Tracking, pp. 44-51. Proceedings
of the Sixth International Conference on Semantic Technologies for
Intelligence, Defense, and Security (STIDS-2011), Fairfax, VA, USA, November
16-17, 2011, Paulo C. G. Costa, Kathryn B. Laskey, eds. CEUR Workshop
Proceedings, Volume 808. http://ceur-ws.org/Vol-808/.
Obrst, L, D. Nichols.
2005. Context and Ontologies: Contextual Indexing of Ontological Expressions.
AAAI 2005 Workshop on Context and Ontologies, poster, AAAI 2005, July 9-13, Pittsburgh, PA.
http://www.mitre.org/work/tech_papers/tech_papers_05/05_0903/index.html.
Gabbay, Dov. 1996. Labelled Deductive Systems; Principles and
Applications. Vol 1: Introduction. Oxford
University Press.
Blackburn, Patrick. 1999. Internalizing Labelled Deduction. In
Proceedings of Hylo’99, First International Workshop on Hybrid Logics. July
13th, 1999, Saarbrücken, Germany. Published in Journal of
Logic and Computation, 2000 10(1):137-168.
Natural language applications:
Gabbay, Dov; Ruth Kempson. 1992. Natural-language content: a
truth-theoretic perspective. In Proceedings of the 8th Amsterdam Formal Semantics Colloquium. Amsterdam: University
of Amsterdam.
Kempson, Ruth. 1996. Semantics, Pragmatics, and Natural-Language
Interpretation. In the Handbook of Contemporary Semantic Theory. Shalom Lappin,
ed., pp. 561-598. Blackwell.
Moortgat, Michael. 1999. Labelled Deduction in the Composition of Form
and Meaning. In Logic, Language and Reasoning. Essays in Honor of Dov Gabbay.
U. Reyle and H.J. Ohlbach, eds. Kluwer, 1999.
Thanks,
Leo
From:
ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Rich Cooper
Sent: Friday, August 10, 2012 4:52
PM
To: '[ontolog-forum]
'
Subject: Re: [ontolog-forum] Ontologies, knowledge model,
knowledge base
Previous discussions
described the variability of contexts. The reason it is important to store
rules as well as facts in the database is that such architecture makes it very
easy to store a table of context IDs and relate them to which rules and facts
apply to each context ID. Searching for contexts becomes very manageable
with that method.
To process a given
context ID, retrieve all the rules and facts into a single graph (locked in
fast memory) and then perform Q&A searches (also locked in memory) as
needed to process part or all of the specified context. The memory can be
released when that context is no longer applicable. Also, numerous
contexts which are related can also be modeled in a graph, and searched,
leading to recursive processes that are much easier to manage than without such
capabilities.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT
EnglishLogicKernel DOT com
9 4 9 \ 5 2 5
- 5 7 1 2
Dear John,
You wrote:
RC
> Actually, rules can
be stored in relational DBs also, not just facts.
You can store anything in
any DB, if you treat it as an uninterpreted "blob" (Binary Large
Object). The critical distinction is how and whether those rules are used
in reasoning.
While BLOBs are widely used to store
unstructured quantitative data such as EKG signals, documents, and such other
byte arrays in a DB cell, that isn’t what I was referring to. BLOBs are
useful when the data can be inserted, queried or deleted in one hunk without
further semantic interpretation by the DBMS. Applications interpret each
BLOB based on what the programmer “knows” the BLOB implements.
Consider a parsed rule which parse
produces a graph of the syntax of the rule. Think of the way algebraic
parsers operate. The parse output consists of triples: one operator and
two objects that participate in the operation of that triple. Allocate
one node in the graph for each of the three elements, with the operator at the
top node and two arcs leaving said top node toward the two objects. Store
the graph in two tables called Nodes and Arcs.
For parameterized function calls such
as f(x,y), the parse produces arcs which are labeled with the parameterization
term. For example, consider the simple equation:
f(x,y) = x + y
which can be drawn in graph form as:
Whereas a BLOB could also be used,
the above representation lets the programmer store the triples in Nodes and
Arcs rows where they can be more easily programmed to traverse the graph.
I use a different <Node, Arc>
design for the triple graph from that I use for the search forest.
Searching the graph constructs the forest, and leads to the AND/OR structuring
I’ve mentioned many times in past posts. The solution subtree is the
embedded tree with max value, min cost, or whatever criterion is used for choosing
the preferred solution subtree.
-Rich
Sincerely,
Rich Cooper
EnglishLogicKernel.com
Rich AT EnglishLogicKernel DOT com
9 4 9 \ 5 2 5 - 5 7 1 2
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of John F Sowa
Sent: Friday, August 10, 2012 9:11 AM
To: '[ontolog-forum] '
Subject: Re: [ontolog-forum] Ontologies,
knowledge model, knowledge base
Doug and Rich,
In general, I agree that Cyc has a
good metalevel terminology and
methodology for knowledge
engineering. But I would cite the warning
by Alan Perlis: You can't
translate informal language to formal
language by any formal
algorithm. There are many "judgment calls"
that cannot be stated in
hard-and-fast rules.
DF
> At Cycorp... We considered an
ontology to define terms, properties
> of terms, and theories about the
terms, while a knowledge base was
> like a database, using terms
defined and provided rules in the ontology
> to describe information about
individuals in some domain of concern.
I agree that's a good
distinction. But the dividing line between what
should be in the definitions and what
should be in the "background
knowledge" is often fuzzy.
Many people let their tools make the
distinction: if it can be
stated in OWL, it's ontology;
anything else goes in the knowledge
base or database. But that
distinction is unreliable.
For example, Plato cited a definition
of Human as 'animal with speech'
or 'featherless biped'. Either
one could be represented in OWL,
but the first is preferred because it
is *essential*, but the other
is *accidental*. However, many
people -- Quine is a prime example --
maintain that there are no clear
criteria for making that distinction.
DF
> Vocabulary microtheories, Theory
microtheories, and Data microtheories.
That's also a good distinction.
But there are many vocabulary terms
that are also technical terms in some
theory. For example, the words
'force', 'energy', and 'mass' are
common vocabulary terms that became
technical terms in physics.
When you have multiple microtheories
that use the same technical terms,
you also run into issues about using
values defined in different ways
in different microtheories.
That can become critical for a large
engineering project that uses
different microtheories to specify
different kinds of components.
DF
> This term [knowledge model] was
not used at Cycorp while i was there.
I agree that it's rare, and I would
avoid it.
RC
> Actually, rules can be stored in
relational DBs also, not just facts.
You can store anything in any DB, if
you treat it as an uninterpreted
"blob" (Binary Large
Object). The critical distinction is how and
whether those rules are used in
reasoning.
In SQL, there are three kinds of
"knowledge" that can be used to
supplement the database:
*views*, which are backward-chaining rules;
*constraints*, which block illegal
updates; and *triggers*, which
are forward-chaining rules that
invoke operations during updates.
If you use those features
extensively, they would make SQL into
a kind of deductive database that
could be called a knowledge base.
This is an issue that many DB and AI
people have been discussing
since the 1970s -- that includes Ted
Codd, who was not happy with
the quirks and limitations of the SQL
design and implementation.
RC
> In your tutorial, on slide 9,
you state:
>
> We need better tools,
interfaces, and methodologies:
> ● Experts in
any field spend years to become experts.
> ● They don’t
have time to learn complex tools and notations.
> ● The ideal
amount of training time is ZERO.
> ●
Subject-matter experts should do productive work on day 1.
>
> The gist of that bullet list is
that people should all learn one
> ontology
language/toolset/methodology.
No, definitely not! What I was
trying to say is that future systems
should support *everybody's* favorite
ontology and notation. When
I said "zero training
time", I meant that nobody should be required
to learn a notation or a vocabulary
that is different from whatever
terms, diagrams, and notations they
prefer for their daily work.
> The knowledge that SMEs develop
is strictly in the application domain,
> and almost never in any
theoretical area other than the usual minor
> amount of math, physics,
chemistry or other more generalized knowledge.
I agree with that principle. My
only disagreement is in the claim
that applications don't involve
theory. I use the word 'theoretical'
for *every* kind of "book
learning'. That includes all knowledge
that is represented in words or
symbols of any kind.
John
_________________________________________________________________
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