[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-
