As promised, a mockup of a topic map interface.
Note that I did not promise a generic topic map interface although this comes pretty close to being generic.
Oh, we need an example of the interface:
Job, Chapter 1
1: There was a man in the land of Uz, whose name was Job; and that man was perfect and upright, and one that feared God, and eschewed evil.
2: And there were born unto him seven sons and three daughters.
3: His substance also was seven thousand sheep, and three thousand camels, and five hundred yoke of oxen, and five hundred she asses, and a very great household; so that this man was the greatest of all the men of the east.
4: And his sons went and feasted in their houses, every one his day; and sent and called for their three sisters to eat and to drink with them.
5: And it was so, when the days of their feasting were gone about, that Job sent and sanctified them, and rose up early in the morning, and offered burnt offerings according to the number of them all: for Job said, It may be that my sons have sinned, and cursed God in their hearts. Thus did Job continually.
6: Now there was a day when the sons of God came to present themselves before the LORD, and Satan came also among them.
7: And the LORD said unto Satan, Whence comest thou? Then Satan answered the LORD, and said, From going to and fro in the earth, and from walking up and down in it.
You should note that each of the verse has a subjectIdentifier prepended to it to enable to reader to quickly locate that verse in a collection of verses.
That identifier also enables the display of other translations of a verse along side the verse in question.
Were this a display of the accepted Hebrew text, of which these verses are a translation, the displayed Hebrew text could act as a gateway to morphological, syntactic (yes, there are differing syntactic parsing of the Hebrew text), links to the latest research, on either a verse, word or structural element basis.
That is what I meant when I said a pull interface.
A pull interface is one where the user and not a programmer, gets to decide what information they wish to see.
For example, say I found the time to practice my Hebrew more than I have for the last 5 or 6 years and so when I mouse-over a Hebrew text, I don’t want a word definition to be displayed but simply its morphological parsing. To act as a hint to me to try to work out from context the meaning of the text.
Contrast that with push models that foist information off onto me whether I would view it or not. Because the developer “knows” what most people want, no doubt by use of Urim and Thummim.
Why not empower users to choose the display (or not) of additional information?
In this particular case, I may choose:
- The classic King James translation.
- A modern translation.
- Several translations in parallel.
- The standard Hebrew text.
- Morphological or syntactic annotations to the Hebrew text.
- Literature annotations to either English/Hebrew text.
- Maps or archaeological supplements to the text.
All underlying the text as interface and subject to expansion by a topic map.
When it comes to developers versus users, the long time topic map advocate, Humpty Dumpty would say:
“The question is,” said Humpty Dumpty, “which is to be master ____ that’s all.”
I vote for users. How about you?
****
PS: BTW, my mockup does all the things I outlined. It doesn’t use JavaScript, Ajax or JQuery to do it but it has had those capabilities long before mechanical assistants appeared on the scene.
What topic maps can add to this interface is a convenience factor and enabling others to more easily bring additional material to my attention, should I choose to view it.
How you wish to enable that use of topic maps is a detail. An important detail but one that should not be confused with or elevated to the same level as successful delivery of content chosen by the user.