Back to device_1

-- Guide to Ridge Route

DEVICE_2

Interconnected devices become a new device

LIMITATION: Notation used with device_1 suggests structural forms that cannot be interpreted on that device.

The two color blocs in the adjacent image have the same form, but that form cannot be interpreted on device_1. The color blocs are only pictorial:

re-arrangement of locations along the diagonal would break up the color blocs; yet, under device_1, re-arrangment along the diagonal does not change anything significant
the color blocs are groupings of locations and structural events, but such groupings are not defined

The limitation is overcome by loosening the constraint that, in every ensemble, the set of locations and the set of events must be disjoint.

Events themselves become elements in a structure, details in a context. There is a context -- the blue bloc -- that includes, as details, the locations and structural events within the blue bloc. There is a similar second context -- the red bloc. There is also a relationship between the two contexts that indicates that the form is the same.

Extension: The event becomes a location

-- The form from device_1...
...develops into a new form.

-- start Kwik Tour

Three Ways to Notate a Structure For Device_2 (Particular Example)

Events (grouped for display):

(p-(a-v)) (p-(a-w)) (p-(a-x)) (p-(b-y)) (p-(c-w)) (p-(d-x))
(q-(b-y)) (q-(c-w)) (q-(c-z)) (q-(d-x)) (q-(d-z))
(b-v) (b-w) (b-x) (c-y) (d-y)

The locations "p" and "q" are contexts where structural events are the details.
Such locations are called "relations" because they resemble the mathematical object of the same name.

An interpretation of the structure:

Each location, a, b, c and d represents an internet service provider (ISP)
Each location, v, w, x, y and z represents a customer
A customer's use of an ISP is represented by an event, e.g. (a, v) means v@a.com.
Each location p and q represents a mailing list
A link between a mailing list and an (ISP - customer) event represents a presence on the list (e.g., (p - (a-v) ) means that mailing list p is sent to v@a.com)

Development of Commands

The adjacent image illustrates the command "stepping on a relation": Relations (such as p and q) are activated first; only those links activated through the relations will be available for the command.

Interpreting the commands for the (mailing list - (ISP - customer) structure:

Finding that w is the only customer that receives list p through both ISP a and ISP c
Finding that y is the only customer that receives both list p and list q through ISP b
Finding that ISP a and ISP d serve at least two of the three customers (v, x, z) that receive either list p or list q

-- Return to Kwik Tour

Hardware: Adaptations of predecessor devices

Ways to implement Device_2:

one "grand" design using device_1, with every data location and structural event entered along the diagonal -- this is a complete and canonical design that is sometimes conceptually useful but is needlessly large and cumbersome
two interactive device_0 devices and two transfer devices (each uses a bank of switches and transfers the settings from one kind of location to another, e.g. from contexts to details) -- most useful generally
hierarchical design using several device_0 or device_1 systems-- this approach appears especially suited for some tasks, e.g., approaches to database searches
-- the (mailing list - (ISP - customer)) example would use 2 device_0 systems and hardware for one transfer function
conventional computers -- any particular structure and command set can be emulated; however, combinatorial inflation is severe and the programming obscures the concepts (a single device operation requires a complex boolean statement).

Commands

A new system of device_2 commands suggests approaches to systematic development of commands including:

Exploration of network structure (e.g., beginning with a specific context, find all 1st-order contexts (relations) that include, as details, links from that context -- a half-step in and a whole step up)
Stepping on relations (illustrated above)
Explication of a location (systematic expression of detail and indirect detail)
Explication of an isolated structure
Exploratory explication based on relations
Implication based on locations, structures and relations
Neighborhood explication and implication
Cluster-shaping
Path-set definition and path-tracing
Interface commands between ensembles
Notation, storage and execution of device commands in compound form in anticipation of self-organization according to forms of experience explored in stage_4 of Water Trail.
-- (page presently has no substance)

Interpretation

An ordered triple of locations (event - (context - detail) is the initial element of structure.

Structures are assembled by identifications that superimpose locations from different events:

identifying two contexts (it is one book that has two different chapters)
identifying two details (the same keyword appears in two sections)
identifying a detail and a context (the chapter in the book contains a section)
identifying an event and a detail (the link between two pages is an element in a structure of pages)

Generalizing the element of structure:

invented contexts -- called virtual contexts -- that include details where linkage is desired (e.g. a context that includes as details a document and the name of the document)
identifications -- that collapse structure into smaller forms, more convenient to use
generalized relations:
- using virtual contexts and identifications to construct a form (relation - (term - term)) that supersedes (event - (context - detail))
- governed through (category - instance) relations desecribed in category
- the commands of device_2 are directly applicable
E. g., a precursor form for the ( mailing - ( ISP - customer )) example
- virtual context f identified with ISP a
- virtual context g identified with mailing list p

Problems interpreted through notation developed in Stage 3 of Water Trail --

Website design
Legal research involving simultaneous searches on disparate search criteria
Hypertext systems for consumer access to information
Programming system to automate selection and sequencing of commands operating the devices

Forward to Device_3.

Mathematical Perspective

It appears to the author (not a mathematician) that the notation used for device_2 is contrary to the rules imposed by the theory of logical types. (Whitehead & Russell, Principia Mathematica, Introduction, Chapter II, especially sections VI - VIII). The notation appears, therefore, violative of mathematical structure.

Note that the rules for the assembly of structures have no prohibition against (p-(q-r)) and (q-(r-p)) both appearing in the same structure; and the commands of device_2 navigate such a structure as any other.

The symbolic scheme attached to any particular example notated in the system can be re-organized to conform to type theory, but there are conceptual elements (instance relations) where, in general, re-organization can require a number of levels that becomes indefinitely large.

In contrast, the system of device_1 is clearly mathematical. The underlying structures have been thoroughly investigated. See, e.g, Harary, Norman, Cartwright Structural Models: An Introduction to the Theory of Directed Graphs (1965).

-- Return to reference on this page

Author's claim to original design, including instance relations (all in Guide to Ridge Route)