ADL- Kite9's Visual Language (Part 2)
In the first part of this article, we looked briefly at what ADL is, and how an ADL diagram is composed mainly of Glyphs, for nouns, and Arrows representing verbs.
It should be clear by now that ADL and the diagrams it defines aren't really specific to the world of computing. Lots of the diagrams in the first article we describing people and their relationships to one another. Indeed, what ADL is really about is knowledge representation. There's a lot of very highbrow reading material on the internet about this, for example you could check out OWL. This is a standard by the W3 designed to enable the semantic web. The broad aim of the semantic web is to represent knowledge on the internet in a form that computers can understand and use. For example, if we define the following two items of knowledge in OWL:
All English people like tea.
John is English.
A clever computer program should be able to infer that:
John likes tea.
This is obviously a crucial conclusion if, for example, you are an intelligent agent (a computer program) in charge of buying food for a house... Which is the kind of application the W3 envisage for all of the knowledge representation stuff.
What has this got to do with ADL? Well, it brings us on to categorisation: how would we respresent the above concepts in ADL?
Basic Concepts in ADL 2: Categorisation
We could take a stab at representing the above statements in ADL using what we learnt in part 1, and this would be quite an easy approach. As shown below:
However, there are two problems with this. First, should "is" be in a connection body? Yes, it is a verb, but it is not something being done actively, it is a passive categorization. Second, it could get quite messy when we add more people and classifications. For example, take a look at the diagram below categorizing some more people:
So clearly, once we move away from the simple case, just using the connection element of ADL is not enough. To get around this problem, ADL introduces two further elements to its visual language.
A context in ADL is an area of the diagram, which is subdivided from the rest of the diagram and given a label. A context is therefore a grouping of diagram items. Here is a quick example:
Why is this good visual language? Well, clearly it is not a new construction of ADL - it's basically taking part of the visual language of the Venn diagram. Now, we can clearly see two sets, French and English, and these are distinct (i.e. they have no members in common). So because we are simply using the established notation of the Venn diagram, we are not likely to confuse too many people.
This is one of the aims of ADL: it is a formalisation of well-understood visual language that is in common use. I would argue that this is also the case with the labelled arrow described in part one: People see labelled arrows all around them all the time and so this visual language element is well established.
So far, ADL supports nesting within its contexts, for example:
This means we can now have sets containing other sets. Note that the idea of a Context is not exactly the same as a set. A context is any group of elements that share something common, or even just a way of showing that the context is changing within the diagram. For example, in the diagram below we can clearly see that John in in Ohio, which is geographically separated from the head office:
Now, compared to the earlier diagram containing all the arrows to show people and their nationalities, using some contexts makes things a million times easier to understand - we have reduced the visual clutter due to a hierarchy of sets, and the reader doesn't have to trace arrows up down and everywhere. That's good, but it's not always the right answer, especially where we are categorizing in multiple dimensions.
Let us reconsider the problem of categorizing John, Ellen and Emile shown above. Now, we want to be able to show both their nationality and their sex. In the diagram above, we did this by introducing two sets both called 'Male', which was a bit of a fudge. Now, it probably wouldn't be all that complicated to allow sets to intersect with one another (as they do in classic Venn diagrams). However, as anyone who has used Venn diagrams will be aware, this starts to get very tricky as soon as you have any more than three different sets - there is no way to subdivide a piece of paper to create four different sets, for example. So what should we do?
Luckily, this problem is already solved on maps. You use a key. For example, on the tube map you have a wheelchair icon attached to all the stations to indicate disabled access, and a red dagger, which tells you to check the station before you travel there (at the time of writing there is work going on for the 2012 Olympics). How do I know that's what these symbols mean? There is a key at the bottom explaining it.
So, ADL supports this commonly understood notion of symbol-and-key classification. Here is our people example again, but this time with a key:
Note that in this example, we are using letters inside shapes to define the key. To differentiate between French and Female (which both use an 'F'), we are using a hexagon and a circle. Clearly, this leaves plenty of alphabetic scope to define other keys, but we could move on to use icons like daggers or wheelchair symbols if need be.
You might very well argue that the information contained in the above is an entirely useless thing to put in a diagram, since there are no spatial relationships between any of the elements. I would agree with you: the purpose is simply to demonstrate the functionality of the language, and show the way in which we can use a key to categorize the glyphs already in the diagram.
In the final part of this introduction to ADL, I will introduce one further way in which glyphs can be categorized, as well as looking at adding other textual information to the diagram.