Re: It don't mean a thing ...

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.

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.

semantics: meaning
pragmatics: use

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:

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.

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.

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

1. Orthogonal persistence in the object school to dissmiss all problems of data sharing as 'implementation issues'.
2. Stretching *type* in the relational school to dismiss 'class' as a valid concept and still have it.
3. (Most unfortunate:) stretching *meaning* to include *use*.