Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: RE: XML indexing/search engine
 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@x...] 8/23/2002 2:10:38 PM, "Bullard, Claude L (Len)" <clbullar@i...> 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.) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
