A description and type theory

Types and tokens, things and instances

Copyright 2017 Graham Berrisford. One of about 300 papers at http://avancier.website. Last updated 18/11/2017 18:53

 

Enterprise architecture is about business system planning.

It can be seen as applying the principles of general system theory – which we’ll get to later.

This paper is one in a family of related papers - listed at the end.

 

Every system description is an abstraction that typifies one or more concrete system realisations or instantiations.

The concepts of “type” and “instantiation” are fundamental to system theory, yet far from universally understood or even agreed.

Who’d have thought the concepts are so variously interpreted in mathematics, computing and natural language?

 

There is some confusion, especially in discussion by software designers, between things, objects and instances.

This paper strives to resolve the confusion by separating things from their instantiations of types.

The proposal is that, outside of biology and software, instantiations are conceptualisations, just as types are conceptualisations.

 

There is some confusion in philosophical discussion between instances of a type and tokens of a type.

The confusion is evident in the Stanford Encyclopedia of Philosophy <https://plato.stanford.edu/entries/types-tokens/>

This paper strives to resolve the confusion by separating the concepts of type signifier and token.

Contents

Description theory. 2

The use of types to describe things. 4

Types in mathematics. 5

Types in computing. 6

Types in nature. 8

What does instantiation mean?. 10

Instances and tokens of a type. 11

Type signifiers and tokens. 12

A philosophical debate. 14

Conclusions and remarks wrt systems. 14

Footnotes on family resemblances. 15

 

Glossary

Some terms used in this paper are used differently or ambiguously in other discussions.

While reading this paper, it is best to put aside any other meanings you might bring to the terms below.

Organism: a thing that can reproduce some of its genes, and so engage in the process of Darwinian evolution.

Describer: a thing (organism or machine) that can create and use a description.

Description: a thing that idealises another thing by recording or expressing some of its properties.

Thing: a discrete structure, object, behavior, event or description.

Set: a collection of things that are similar in so far as they instantiate one type.

Instance: an embodiment, by one thing, of the properties of a type.

Type: an intensional definition of a thing; a description of the property type(s) that things of that type embody or give values to.

Type signifier: a name, image or effect of a type, which describers use in recognising, thinking or communicating about that type. E.g. the word “planet”.

Token: an appearance of a type signifier or type in a private memory or a communicable form. E.g. an appearance of the word “planet”.

 

Below are a few verbal definitions of types used in describing systems.

Note how, in defining a type, we classify it using other types.

 

Type

Generic type + differentiating properties

Thing

A describable element of the space-time continuum

Behavior

A thing that happens over time

Structure

A thing that exists in space

Active structure

A structure that can act; can perform a behavior

Passive structure

A structure that is acted upon by a behavior

Place

An addressable location in space

Time

A moment or duration definable in time units

Description theory

For some, understanding system theory requires making a paradigm shift as radical as is needed to understand Charles Darwin’s evolution theory.

Many find it difficult to understand the implications of what was written in 1956 by Ross Ashby.

 

“At this point we must be clear about how a "system" is to be defined.

Our first impulse is to point at [a concrete entity repeating a behavior] and to say "the system is that thing there".

This method, however, has a fundamental disadvantage: every material object contains no less than an infinity of variables and therefore of possible systems.

Any suggestion that we should study "all" the facts is unrealistic, and actually the attempt is never made.

What is necessary is that we should pick out and study the facts that are relevant to some main interest that is already given.” W Ross Ashby 1956

 

In short: to apply system theory is to select and describe those behaviors of an entity that are relevant to some given aims(s) and/or concern(s).

The describer must abstract from the infinite describable facts that could be found in observing the activities of the concrete entity.

 

Our description theory is based on three propositions.

1.      Describers observe and envisage realities (which they perceive to be composed of discrete objects and events).

2.      Describers create and use descriptions (stored in memories and conveyed in messages using brains, speech, writing, pictures and other forms).

3.      Descriptions conceptualise realities (they either mimic features of things, or represent them in some encoded form).

Describers

A Darwinian explanation of description starts from the notion that organisms can recognise descriptions of things.

How do we know one animal can understand a description created by another? By their actions.

Honey bee A performs a wiggle dance to describe the location of a pollen source; honey bee B finds that pollen source

The only plausible conclusion is that honey bee B understood the description of reality communicated by honey bee A.

 

A premise here is that there can be no description until there is a describer to create and use it.

Organism: a thing that can reproduce some of its genes, and so engage in the process of Darwinian evolution.

Describer: a thing (organism or machine) that can create and use a description.

Realities

Was the world already divided into discrete things before it was described?

True, any solid object in space, gas or liquid has a natural discreteness in our perceptions.

But looking beyond solid objects, the discreteness of things, one from another, is as much a matter of perception or description as reality.

 

Where is the boundary in space of the solar system, a hurricane, the Indian ocean, or the United States?

When is the start or end in time of the solar system, a hurricane, an ocean wave, or the Wimbledon tennis tournament?

These things become discrete in our descriptions of the universe.

We can divide the universe in infinitely different ways, and having divided it one way, we can describe things accordingly.

 

Cosmologists see the universe as a space-time continuum.

However, a premise here is that reality can be described in terms of discrete things, discrete object and events.

Thing: a discrete structure, object, behavior, event or description.

Designed thing: a thing described before it is created

Natural thing: a thing that emerges from the evolution of matter and energy, regardless of description.

 

As we shall see, a thing may instantiate many types.

Descriptions

In short, realities do not have descriptions, awaiting discovery.

Rather, describers create descriptions to help them understand and predict realities.

Description: a thing that idealises another thing by recording or expressing some of its properties.

 

Description theory

Descriptions

<create and use>                   <idealise>

Describers     <observe & envisage>     Realities

 

There were describers and descriptions before mankind.

However, the ability to describe reality is uniquely and astonishingly well advanced in mankind.

We form descriptions in many different ways:

·         We naturally encode descriptions in mental models: e.g. remember the sensation of looking at a face.

·         We make descriptions that mimic reality in the form of pictures and other kinds of physical model.

·         We encode descriptions in spoken or written words: e.g. “a planet is a large body in space that orbits a star.”

·         We encode descriptions in other forms of documented model: e.g. a symphony score.

 

To describe is to typify.

Humans describe things by using words to typify discrete objects and events in that reality.

This paper looks at the nature of types used in description.

The use of types to describe things

The evolution of description outlined steps leading to the increasingly sophisticated creation and use of “types” to describe things.

This triangle represents relationships between describers, types and things.

 

Type theory

General Types

<create and use>         <idealise>

Describers <observe and envisage> Particular things

 

Thinking about description usually starts by distinguishing universal descriptive types from particular things that instantiate them.

E.g. A circus ring instantiates (embodies, exemplifies or realizes) the “circle” type (how accurately is discussed later).

 

Universal type

“Circle”

A concept described using other types such as “radius” and “circumference”.

Particular thing

A circus ring

A thing described by giving particular values to the types above.

 

Generally speaking, one type can be realised in many things: e.g. the “arena” type is realised by very many circus rings and theatre stages.

And one thing can be idealised in many types: e.g. a circus ring realises the two types “circle” and “arena”.

 

Universal type

“Circle”

“Arena”

“Arena”

Particular thing

A circus ring

A theatre stage

 

Any material structure can instantiate many types.

So to describe all the properties of a structure is impossible, and the attempt is never made.

 

Our main concern is describing activity systems rather than passive structures.

This paper extends the normal type/instance distinction by dividing instantiations into behaviors and structures.

 

Behavior type

“Orbit”

“Rotation on axis”

Behavior instance

An orbit

A rotation

Entity that performs behavior

A planet

 

Again, the relationships are many-to-many associations.

One behavior type can be realised by many things.

E.g. the “orbit” type can be realised in many orbits by many planets and asteroids.

One thing can realise many behavior types.

Eg. a planet can realise the types “orbit”, “rotation on axis”, “rocky” and “smaller than earth”.

 

People often point at an identifiable entity and call it “a system”.

However, a social or business entity can realise many unrelated and uncoordinated behaviors.

E.g. one social group can realise the two behavior types “card game” and “dinner party”.

 

Behavior types

 “Card game”

“Dinner party”

Behavior instances

A game of bridge

A game of whist

A dinner

Entity that performs behaviors

The social group: John, Joe, Joan and Jo

 

A business enterprise can be seen as a social entity in which actors play roles in many systems

Those business systems may be inconsistent, unrelated, or even in competition with each other.

To study all the behaviors an entity realises is impossible, and the attempt is never made.

Types in mathematics

Mathematicians define a set by defining its members in one or both of two ways.

Some sets can be defined by extension, by enumerating set members.

E.g. list the decimal numbers, or name the colours of the rainbow.

Some sets can be defined by intension, by typifying one member.

E.g. each member in the set of even numbers is as an integer divisible by 2.

 

Basic set theory is too limited for practical system description, because it assumes sets are static.

A static set cannot gain or lose members; add or subtract a set member and you change the set.

In most domains of knowledge, sets are dynamic, they grow and shrink: e.g. the set of trees, or bachelors.

A dynamic set cannot be defined by enumeration; it can only be defined by typifying a set member.

 

So here, a set is dynamic and defined with reference to a type.

Set: a collection of things that are similar in so far as they instantiate one type.

E.g. the set of planets in our solar system.

E.g. the set of symphony performances.

 

A set is an aggregate of its members, with attributes of its own, notably, a total number of members.

A type does not define a set, rather, it defines one member of the set, one instance of the type.

 

Type: an intensional definition of a thing; a description of the property type(s) that things of that type embody or give values to.

E.g. Planet: a large body in space that orbits a star.

E.g. Symphony: a substantial piece of orchestral music in several movements.

 

Instance: an embodiment, by one thing, of the properties of a type.

E.g. one planet or one symphony performance - in so far as they match a given type.

 

Monothetic type: a type that defines properties necessary and sufficient to be a thing of that type.

E.g. A circle is a plane shape with a boundary equidistant at every point from a fixed central point.

The complement to a monothetic type is strict instantiation, where a thing completely and indisputably matches a type.

 

Polythetic type: a type that defines more properties than are necessary – so a thing need not instantiate all properties of the type.

E,g. A bird has feathers, a beak and the ability to fly.

If this type is monothetic, then penguins are not members of the set of birds.

If this type is polythetic, then penguins may be included in the set of birds.

The complement to a polythetic type is fuzzy instantiation, where the match of a thing to the type is incomplete and a matter of judgement.

 

There is an even softer, fuzzier kind of typification.

Fuzzy mathematics (after Lotfi Aliasker Zadeh) feels closer to human reasoning.

In Boolean logic, the values of a true/false variable are binary (yes or no, 1 or 0).

In fuzzy logic, the values of a true/false variable may be any number between 1 and 0.

In other words, a thing can be partially true, or have a degree of truth.

A thing can have rather more or rather less of a quality, and it can be rather more or rather less a member of a set.

Types in computing

Some regard types and type systems as the domain of computing.

The definitions below are taken from the Unified Modeling LanguageTM standard, v 2.4.1.

 

Note that two concepts can be related by a generalisation-specialisation relationship.

Instances of the more specific concept inherit all the features of the more generic concept.

E.g. squares inherit from rectangles, which inherit from parallelograms, which inherit from quadrilaterals.

And in UML, classes inherit from classifiers, which inherit from types.

 

UML Type

“A type constrains the values represented by a typed element.”

“A type serves as a constraint on the range of values represented by a typed element.”

“A type represents a set of values.”

“A typed element that has this type is constrained to represent values within this set.”

 

The value of a typed element must have a value that conforms to the type.

E.g. the type “rainbow colour” represents the set of values enumerated as {red, orange, yellow, green, blue, indigo and violet}.

A data item of that type must have one of those values.

 

UML Classifier (inherits from Type)

“A classifier is a classification of instances, it describes a set of instances that have features in common.”

“A classifier is a type. A Classifier defines a type.”

“A classifier is a classification of instances according to their features.”

“All instances of a classifier have values corresponding to the classifier’s attributes.”

 

(Strictly speaking, a classifier does not describe a set of instances, it describes one instance in a set.)

 

UML’s "classifier" is itself a generalisation of three subtypes:

·         Component: components typify subsystems (and are akin to the systems discussed in these system theory papers).

·         Data type: data types (e.g. integer and string) typify instances of data structures and data items, which are defined only by their value.

·         Class: classes (discussed below) typify objects that have behavioral and structural properties.

 

UML Class (inherits from Classifier)

“A class describes a set of objects that share the same specifications of features, constraints, and semantics.”

“The purpose of a class is to specify a classification of objects and to specify the features that characterize the structure and behavior of those objects.”

“Objects of a class must contain values for each attribute that is a member of that class.”

 

A software object instantiates a specific class; so the object’s existence depends on the existence of its class.

A class corresponds to the set of zero, one or more software objects that instantiate it.

Some see the class as being that set of objects.

But strictly speaking, a class does not describe a set of objects, it describes one object in a set.

 

Multiple inheritance in object-oriented programming languages

Multiple inheritance has two meanings.

It can mean one class inherits from another class, so an object instantiates one class directly, and others (its supertypes) only indirectly.

It can instead mean one object instantiates two or more unrelated classes.

The latter feels more like how types are used in natural language, and is akin to "mixin classes".

 

Mixins in object-oriented programming languages

mixin class contains behaviors that are "injectable" into other classes (https://en.wikipedia.org/wiki/Mixin).

A mixin may be described as being "included" in a class - rather than "inherited" from a more general supertype class.

Since mixins add properties to class, they don’t help us model the case where, for penguins to be birds, we need to subtract a property!

 

Type systems in computing

The main purpose of a type system in computing is to reduce miscommunication between two software modules.

For example, once a data item has been declared as an alphabetic name, a static type checker can ensure it is not used in multiplication operations.

Various kinds of type system are discussed here <https://en.m.wikipedia.org/wiki/Type_system>.

Structural typing is static typing, and checks type compatibility by reference to all of a type's definition at compile time.

Duck typing is dynamic, and checks type compatibility by reference only to that part of a type's definition that is referred to at run time.

By definition, dynamic type checking may cause a program to fail at runtime.

(In some programming languages, it is possible to detect and recover from such failures. In others, type-checking errors are fatal.)

Types in nature

The type theory here doesn’t start from mathematics or computing.

It doesn’t derive from a study of numbers, set theory or the intensional definition of a set member (see above).

It doesn’t start from a study of type systems in computing (see above).

It starts from Darwinian evolution.

 

Designed thing: a thing described before it is created

E.g. what we may typify as a “motor car”, “accounting system” or “tennis match”.

Designed things follow types used to design them

By contrast, natural things precede types used to describe them.

 

Natural thing: a thing that emerges from the evolution of matter and energy, regardless of description.

E.g. what we may typify as a “planet”, “hurricane” or “penguin”.

Note that a natural thing's instantiation of a type cannot occur until that type is created.

We continually and inventively classify things, first this way, then that way.

In addition to descriptions we make of things, organic things are described and typified in the form of the DNA molecules from which they are made.

 

Fuzzy biochemical typification

A Darwinian explanation of typification starts before mathematics and computing, and even before words.

It starts from the notion that organisms evolved to recognise family resemblances between things (see the footnote on Wittgenstein).

A family resemblance occurs when the same properties appear in several things, or when a new thing resembles a past thing.

 

We do remember particular things, particular objects, particular events.

But does the brain work by comparing every newly observed thing with every remembered past thing?

The evidence is rather that brains store and recognise patterns of related sensations, or mental models of loosely-defined types.

And that recognising family resemblances gives organisms an advantage in the struggle for survival.

 

Animals recognise things of a type by fuzzily matching a thing’s observed properties to ones encoded in memory.

Consider the saying: "If it walks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck."

We might treat a thing as a duck even if has only two of the three properties (e.g. it cannot quack).

We might not treat a thing as a duck even if it does have all three properties (e.g. it is a mechanical model).

 

Fuzzy verbal typification

Animals typify things to minimise communication errors

The types of things recognised by animals are symbolised in the tokens they use to communicate.

E.g. an animal sounds an alarm call to signal a new instance of the type we call “danger”.

 

Natural language is loose; and in ordinary life we may find no need to formalise what the definition of a type.

But in complex or risky human endeavours, we need to minimise miscommunication errors between people.

And using the gift of verbal language, humans learned to formalise family resemblances in propositions like this.

 

·         A duck is a bird that waddles when it walks, swims by paddling its feet and quacks.

 

And/or formalise family resemblances in a type definition thus.

Type name

Type definition

Duck

Bird, waddler, swimmer, quacker.

 

Any type theory has to address:

·         If a thing does embody or exemplify all the properties in the type definition, must it necessarily be a duck?

·         Must a thing of the “duck” type embody or exemplify all the properties in the type definition?

 

Types and the things that realise them – in general

A named type is a set of property types, which (wholly or partly) describe a thing of that named type.

A type defines a thing only in so far as that thing instantiates one or more of that type’s properties.

A thing can (wholly or partly) instantiate many separate types.

Things usually have many more properties than any given type; and may have less

It is a matter of judgement whether a thing that does not instantiate all properties of a type can be regarded as a thing of that type.

What does instantiation mean?

There is some confusion, especially in discussion by software designers, between things, objects and instances.

This paper strives to resolve the confusion by separating things from their instantiations of types.

The proposal is that, outside of biology and software, instantiations are conceptualisations, just as types are conceptualisations.

 

In a software system, a class is instantiated by objects (which are often abstractions that describe real world things monitored or directed).

In the real word, a natural thing instantiates as many types as we are used to describe it.

 

A software object is the instantiation of one class, and must have a value for each attribute of that class (if only a null value).

A natural thing is the instantiation of potentially infinite conceivable types.

Moreover, a natural thing's instantiation of a type cannot occur until that type is created.

 

In the software world, a data item’s value equals a value in the set of values defined by a data type.

A natural thing embodies a value in the set of values defined by a type.

E.g. a rose looks red to an observer.

E.g. a circus ring looks circular to an observer.

 

Instantiation of types by natural things

Natural things are instances only in so far as they match defined types.

E.g. For eons before mankind, the thing we now call Pluto was not named or typified.

For a relatively short while, Pluto was described as instantiating the type Planet.

Today, Pluto is no longer regarded as an instance of the type Planet.

 

The existence of a natural thing does not depend on or requires the existence of a type.

E.g. things of the "planet" type existed before any definition of that type.

Also, things of the "duck" type existed before any definition of that type (unless you count the DNA that is shared by all ducks and only ducks).

 

A natural thing can instantiate or embody zero, one or infinite types. 

E.g. A duck is a thing that instantiates the types "waddler", "swimmer" and "quacker".

And it can instantiate as many other types as we choose in future to classify it.

 

Instantiation of types by designed things 

The existence of designed thing depends on the existence of a description – if only in a mental model of the builder.

True, the first "circus ring" was built before any explicit definition of that as a general type.

However, any and every attempt to describe it would quality as type, since many future instances of it can be envisaged.

 

The type "circus ring" might be defined as a thing that has properties "circle", "performance area" and "sawdust covered surface".

But some things we happily call a circus ring may not instantiate all the properties of our "circus ring" type.

And everything that instantiates all the properties of our "circus ring" type has infinitely more properties than the ones we defined.

And somebody else may construct "circus ring" type with different properties ("wooden", "public/animal boundary").

 

Fuzzy instantiation

The suggestion here is that strict, perfect, conformance to types appears only in pure mathematics and computing.

The types we meet in software engineering are peculiar rather than normal.

A UML class is formalised the point where an instance is an object that:

·         can be automatically manufactured by reference to that class

·         must have values for all the properties of that class

·         is nothing more or less that an instance of that class.

 

Thinking along these lines misleads people about what might be called natural typification.

In natural language, types are abstractions recognisable (and therefore somehow remembered) by organisms.

A type is a family resemblance that assembles other types into a type definition.

The instantiation of that defined type by real-world objects is fuzzy.

E.g. We know that no circus ring is perfectly circular; yet we say it is circular.

Also: we know that penguins cannot fly, yet we happily call them birds.

Instances and tokens of a type

There is some confusion in philosophical discussion between instances of a type and tokens of a type.

The confusion is evident in the Stanford Encyclopedia of Philosophy <https://plato.stanford.edu/entries/types-tokens/>

This section strives to draw a distinction.

 

On their own, the words “rose” and “pink” are not types; they are only names that signify types of plant and of colour.

Such a type signifier is only meaningful to us when associated in our minds with other types.

 

A mythical type: unicorn

Nothing instantiates the “unicorn” type; the set of unicorns is empty.

 

·         An instantiation of the type “unicorn” would be a real world animal.

·         A token of the type “unicorn” is a copy of its definition, or signifier of it.

 

Surely, no abstract type, no Platonic ideal “unicorn” existed before the type was conceived?

Moreover, if you can erase all tokens of the type, then “unicorn” will disappear from the knowable universe.

 

A strict instantiation of a monothetic type: a computer program execution

The logic and instructions in the code of a computer program form a complex program type.

Different program instances/performances are tested at different levels of abstraction (unit tests, system tests and acceptance tests).

Eventually, the logic is considered proven correct, and the program is used in earnest.

The program type is a perfect ideal type, and its instantiation in program instances/performances is also perfect.

 

·         An instantiation of a program is a performance of that program type.

·         A token of a program is a copy of that type, or signifier of it.

 

Surely, no abstract type, no Platonic ideal form of the program, existed before it was written?

Moreover, if you can erase all tokens of the type, then the program will disappear from the knowable universe.

 

A fuzzy instantiation of a polythetic type: a symphony performance

A symphony score is a complex type that typifies its performances, including rhythms, notes, intervals and instruments.

 

·         An instantiation of a symphony score is a performance of it, which fuzzily instantiates the type.

·         A token of a symphony score is a copy of that type, or a signifier of it.

 

Surely, no abstract type, no Platonic ideal form of the symphony, existed before it was written?

Moreover, if you can erase all tokens of the type, then the symphony will disappear from the knowable universe.

 

A fuzzy instantiation of an apparently monothetic type: a circular thing

No real-world circus ring is perfectly circular.

 

·         An instantiation of the type “circle” is a (near enough) flat real-world shape that has (near enough) the same radius in all directions.

·         A token of the type “circle” is a copy of its definition, or signifier of it, such as the word “circle”.

 

Tokens of the “circle” type exist in countless mental, documented and other models people have made of things in the universe.

Surely, if you can erase all tokens of the type “circle”, then the concept will disappear from the knowable universe? Or do you believe otherwise?

Type signifiers and tokens

This paper strives to resolve some confusions mentioned above by separating the concepts of type signifier and token.

 

Most of our discussion is about types that are named and defined using words.

To describe a thing in words is not merely to register its existence, it is to say that it exemplifies one or more types.

“In describing a situation, one is not merely registering a [perception], one is classifying it in some way, and this means going beyond what is immediately given.”

Chapter 5 of “Language, truth and logic” A J Ayer.

 

Below are a few verbal definitions of types used in describing systems.

Note how, in defining a type, we classify it using other types.

 

Type

Generic type + differentiating properties

Thing

A describable element of the space-time continuum

Behavior

A thing that happens over time

Structure

A thing that exists in space

 

We usually signify a thing belongs to a type using only the type name

Thus, we signify the thing has the properties in a type definition known to both us and those we communicate with

Of course, our communications are only meaningful to people who share the same definitions of signified types.

 

Note also, there are other ways to signify a type than words.

We use gestures, show pictures, and point to effects associated with things of a type.

 

Type signifier: a name, image or effect of a type, which describers use in recognising, thinking or communicating about that type.

E.g. saying or writing the word “planet”.

E.g. pointing to a picture of a unicorn.

E.g. pointing to a thing of the “smoke” type may signify a thing of the “fire” type.

 

I didn’t set out to say anything new in this paper, only to make sense of sources in a way compatible with Darwin (biology) and Ashby (system theory).

Trying to do that lead this radical proposal.

There is no abstract type – independent of any description of it or reference to it.

So, not only type signifiers are tokens, but also type definitions.

Communications depend on type definitions being shared well enough, rather than perfectly, between communicating parties.

Mathematical types like “circle” are exceptions rather than the norm.

 

Token: an appearance of a type signifier or type in a private memory or a communicable form.

E.g. an appearance of the word “planet”, or a definition of that word.

A philosophical debate

To describe particular things, we use more universal types.

Type theory

Universal Types

<create and use>               <idealise>

Describers <observe and envisage> Particular situations

 

Is there an ethereal, eternal type, a Platonic ideal “circle” that existed before it was conceived by a describer?

There is a debate as to whether types (or at least, mathematical types) exist in an ethereal and eternal form, independently of human thought

 

Certainly, a type must exist before a describer can use it to describe a thing.

Imagine you noticed Venus in the night sky before the type “planet” was conceived, named and defined

Then, you could not describe it as an instantiation of the type “planet”.

 

(Or else you would have to say, in a ridiculously redundant way:

“That light in the sky already instantiates all as-yet-undefined types that might be created or used to describe it in future.”)

 

Probably few people would presume a type like “enemy” or “danger” existed before life.

And even fewer would presume that human-specified types like “football” and “unicorn” existed before life.

Yet many assume that mathematical types like “circle” exist for eternity – before and after humans.

Why presume some types have existed forever while others have not?

Could any types exist before there were describers, before there were life forms?

 

One popular source distils the debate thus.

“Taking "beauty" as example, three positions are:

·         Platonic realism: beauty is a property that exists in an ideal form independently of any mind or description.

·         Aristotelian realism: beauty is a property that exists only when beautiful things exist.

·         Idealism: beauty is a property constructed in the mind, so exists only in descriptions of things.” (“The Problem of Universals” Wikipedia 2017.)

 

To explore this debate, read A philosophy.

Conclusions and remarks wrt systems

Ashby saw a system as an island of orderly behavior in the ever-unfolding process that is universe.

He said the scope of a system is determined by its describers.

Give some aims or interests, describers focus on some regular behaviors performed by some interacting entities.

Ashby’s system might be characterised, very briefly, as a describable set of roles and rules.

 

A designed system is typically described in terms of:

·         Identifier (typically a name along with a generation/version number).

·         Aims or purposes (ideally SMART).

·         Behaviors and interactions (performed by active structures).

·         Active structures (roles of actors that perform behaviors).

·         Passive structures (objects acted on by behaviors).

·         Places (addressable locations in space where structures sit and act).

·         Times (moments and durations when behaviors happen).

 

This paper discusses the relationship of types to things, and descriptions to realities.

Note the correspondences between these three many-to-many relationships:

·         One description can be realised in many realities; one reality can be idealised in many descriptions.

·         One type can be realised in many things; one thing can be idealised in many types.

·         One system description can be realised by many entities; one entity can be idealised in many system descriptions.

 

For some, understanding system theory requires making a paradigm shift as radical as is needed to understand Charles Darwin’s evolution theory.

I say that because I find most people find it difficult to understand the implications of what was written in 1956 by Ross Ashby (quoted at the start of this paper).

In the light of Ashby’s declaration, this table compares the concepts of a type and of a system.

Types and the things that realise them

Abstract systems and the concrete entities than realise them

A named type is a set of property types, which (wholly or partly) describe a thing of that named type.

A named system is a set of orderly behavior types, which (wholly or partly) describe a concrete realisation of that system.

A type defines a thing only in so far as that thing instantiates one or more of that type’s properties.

A system defines an entity only in so far as that entity instantiates one or more described system behaviors.

A thing can (wholly or partly) instantiate many separate types.

A concrete entity can (wholly or partly) perform behaviors in many separate system descriptions.

Things usually have many more properties than any given type; and may have less

Entities usually have many more properties than any described system; and may have less.

It is a matter of judgement whether a thing that does not instantiate all properties of a type can be regarded as a thing of that type.

It is a matter of judgement whether an entity that does not instantiate all properties of a system can be regarded as a system of that type.

 

This paper is one in a family of related papers.

1.      The nub of our philosophy

2.      Introduction (which leads to How the brain works)

3.      A communication theory.

4.      A language theory.

5.      A description and type theory (which leads to Realism or Idealism?)

6.      A philosophy (which leads to Other triangular philosophies)

7.      Knowledge and truth

Footnotes on family resemblances

The philosopher Wittgenstein looked for "family resemblances" across the range of things called "games".

He had a type name; he could define a wider genus (e.g. activity system) but could not find a specifically differentiating type property.

 

Family resemblances (edited from Wikipedia 23/10/2017)

[In his later life] Wittgenstein grew uncomfortable with the traditional notion of category [type].

His discussion on the category game is particularly incisive (Philosophical Investigations 66, 1953):

“Consider for example the proceedings that we call 'games'. I mean board games, card games, ball games, Olympic games, and so on.

What is common to them all?

Don't say, "There must be something common, or they would not be called 'games' but look and see whether there is anything common to all.

For if you look at them you will not see something common to all, but similarities, relationships, and a whole series of them at that…

The result of this examination is: we see a complicated network of similarities overlapping and criss-crossing: sometimes overall similarities, sometimes similarities of detail.”

 

Since the publication of the Wittgentein’s “Investigations”, the notion of family resemblance has been discussed extensively.

Not only in the philosophical literature, but also, for example, in works dealing with classification.

The approach is described as "polythetic", distinguishing it from the traditional approach known now as "monothetic".

Prototype theory is a recent development in cognitive science where this idea has also been explored.

As the idea gains popularity, earlier instances of its occurrence are rediscovered e.g. in 18th century taxonomy, in the writings of Vygotsky or Tatarkiewicz.”

 

Prototype theory (edited from Wikipedia 23/10/2017)

“This was formulated in the 1970s by Eleanor Rosch and others.

It is a mode of graded categorization in cognitive science, where some members of a category are more central than others.

It is a radical departure from traditional necessary and sufficient conditions as in Aristotelian logic, which led to set-theoretic approaches of semantics.

It leads to a graded notion of categories, which is a central notion in many models of cognitive science and cognitive semantics.”

 

 

All free-to-read materials on the http://avancier,web site are paid for out of income from Avancier’s training courses and methods licences.

If you find them helpful, please spread the word and link to the site in whichever social media you use.