you're reading...

Abstraction (II) Simplification is a Bad Word

Source-Abstraction Correspondence

On the preliminary study, I think abstractions is not fiction or imagination. An abstraction itself is certain object/entity in the world – in a physical, cognitive or computational space – however, it is never an isolated thing but has certain source or basis that the abstraction is abstracted from, to distinguished from such as fictitious or imagined thing. It has a source where there are objects/entities which are more concrete than the abstraction, and have certain correspondence with the abstraction, that is, a source-objects-to-the-abstraction (source-abstraction for short) correspondence. Notice that the ‘objects’ in this essay are in general sense but not in the Object-Oriented sense.

Abstractions in Computational Aspect

In the field of IT and applications, ‘abstraction’ are often appeared not about cognitive nor physical. So I extended the Table I-1 from the previous essay, as Table II-1.

Table II-1: Extending Types for Abstractions to Computational

Physical Cognitive Computational
homogeneous water from rivers, ‘life’ from organisms a class from the objects
non-homogeneous photo from real world objects, ‘moon’ from the real moon data from the real worl

In the table, I added a new space for abstractions, the computational aspects. For the examples in the table, say an abstraction “a class abstraction from the objects” is homogeneous, in the sense that both the class and the objects are carried on the same media, such a language/program (and do not depends on the specific physical materials); an abstraction “data abstraction from the real world” is non-homogeneous, obviously, data in an computer have different media (materials) from the actual thing.

Simplification is a bad word for Abstraction

In such the software field, it appears often explaining abstraction with some words such as ‘simplify’, ‘refine’, ‘reduce’ etc. These words are quite matching the simplest abstraction, as the  example “water abstraction from rivers” in the table, yet, a basic definition in many dictionaries: “remove something from somewhere.” However, I have many reasons to argue that, those words, such as ‘simplification’, are bad words for abstraction. It sounds obvious but too apparent to most types of abstraction we concerned.
If you want represent – abstract – some thing from a reality, It had to be expressed in certain data. So I will talk above issue on data modeling. In Navathe&Sham’s book Fundamentals of Database Systems (4th ed.), discussed four abstraction concepts for data abstraction process, which are used in semantic data models or KR schemes (p110-113): (1) classification and instantiation, (2) identification, (3) specialization and generalization, (4) aggregation and association. The (1) and (3) are inverses but (4) are not, I divided them into two types of abstractions. (see explaining later)

Table II-2: Types of Abstractions for Data Modeling

Type of
Objects at Source
classification and instantiation instances (objects) a class is-an-instance-of (is-a-member-or)
specialization and generalization instances (classes) a class is-a-subclass-of (is-a-subtype-of)
aggregation components/parts/ properties an aggregation (object) is-a-part-of (is-a-component-of)
association objects playing roles an association/relationship is-a-role-of (is-a-participator-in)
identification an individual object an identifier is-denoted-by

Note. In data modeling, it is usually using ‘entity/type’. All ‘object’ and ‘class’ can also add/replace with ‘entity’ and ‘type’ in the table.

Based upon the discussions above, it may

  • say a classification (class/type) is an abstraction, since that it has certain common properties/attributes that are selected/copied from some objects/entities at the source;
  • say a specialization is an abstraction, since that classes/types themselves can also be objects/entities, and thereby be instances of some super class. A super class/type abstraction from some subclasses is usually homogeneous but the classification is possibly non;
  • say an aggregation is an abstraction, since that it is a collection of certain objects/entities at the source, but can be played as an object/entity on another level;
  • say an association is an abstraction, since that it is an object/entity with some roles which are played by some objects/entities, and the roles is belonged to the abstraction but not the objects/entities at the source;
  • say an identification is an abstraction since that it is denoted an individual object/entity as the source.

Notice that, all the abstractions are not as a simplification, not like “remove something from somewhere” as “water abstraction from rivers”, even if for a class from some objects in data – as a homogeneous abstraction – the class itself ought be a data entity and have certain construct but not some thing that simply extracted from the source. We can find more examples, such as an assembly instruction from machine instructions, an API from operational system, and so on. I think, almost all of the types of abstractions in computational space cannot be understood as ‘simplification’.

Overall, The word ‘simplify’ is not suited to most types of abstraction that interested by us, and, on other hand, it is easy to lead astray, to lead us understanding the modeling for some software and the applied domain as a simple mapping between the Objects of software and the entities in the domain, even more, to lead us to be under a delusion that see a whole of software as a ‘simulation’ or an ‘abstraction’ that extracted some objects what concerned, from the real word.


About TY

interested in models & modeling, software, information systems, applications & engineering for enterprises


6 thoughts on “Abstraction (II) Simplification is a Bad Word

  1. You’re filling “appliance” (as Stachowiak used to call it) with life. Although I find the types as defined in the DB book not so perfect, I makes a great example to think about appliance.


    ps: found a ppt version of the book on:

    Posted by modelpractice | August 13, 2011, 15:28
    • Sorry, I’m not very understanding your meaning… I’ve read two vision of Stachowiak’s definition to model, one used “attribute of appliance”, but other one use “pragmatic criterion” (it seems ought corresponded)… what is the “great example” your mentioned?

      Thanks for gave the Url of the book. I find “the types of abstraction” in the ppt version is different with my full version (4th ed.)

      Posted by TY | August 13, 2011, 16:17
  2. Hi TY

    Don’t know if there’s an official translation. I refer to http://iwi.uibk.ac.at/wikiwi/index.php?title=Model for no special reason. Think the appliance makes the difference from simplification/ abbreviation to abstraction.

    This definition of appliance is from the 70/80s so some up to date examples, as from databases are definitely a great thing to find (just as you have done).


    Posted by modelpractice | August 13, 2011, 18:00
  3. Interesting post..

    Posted by gangulysubhajit | June 25, 2012, 02:25


  1. Pingback: Simplification (Abbreviation, Reduction) is Not the Essential Feature for Concept of Model « THINK IN MODELS - July 4, 2012

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s



Subscribe notifications of new posts by email.

Join 62 other followers

%d bloggers like this: