Re: It don't mean a thing ...
Date: Wed, 02 Jun 2004 00:09:13 +0200
Message-ID: <40bcfe7e$0$37789$e4fe514c_at_news.xs4all.nl>
Eric Kaun wrote:
>>The word "meaning" is critical here. Meaning to whom? >>I'd probably guess that this meaning is with respect to >>the organization which has assembled the data, the systems, >>the users, etc. So using this ... >> >>IMO the statement is accurate, but should be >>generalised further: data on its own not only has >>no meaning
>
> I take the stance that data on its own does have meaning, or at least that
> meaning gives it a useful definition. Without meaning (imbued by virtue of
> some reference, e.g. the business that wants to use it), it's just... bits?
> Facts? To me, the word "data" makes a useful distinction between phenomena
> in some raw, perceived-yet-unprocessed state, and that with which we need to
> work.
This is much closer to what I thought was meant when people used the word data. But this wide-spread definition suggests we were both wrong, doesn't it? Language is as language does. I do not pretend I can redefine it on my own. I can, however, change my own choice of words. I know what I like thinking about, and it is not data as it is defined there.
But maybe (I hope) it is simply a mistake, copied all over the place. That is why I also asked (as yet unanswered) for a source of the definition.
> In any event, applications use the meaning of the data. Nearly every app,
> regardless of where it gets its data, makes assumptions about what's stored,
> its format, columns, relation heading, whatever. Even very dynamic apps,
> with interpreters for domain languages, make some assumptions. Those
> assumptions are the meaning, or at least require that the meaning be
> "enforced". Those assumptions are critical to allowing more than one
> application to deal usefully with business data.
Sharing. Sharing has costs and benefits.
>>but is absolutely useless without the >>corresponding application layer by which it is >>constantly maintained.
>
> Then divide application layer into 2 parts: the Enforcer and the User. An
> RDBMS defines and enforces the law; it's the government. The applications
> are the citizens, which can exert only an indirect influence on a government
> that (hopefully) takes the needs of all citizens into account. The two
> together make a democracy.
>
> (forgive the oversimplification of democracy)
More metaphores :-) Some of these governments have made the cost of sharing so grossly outweigh the benefits, that all kinds of allmost sharing and partwise sharing have emerged. But we can only discuss those, if the sharing *is* a topic - which it is not if we talk about data in the definition under discussion.
>>The organization requires both the data and the >>application layer in order to function. They are >>the ying and the yang; inseparable.
>
> No, they're not inseparable. They're separated all the time, and usefully.
> Granted that to understand the app you need to understand at least the
> subset of the business's data with which it deals; on the other hand, you
> shouldn't need to understand every application to understand what a given
> chunk of data means. Not if you've got an engine that's worth a damn.
Received on Wed Jun 02 2004 - 00:09:13 CEST