[
Lists Home |
Date Index |
Thread Index
]
I'm not to sure why the term semiotic gives
you fits, but semiote and semiosis should. Sign
system and sign system theories are certainly
old stuff and because of all the Victorian era
terminology, hard to read, but they may be a more
cutting edge for AI than predicate logic, although
in implementation, predicate logic systems are
subsystems to semiotes. It's just one more way
to query and transform. As long as the system
can handle polarities, navigating a sign space
isn't that rough. XML and XSLT are actually
a very good way to do this cheap given a
pipeline.
Humans are not computers; they are networks.
I agree though. The more I dig into the AI
rants, the more I uncover terminology that
can be easily reexpressed in terms of relational
dbs with object oriented front ends on a network.
That much is straightforward. Where the
fun starts is in turning extractions of human sign
systems into tables of value and by abstraction,
manipulating these. Most of us here live in a
world of office documents, but they aren't
the only sign systems I'm interested in
these days. The really really fun bit
is that the front end GUI doesn't have to be
a windowing system. The GUI should be
appropriate to the data types. Windows
are lousy ways to depict emotional sign
systems, yet emotional sign systems ARE
how humans determine their focus of
attention and organize their memory. it
isn't that we need to make a computer
think like a human; we need it to be adaptible
to the way a human communicates.
If we do that, maybe we can finally get
beyond point and click to something a bit
more expressive. XML is actually rather
useful for this kind of system for all
the reasons you and the rest of us have
supported it. It is a great syntax for
structuring signs. Elliot Kimber used to
point that out in this sigs. I really
wish he had kept on that path.
I want Simone and I think it is a very
doable project. :) There may not be a
lot of money there, but heck, who made
money on Mosaic (exceptions to those
who lifted the code and denied it).
"Sweet dreams are made of this...
Everybody's looking for something."
len
-----Original Message-----
From: Mike Champion [mailto:mc@xegesis.org]
8/23/2002 2:10:38 PM, "Bullard, Claude L (Len)" <clbullar@ingr.com> wrote:
>DOMs make fine semiotic storage models for a local
>focus of attention. So does a relational view, but
>keeping one of those around means keeping the rest
>of the RDBMS handy, and that is expensive in several
>dimensions.
I would never voluntarily use the word "semiotic"
in a sentence without quotes around it :~) but I think I
agree. Data that will be re-used in unpredictable ways
and updated by multiple applications really should be
normalized and stored in an RDBMS to minimize redundancy,
maintain referential integrity, preserve independence between
the store and the application, and all the other things that
Prof. Codd talks about.
On the other hand, not all data
one encounters imposes all these requirements on its
processors, and XML is a convenient and useful way to
capture and manipulate some snapshot of the data as
"documents." Documents inside an application are
conveniently manipulated as DOMs (generically speaking).
If the documents are processed serially via a pipeline or
workflow, then if often does make a lot of sense to
have them manipulated as XML by each node in the sequence
rather than going back to the master database(s). As Len
notes, this can be very expensive, and the RDBMS is
not always handy.
The canonical example is an invoice, because real-world
invoices (as I undertand it) generally normalize into
about 20 RDBMS tables, and can span 100 or so tables in
an industrial-strength ERP system (I'm told). In a
serialized, distributed invoice processing system, it
can be a lot more efficient to extract a snapshot of one
logical invoice from these tables into XML, pass it around
as a "document" to be read, annotated, updated, etc., and
then put it back in the ERP system (or whatever) once the
various humans have done whatever they have to do to process
an invoice.
A theme I keep coming back to in xml-dev rantings is that
the WHOLE POINT of XML is to live at the nexus of human and
machine systems. Extracting complex DBMS or ERP representations
into ordinary business "documents" makes them more accessible
to humans and human-oriented business processes (which were
designed to be serialized, distributed, and capable of working
with only one writer holding the "lock" at any given time.)
|
