Representing a thing

25 August 2011

Introduction

Instances of the entity types of the ISO 15926-2 data model are empty, there is no information in them, except for some meta data. Using relationships we can say something about composition, containment, etc, but in fact we point at other empty shells.

In the end humans need to know more than that, they have to see text, numbers, images, etc in order to understand the information.

That is the scope of this topic.

Paradigm shift required

Information representation is a complex matter. In the past years it appeared that this subject gives cause to a lot of misunderstanding. So when you read this topic, be prepared for a paradigm shift.

The letter A is a class

This paragraph title stands for the entire alphabet, all numbers, all Booleans, even for the representation of a date and time. If that were not the case, there could be only one of each, and we wouldn't have something to read at all.

All the a's you find in this topic on this screen are physical objects (pixels on a screen, or ink on paper, that are members of the instance of ExpressString "a" that is a subtype of ClassOfInformationRepresentation.

For the vast majority of cases you are interested in the contents, regardless on which copy it is presented (as opposed to represented).

Yes, there are paper documents (physical objects), but they are of minor importance in the context of ISO 15926. The only time you want to store information about a particular paper document is when you need to manage that copy. This may be the case when the document contains information that may only be disclosed to some people. You have numbered copies then, and you keep record of who got which copy.

And yes, there are revisions of documents. Where classes have no temporal parts, how then do we handle that? See the applicable topic.

Model

Below is a compacted model for representing anything:

From this model many specialized templates can be derived.

Let us review this model in some detail.

At the left-hand side we see two noteworthy things:

  1. The entity type (ABS)Thing, being an abstract entity type, may not be instantiated. All its subtypes (except the abstract supertype ones) can be described and/or identified with a selection from the possibilities at the right.
  2. Class and its subtypes can be "defined", the other subtypes of Thing cannot. Class and it subtypes can also be described and/or identified.

The PossibleIndividual that is the 'sign' of the RepresentationOfThing usually is a PhysicalObject, but can also be an Activity, like a stop sign by a police officer. As said before, this part of the model will only be used seldomly. We use it mainly for the model for revising, approval, issuing, etc a document. We do not approve a paper copy, but the class. Yet only instances of PossibleIndividual can participate in an approving activity. This is solved by approving the physical object that is the record on the server. See the Document-related Topics on the home page.

InformationObject, -Representation, and -Presentation

ClassOfInformationObject is defined in ISO 15926-2 as follows:

A ClassOfInformationObject is a ClassOfArrangedIndividual whose members are members of zero or more ClassOfInformationRepresentation and of zero or more ClassOfInformationPresentation.

This can be modelled as follows:

but better as follows:

because the presentation part (e.g. bold, font type, fot size, color) shapes the representation part.

Even more likely it will be as follows:

See also the topic Document composition.

Usually such a composition of documents in ISO 15926 terms is rather cumbersome, although the effort could be worthwhile for documents with many data, like equipment specifications, in order to make the contained data available in computer-interpretable format. In the past I spent considerable time on composing such documents in this way, but sofar it seems that this didn't get attention.