When my business agrees to  work with your business, we need to know what we are working on and how we are going to work. This is shared knowledge, describing the sorts of thing we both understand. For example, You make widgets, and I assemble them into thingies, and so we share knowledge about how to name widgets and how I order then from you, and how you tell me about the progress of an order.

When we are actually working together, we don’t share the knowledge each time we communicate, rather we send each other individual facts about the concrete situation.

• “Have you got 45 P123s?”
• “No, I have only 42 P123s, but I will make some more next month. They cost £42 each, £400 for ten.”
• “I would like to by 40 P123s today.” “I would like to buy 10 P123s next month.”
• etc

An information standard describes the units of information we send to each other and the messages in which they occur. Information units like <part number>, <price per unit> or <date>. Messages such as [stock query], [price quotation].

A data standard describes how the information units and messages get coded into comuterese, such as an XML message. There are many data standards that like to pretend they are information standards, for example, by giving a data unit a tag like . Such names are clues for the programmers, they are clues to the programmer’s knowledge, not to the business knowledge. Which is why, when I ask, “when I buy paint, is the unit in a tin of paint or a litre of paint?” the message has to get rewritten.

Confusing data standards with information standards gets very messy. I do information standards such as:

• STEP – ISO 10303 – a huge series of standards on product data
• PLCS – Product Life Cycle Support (ISO 10303-239)
• JC3IEDM – a NATO standard for military situation awareness
• MIMOSA OSA-CBM – for Integrated Vehicle Health Management