OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Beyond Ontologies

[ Lists Home | Date Index | Thread Index ]

From: Roger L. Costello [mailto:costello@mitre.org]

>I think it is clear that except for trivial, academic cases RDF Schema
>and OWL do not have the robustness to capture the dynamically changing
>nature of real-world semantics.  To do so, we must go beyond these
>ontology languages.

Because ontologies do not capture.  They **distinguish**.
The intelligent observer captures.  One reason to create 
automatons for this (to answer Nicholas), is to make 
automated agents behave intelligently so that they can 
act as representatives of their owners, for example, 
intelligent search 'droids that discover and distinguish 
resources, then negotiate with them to create a proposal 
based on the results of the negotiation that can then 
be presented to the human owner.  This is doable but 
a better understanding of negotiation requires the 
understanding of domain creation and domain evolution 
such that the agent can identify the current domain. 
In short, it manages contexts on behalf of the user 
and that is a way of saying 'creates and evolves 
schemas'.  Already, tools such as Visual Studio 
produce schemas on-demand.

Ontololgies model. A known means of modeling  
what you are working on is situational cybernetics using 
first and second order cybernetic systems.  The vital 
knowledge is that in a dynamic situation, controls are 
emergent or evolve by negotiation.  

There is nothing spooky about complex systems, 
or really, distinctly new.  Pipelined systems 
with negotiated controls are the common approach 
because of the need for a formal system that 
enables scope of control (where scope has dimensions 
such as temporal, spatial, conceptual class, and so 
Formal systems require closure and therefore, never 
accurately model 'reality', and that is a 'so but 
so what' statement.  Tools is tools.  The Golem 
problem is solved by limiting the authority of 
the ontology and its operational means.  For your 
work, consider a system that provides a means to 
parameterize an XSLT that modifies the document 
be it a chain of XSLTs that modify aspects of a 
schema or themselves.  Even if complex, 
it is finite (closes).

The work on upper level distinctions that can then be 
used for organizing the classifications efficiently 
and *distinctly* is the tough work.  When you say 
"beyond ontology", you are repeating an age-old 
pattern in computer science:  shifting the focus 
from data to process.   To understand the world 
'as it is', one sees 'being', 'thinging', 'becoming', 
and so on, the dance of lila, the essence of samsara. 
But to be in that world, one uses energy to change it, 
one 'interacts'.  As I said, at the end of your 
investigation, you should have a much greater appreciation 
for data-driven applications, paticularly, data-driven 

Where is the source for parameters to XSLT scripts? 
That is the environment interface control.
John Sowa makes some important points about ontologies 
in his work and recent discussions on the CG list:

"The upper ontology should be
organized around fundamental distinctions, from which
the various categories and their placement in the
hierarchy can be derived automatically.

One of the distinctions is between physical and
abstract.  That distinction covers representations
as well as possible individuals that don't really
exist, such as unicorns.

All types are abstract, whether types of lions or
types of unicorns.  All actual lions are physical,
and any instance of Unicorn, if it were to exist,
would also be physical.  Similarly, the information
in all representations is abstract, and the encoding
in any medium is physical.

That is an example of how one distinction, high up
in the hierarchy, has implications that ripple down
throughout the ontology.  Unless the distinctions
are located at the proper level, redundant copies
of similar but subtly different axioms must be
repeated in many disparate sections of the hierarchy.

And that brings us to another point that I have been
making again and again:  we should not start by drawing
diagrams, but by listing the relevant distinctions.
Then at every stage of ontology development, we can
push a button to cause some algorithm, such as FCA,
to create a hierarchy of categories that shows where
each of them is located in terms of the defining
distinctions." - J.F. Sowa

Back to topic.  A known approach to modeling and 
evolving system is semiotics.
One could model a semiotic processor using XML, XSLT, 
and the parameterising program as the interface to 
the environment.  One gets a recursive process model.  
Something from my HumanML notes:

"If Peirce's ideas that the universe is a sign producer are applied, 
then in effect, the model includes the environment as well as all 
semiotes within it.   Schematically:

|Semiote: Global environment                           |
|                                                      |
|                     +----------------------------+   |
|                     |                            |   |
|                     v                            |   |
|       |----------------------------|             |   |
|       |Semiote: local environment  |             |   |
| sign  |----------------------------|             |   |
|---+-->|                        sign ->--+---+    |   |
|   |   | Semiote: member            |    |   |    |   |
|   |   | Semiote: member            |    |   |    |   |
|   |   |----------------------------|    |   |    |   |
|   |                                     |   |    |   |
|   +-------------------------------------+   |    |   |
|                                             |    |   |
|                   +-------------------------+    |   |
|                   |                              |   |
|       |-----------v----------------|             |   |
|       |Semiote: local environment  |             |   |
| sign  |----------------------------|             |   |
|---+-->|                        sign ->--+--------+   |
|   |   | Semiote: member            |    |            |
|   |   | Semiote: member            |    |            |
|   |   |----------------------------|    |            |
|   |                                     |            |
|   +-------------------------------------+            |  
|                                                      |

We design a class structure for that which can process the 
structured messages (signs) that are provided in the form 
of an XML instance.   This would incorporate XML technology 
such as DOM and possibly XSLT as components of the sign processor 
which itself may be an XML pipeline augmented with a rule 
processor such as a Schematron engine."



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS