Re: It don't mean a thing ...
Date: Mon, 07 Jun 2004 14:30:23 +0200
Brian Inglis wrote:
> mAsterdam wrote:
>>Brian Inglis wrote: >>>mAsterdam wrote: >>>>Brian Inglis wrote: >>>>>mAsterdam wrote: >>>>>><quote> >>>>>> Data on its own has no meaning, only >>>>>> when interpreted by some kind of data >>>>>> processing system does it take on >>>>>> meaning and become information. >>>>>></quote> >>>>>ISTM it's just the very old statement that a string of bits or bytes >>>>>by itself has no semantic content, but it gains semantics when it is >>>>>interpreted as a type: characters, an integer, or an FP number. >>>> >>>>(Type as 'valid set of values' - please correct me >>>>if you use another definition) The only semantics >>>>it gains by being interpreted as a type is >>>>being member of a set. >>> >>>Type or Class also allowing certain operations. >> >>(http://en.wikipedia.org/wiki/Peano_axioms) >> >>The Peano axioms define natural numbers >>by means of the 'successor' operator. >>But, say, addition - while surely possible >>on natural numbers does not define them.
> The operations on numbers are an important part of the semantics of
> numeric data types and are part of the type definition IMHO.
In another post I wrote:
> There is an important difference
> between meaning and use.
> Say we currently have a validated statement
> about the exchange rate of some stock at some
> recent time.
> 1. It does not matter to the meaning
> where/how this statement is represented. We have it.
> 2. To the use of it it is important where/how
> it is represented, and available to relevant actors.
> 3. Twenty years later the meaning of this statement
> is still the same.
> 4. Twenty years later most of its usefullness will
> probably have gone.
It has to do with layers of communication. Some prefer to distinguish only two layers (syntactic & semantic), others more (fatic, syntactic, sigmatic, semantic, pragmatic).
>>Using type in the 'valid set of values' way:
> Types as 'valid sets of values' can only be tested for existence and
> membership and have limited usefulness mainly for validity checking.
Yep. In databases, that is where 'type' fits in - that is *if* we want to discover nuance. To distinguish one needs distinctions.
> Without even those meagre existence and membership predicate
> operations which depend on some comparison operation, the type would
> be a uselessly abstract concept, not even an idea.
Meagre as existence and membership operators may be in your view, luckily, they apply to 'type'. Constraints are based on this. I would not dare to call that a useless or even unimportant concept. But it also has an upper bound - that is *if* one dinguishes more layers.
> But types as 'valid sets of values' in the sense of equivalence
> classes with properties and possibly associated or value dependent
> operations are much more interesting and useful objects.
>>Some operators (help) define a type, other operators, >>though possible do not. I would think >>that all the possible operators would be part >>of the class definition, not the type.
> I don't really see or make much distinction between type, domain,
> class, object, assuming the latter does not have the meaning of
Do you make a distinction between 'meaning and 'use' ?
>>The defining operators affect meaning, >>the others, though they do affect use, >>do not affect meaning.
> You are claiming that the operations which may be used on a type do
> not affect the meaning of the type.
That is, beyond the ones *needed* for the definition of the type.
To reiterate in terms of the example: successor does,
addition - however useful - does not affect the meaning
of 'natural number'. Yet IOW:
Addition affects the use of natural numbers, not the meaning.
> But you also state that operations affect use, so you must admit that
> types without operations may be useless.
Useless, yes. Not meaningless.
> Would you not agree that the change of the type from useless to useful
> certainly gives the type additional meaning in changing that use
> property, plus those additional operations adds information not
> originally available from the type and so affects the type semantics?
No. It overloads a concept which is complex enough as it stands. But many use the terms in the sense you do. For instance mountain man, in another post:
> I think we sort of agree here, except I guess I
> am pushing more towards a definition where the
> meaning of the data and its usefulness are somehow
> related, and that it may be --- in some instances --
> not appropriate to separate the distinction.
I forgot to ask where this particular vagueness would be appropriate, though. Often used, yes.
> ISTM the operations which may be used on what you call a type are both
> an enhancement and a tightening of the definition and meaning of the
> type, making it a different type, and so the operations allowed on
> types are an integral part of the type semantics.
On the contrary, by overloading concepts one blurs potentially useful distinctions.
> Types with operations as part of their semantic definition are much
> more interesting in that they can be combined in various ways to
> generate useful information not already available.
The only operations I want to exclude as part of their definition are the ones not used to define them. Makes sense, no?
> Sets as types would have limited usefulness by themselves alone,
> without any of the more interesting set operations and the associated
> semantics defined on them.
It gets boring, I'm affraid: I'ld say 'associated *use*'.
Now why would I want to make a distinction others do not?
It is because I suspect a lot of the miscommunication between people from different schools of thought is due to stretching the meaning of school-internal words when confronted with problematic issues, partly to avoid the use of *their* concepts, partly to cover up paradigmatic blind spots. Not unlike the not-invented-here syndrome.
Three examples would be
- Orthogonal persistence in the object school to dissmiss all problems of data sharing as 'implementation issues'.
- Stretching *type* in the relational school to dismiss 'class' as a valid concept and still have it.
- (Most unfortunate:) stretching *meaning* to include *use*.