Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

[REBOL] Re: rebol-framework: information

From: petr:krenzelok:trz:cz at: 31-Dec-2002 10:10

Ashley Truter wrote:
> Hi Robert, > > Read your doco and the conceptual basis looks pretty sound to me. I've > also been working on an alternative to the traditional database > approach and my thoughts, or emphasis, differ from yours. Since your > doco got me thinking about other issues, I thought (hope!) I might > return the favour by jotting down my thoughts on the subject. > > The "problem" I am attempting to solve is that the company I am trying > to run receives and generates a lot of data in multiple formats (many > of them not electronic).
Not electronic? Yes, there is plenty of such material around. You either find the way how to record info needed or knowledge of the material is nearly lost. You could also think of some kind of workflow engine, which would help you to keep track, what person (office) has certain files on their desk. It is all about processes. Being responsible for e-biz in our company, I came to the conclusion, that no single system is gonna to save you. Today, the world is about heterogenous systems, which you need to teach to communicate one to each other. WebServices anyone? :-) Typical example of broken chain of info flow inside our company: We use Lotus Notes as group-ware system here. Our user receives e.g. email concerning contract No. 1234. But all contract info is stored in SAP R3. So, currently, the email is lost (messages older than 180 days are moved to archive because of storage capacity problems). But - it should not be so! Later on we may need such email info as a decision point to some complaint of customer, etc etc. So you have to decide, what kind info is valuable to your company processess ....
> Some of this "manual" processing may be recorded (in disparate > places), most often it is committed to our (fallible) memory!
so it is nearly lost :-)
> I am trying to design a "system" that enables either the data itself > (say in the case of "contacts") or a reference to the data (say in the > case of PDF documents) to be stored without having to predefine an > arbitrary data structure. The "system" should allow me to do things like: > 1) show me the location of all data to do with embedded systems, > sorted by what I have most recently looked at. [This should display an > entry for each relevant source. Clicking on the entry should take me > to the source (opening a PDF, logging onto a website, telling me the > location of a physical folder, etc)]
you could use full-text indexing, or even simpler aproach we use here to build our knowledge base. Just stick certain button on various company forms, which will allow your ppl to categorise stuff. We use it with our Lotus Notes system, and it simply works. You e.g. receive document, and assign it to "embedded systems" "kiosks" categories .... Later on, your knowledge base can be as simple as the tree of your terms ... so you click upon "embedded systems" and all relevant (recorded docs) are shown in the list
> 2) generate a phone list based on my contacts > 3) tell me which CD's contain optometric images in JPG format
both can be solved by what I describe above ....
> 4) Display my account details, including encrypted username / > passwords / PINs > 5) Tell me if the PDF on my HDD has been updated on the site I > originally obtained it from, and if so, get it.
well, this one would either need some kind of button on certain form to check it right away while you are at a form/doc, or you would have to run some kind of agent (background process/task), which would periodically check for doc updates. Some time ago I worked for Czech Amiga News server (http://amiga.czex.com ) and we build a small script, which periodically checked changes of list of sites and generated html doc out of it, so it saved us plenty of manual work ... quite easy done using Rebol :-)
> My attitude to data capture is that it should be as easy as writing it > on a piece of paper, because if it isn't then that's where it'll end > up! The system should also infer as much as it can about the data. > With that in mind I am trying to use a heuristic approach such that > entering: > > Mr James Smith > 28 Oakfield Street > (03) 9876 1234 BH > > will store this record as key/value pairs (with each line being a > value), but able to infer things about compound values (eg. while "Mr > James Smith" is a name, the system should be able to work out gender, > firstname and surname based on the value). In essence, the system > would extend REBOL's knowledge of data types such that it knows what a > value is and what it can do with that value. At this stage I'm > thinking that REBOL can be used to determine the base datatype (eg. > money, email, string, etc)
I don't believe in Rebol datatypes usability, not in the way you require them to behave. Some language gurus will burn me here that following expression gives accureate info, but for me, it is of no value: ->> email? to-email "abc" == true If "abc" string can be pushed to represent email value, than I can't trust rebol datatype detection, or simply put it works in other way than I would need it. You seem to have pretty hing demands, so in your case, I would not try to mix rebol datatypes and your owns, but simply create whole datatypes detection from scratch by defining you own rules you expect your datatypes to meet ....
> pretty well, but the system will need to infer a bit more with some > types (eg. is this string actually a phone number?) and offer logical > choices and defaults once the datatype is determined (eg. You entered > $12.50 which I know is money! and will default to "Price", but it > could be "Amount", "Tax", "Discount", etc). > > Depending upon the source of data, other attributes can be > automatically deduced and stored. For example, a PDF file has a file > name, location, create and modify dates, and with a little extra work > the title, author and description (if any) can be extracted from the > document itself.
you can stick objects e.g. to certain datatypes, which you can later on turn into GUI ... e.g. for detected file type: [ location: name: type: size: date: author: etc .... ]
> This approach, if achievable, does away with data structures and > allows freeform queries to generate tabulated result sets (eg. "Show > all invoice#, amounts" would know that amount is right justified and > prompt to include a total summary).
whatever :-) create some report engine, make it possible to being handled by dialect or other way .... but just don't forget about simplicity. Sometimes it seems to me, that Rebol is already an engine, which helps to directly construct what you need ... just don't spend too much time on high-level stuff (e.g. your report engine) - concentrate upon basic engine and rules of your system. Building good "ground" will reward you later .... -pekr-