SCOUG-SundialSIG Mailing List Archives

<< Previous Message << >> Next Message >>

Date:	Fri, 1 Jun 2001 08:03:49 PDT
From:	"Lynn H. Maxson" <lmaxson@pacbell.net >
Reply-To:	scoug-sundialsig@scoug.com
To:	Scoug Sundial Sig <scoug-sundialsig@scoug.com >
Subject:	SCOUG-SundialSIG: June meeting

Content Type: text/plain

Things are getting better (couldn't get no verse) in that Peter
has graciously (to relieve the pain in his arm as twisted up his
back) consented to leading our next Sundial SIG meeting. He will
give us a leg up (with no hydrant, trees, or tempting bushes
present) on our investment project using MESA2 (and whatever else
gets tossed in).

There's nothing more appalling to a group leader who, having
started a journey and gone some distance, looks around,
discovering his group is missing. It's the first thing they teach
you in leadership school (Snake Oil 101). Wanting desperately to
pass the finals and get my degree, I thought I might check to make
sure that my itenary matches yours. If this means throwing out
some of mine and replacing them with some of yours, that's the
second thing they teach you in leadership school.

Now in order for us to communicate properly, i.e. understand each
other, we have to come to terms (third thing in leadership
school). As Steven Levine would tell you (though no such prior
reassurance is possible--I was absent during the fourth thing they
taught you) I am a specialist in generalizations. While it may
seem difficult to nitpick in general I have made it part of my
specialty.

You cannot talk about data or process it without having any. To
have it you must first "capture" it. If we are in the habit of
capturing lots of it we need some means of identification so that
we can deal with it separately (individually) as well as in larger
selected groups.

The data itself has content which represents the set of
"attributes" (sometimes referred to as "fields" in files and as
"columns" in a relational database). A given set of attributes
collected somehow together (unstructured) represents an "entity".
Normally at least one attribute serves as the means of identifying
an entity, appropriately (and hopefully not surprisingly) called
an "entity identifier". That covers content.

Unfortunately in spite of our snake oil that indicates otherwise
all data storage mechanisms are linear (bit-wise sequential) in
structure. That means we must store (and retrieve) data using a
given structure, i.e. order of entity attributes. That structure,
as it does for the syntax of this sentence, determines the
context.

So any time we would definitively talk about data we must agree on
both its content (attributes and their current value) and context
(structure). In the early years of IT we had our nose to the
grindstone with little need for pretentious claims. It was before
marketing and while technicians still ruled. We were then content
to call it what it was: data processing.

However, marketing reared its ugly head and to separate what we do
now from what they did then we changed it to information
processing. Note, however, that except for the name change
everything else remained the same. So the question becomes, is
there a difference or not? Is data processing information
processing? The answer is "no". The difference is "you".

If data equals content plus context (data = content + context),
then what does information equal? Information equals data plus
meaning (information = data + meaning or, substituting for data,
information = content + context + meaning). Where does the
meaning reside, i.e. stored? In whomever (the observer or viewer)
sees it in the data. If the observer (or viewer) does not see it,
then it does not exist (for that viewer).

The net of all this is that we have no means of incorporating
meaning in data exclusive of an observer: we cannot store,
maintain, and retrieve information, only data. Having some 45
years of IT experience under my belt beginning before marketing
brought snake oil into IT, I remain a technician. Thus I separate
out discussions about data, its content and context, which is
independent of any observer from discussions about information
which is not independent. I remain an unreformed and unreformable
"data processor".

I'm already too much into your time but from Peter's presentation
in our meeting we will have to capture different types of
investments, possibly using different data contents. At the same
time we will have to provide a context, a structure on the
content, with some means of identifying the attributes.

As we will have zero, one, or more instances of given data
(content within a context) type we have to have some means of
indentifying the instances. As we will deal with data type groups
(each with different content and context) we will need some means
of group identification. As we may have different collections of
data groups we will need some means of identifying collections.

This means that beginning at the attribute (or content) level we
have the foundation upon which we can build all higher levels
(abstractions). We may then progress from a "field" (attribute)
to its collection in a "record" (a group of one or more fields) to
its collection in a "file" (a group of zero, one, or more
records).

Please note the shift following "a group of" in the previous of
going from "one or more" fields to "zero, one, or more" records.
It indicates that the lowest level of abstraction (attributes)
must exist for any higher level to exist, but that any higher
level may be composed of "zero, one, or more" lower lower, i.e.
any higher level may be "empty".

As your leader I am looking around. Is there anyone there?

=====================================================

To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-sundialsig".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================

Return to [ 01 | June | 2001 ]

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.