The Artima Developer Community
Sponsored Link

Weblogs Forum
Multiple Contexts, Information Reuse, and Backpointers

2 replies on 1 page. Most recent reply: Jan 26, 2006 8:57 AM by Eric Armstrong

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 2 replies on 1 page
Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Multiple Contexts, Information Reuse, and Backpointers (View in Weblogs)
Posted: Jan 22, 2006 5:05 PM
Reply to this message Reply
Summary
When it comes to information reuse in multiple contexts, backpointers are critical. Doug Engelbart said so in 1968. I finally understand why...
Advertisement

Doug Engelbart always said that backpointers were necessary. I just encountered a concrete example that points out why.    (01)

If a chunk of text is referenced in several difference contexts--perhaps linked in one and included in another--then /backpointers/ show where they are. They let you see where and how a particular segment of information is being used.    (02)

Mechanically, backpointers are very much like links. In fact, they are essentially links with a type tag that says "I'm pointing backwards".    (03)

Note: Type tags on links are something else that Doug always claimed as necessary. They were actually implemented in the NLS system he demonstrated in 1968, and never seen since. (For more on "The Mother of all Demos", see Doug Englebart's NLS System).    (04)

It's important to identify backlinks because they have different /semantics/ than regular links. So while forward links and link-transclusions would be automatically processed when displaying a document, back-pointers might not be seen unless you ask for them.    (06)

A concrete example will make it easier to see why backpointers are vital.    (07)

In my role at Sun Microsystems, I've had an opportunity to think about to structure the installation pages for the Java platform. The Document Information Typing Architecture (DITA) looks like a natural fit here because:    (08)

  • With small deltas, the instructions for Linux and Solaris are virtually identical.    (09)
  • The instructions for the 64-bit architectures are a clean super-set of the 32-bit architectures. It would be nice if the 64-bit folks had one set of instructions, and it would also be nice if the 32-bit readers didn't have to read around the 64-bit information.    (010)
  • The material for some add-on technologies (browser plugins for example, and Java Web Start) apply to both the development kit (JDK) and runtime utility ("runtime environment", or JRE).    (011)

There are a few other opportunities for reuse, but those are the major ones.    (012)

The issue to be solved came up when one of the reviewers pointed out that some of the Linux instructions don't apply to Solaris (or vice versa) and that, every time he takes them out, they wind up reappearing later.    (013)

It was easy to see why. The instructions were so long, and the differences so minor, that would only be natural for a writer working on one to simply copy their changes over to the other.    (014)

With manually pasted text, it's possible to consider taking the writer to task for not being detail-minded enough to observe the minor discrepancies. The fact that no human being on earth is not that detail-minded does not have to dissuade us from our righteous indignation. We can chastise that writer to our heart's content. Why not? It does our soul good.    (015)

But in an environment of automatic reuse, there would be /no way/ for a writer to know who might be using their content, and in what context--unless there were backpointers to follow.    (016)

The first several interface implication for backpointers is simple: You need to know how many backpointers there are for a given bit of material. That number gives you important information all by itself:    (017)

  • If there is only one, you know that you can safely make any changes you want.    (018)
  • If there is none, the material hasn't been used. It might not be worth editing, or it might need a home.    (019)
  • If the number is greater than one, and it matches the number of times you have refererenced it in your documents, then you can proceed with confidence in the knoweldge that you know how the material is being used.    (020)
  • If the number is greater than the number of your personal references, you have to inspect them. (Imagine for example that there is one more. You may have seen it before. But if that reference was dropped and a new one was added, the extraneous context in which it was used could have changed completely.    (021)

Finally, when a piece of information is used in more than one context (yours or others), you need a way to see them in some reasonable fashion. As contemplate the change you plan to make, you then have several interesting options. In choosing which options to implement, the authoring system needs to balance interface complexity against functional completeness:    (022)

  • Trivial change (fix a typo, for example): Just make it.    (023)
  • Note that a relatively small change like adding or removing the word "not" can completely change the meaning of a sentence or paragraph. So whether or not a change is "trivial" depends on how it affects the meaning, not on the number of characters that change.    (024)
  • Change that applies in all contexts (improve wording, add an explanatory note): Just make it.    (025)
  • Modification (changed wording) or deletion that applies in a subset of contexts: Version fork. Select the contexts that should point to the new version.    (026)
  • Addition that applies in a subset of contexts: Three possible options:    (027)
    • Simple version fork, as for a modification    (028)
    • Create a higher level topic that includes the original material and appends the additions. Choose the contexts that change to point to the larger topic.    (029)
    • If the change applies to only one of the contexts, add the new material in that context instead of at the original location.    (030)
    • If the change applies in multiple contexts, add the new material in one of them and add references to it in the others.    (031)

Summary

With reuse comes the necessity for managing backpointers, so that editing and revisions can be carried out intelligently.    (032)


Cleo Saulnier

Posts: 77
Nickname: vorlath
Registered: Dec, 2005

Re: Multiple Contexts, Information Reuse, and Backpointers Posted: Jan 23, 2006 2:16 AM
Reply to this message Reply
That video shows us how far behind the times we are. It looks like something out of a sci-fi movie, it's so good and eerie. It's almost as if it's from the future, yet it's in B&W and from the 60's. Every programmer should see this.

Eric Armstrong

Posts: 207
Nickname: cooltools
Registered: Apr, 2003

Re: Multiple Contexts, Information Reuse, and Backpointers Posted: Jan 26, 2006 8:57 AM
Reply to this message Reply
Vorlath wrote:
>
> That video shows us how far behind the times we are. It
> looks like something out of a sci-fi movie, it's so good
> and eerie. It's almost as if it's from the future, yet
> it's in B&W and from the 60's. Every programmer should
> see this.Vorlath wrote:
>
Couldn't agree more. The demo was done in 1968, and it shows things that didn't arrive until decades later. It even shows a few things that *still* haven't arrived.

Stuff we take for granted today included a graphic monitor, a mouse, hypertext, diagramming, and outlining that you can collapse and expand, all on a timesharing system. None of that stuff would be commercially available for at least 10 years, and sometimes not until 30 years later.

Then there are things that *still* haven't arrived: a programmable chording keyset; typed links that determine the view you see when you follow the link; fully integrated diagrams and text, all with links. And behind the scenes, it implements automatic backpointers so you can see all of the incoming links to a topic.

But what's truly humbling is how it was all implemented. This is 1968. Transistors have only been introduced recently. Integrated circuits haven't even been invented. There are no graphic terminals. No ethernet. No GUI libraries. No nothing.

For a graphic output device, they use an oscilloscope. They mount a camera in front of it and run a cable down the hall to a monitor in your office. From there, cables run back from the keyboard, mouse, and chording key set. And with this limited "proof of principle" hardware, they manaage to implement the most sophisticated software system ever devised. Unbelievable. It really earned it's title as the "Mother of All Demos".

Flat View: This topic has 2 replies on 1 page
Topic: New HeronFront with Classes and Delegations Previous Topic   Next Topic Topic: Implementing Implicit Behavioral Subtyping using Traits


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us