Re: Mapping, take II

[Mark Baker <mbaker -at- OMNIMARK -dot- COM>]

Locke, David wrote


>So maybe, in our hypertext systems, we need to stop thinking about jumps
>(link) as just a way to move from one paragraph (node) to another, and
start
>thinking about jumps as relationships.


We need to be careful here. Links are not relationships, they are simply one
means of expressing a relationship in a finished information product.

There are many relationships between different pieces of information. Some
are intrinsic, based on the content of the information itself. Some are
extrinsic, imposed by someone based on external factors.

To see the difference between intrinsic and extrinsic relationships,
consider the set of all ice cream flavors containing nuts (intrinsic -- I
can tell from looking at the ice cream if it contains nuts) and the set of
ice cream flavors you like (extrinsic -- I can't tell from looking at the
ice cream if you like it).

Intrinsic relationships exist in the meaning or content of a piece of
information. Human being readily detect these relationships from reading the
plain text. If we want to model those relationships so that we can act on
them programmatically, we may need some form of markup. This markup should
not be link markup. Rather, it should clarify the nature of the information
object. Markup should make clear the intrinsic properties of the information
object. Relationships can then be inferred from observing those properties.

Extrinsic relationships are imposed from without. They too may require
markup. On the other hand we will often find that extrinsic relationships
map to intrinsic properties, removing the need to enumerate them (for
instance, you may tell me that you like all ice cream flavors that contain
chocolate)

Each piece of information in your information set will have several, perhaps
many relationships, intrinsic and extrinsic, implicit and explicit. When you
start the process (human or mechanical) of building an information product,
you will have choose what to do about those relationships. In most cases you
will treat each relationship in one of three ways:

1. Express the relationship through sequence (place related material before,
after, or next too the current information).

2. Express the relationship through a link (create a hot spot which leads to
another page or document containing the information).

3. Ignore the relationship.

Number 3 is by far the most common. Document design, or more specifically,
synthesis of an information product, involves throwing away most of the
relationships, and expressing the ones the remain (the ones you consider
most important for this particular synthesis) through sequence or linking.
Usually, the most important relationships are expressed by sequence, the
less important ones by linking.

In the process of expressing a relationship by sequence or by linking we
generally throw away the information on the nature of the relationship
itself and replace it with mechanical information on sequence or link
operation. The explicit relationship information is lost by the time a
relationship becomes a link.

One of the biggest mistakes that people make in designing single source
information sets is to manage links when they should be managing
relationships. The best way to manage relationships is to manage those
properties which form the basis of relationships, making the relationship
explicit is less effective because it does not hold out the possibility of
discovering new relationships based on the properties of other objects.

Actual links are the properties of individual information products and
should be generated on output as part of the synthesis process.

Effective single sourcing depends on keeping and managing all the
interesting relationships in your information set in order to give yourself
many options for creating different syntheses of information for different
purposes.


---
Mark Baker
Senior Technical Communicator
OmniMark Technologies Corporation
1400 Blair Place
Gloucester, Ontario
Canada, K1J 9B8
Phone: 613-745-4242
Fax: 613-745-5560
Email mbaker -at- omnimark -dot- com
Web: http://www.omnimark.com


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=