The MindSet standard consists of a mathematical formulation, a modeling language, and various formats for implementation. The modeling language consists of principles which help an author indicate conceptual constraints that express their intent. The various implementations include additional rules to simplify the transfer between tools for organizing thoughts.
The MindSet standard treats a thought as an element of T x T
x T x I x P x C.
The MindSet standard is for the import/export of multisets of thoughts.
An N-tuple is a list of elements, a1, a2, ..., aN, where each element is taken, respectively, from a list of sets, A1, A2, ..., AN. The N-tuple is written as (a1, a2, ..., aN) and the set of such N-tuples is written as A1 x A2 x ... x AN.
The MindSet standard treats a thought as an element of the set T x T x T x I x P x C. In other words, a thought is a 6-tuple (a1, a2, a3, a4, a5, a6) where:
Section 2. Modeling Language explains how we attribute meanings to a1, a2, a3, a4, a5, a6 and also why we work with multisets. Section 3. Implementations describes formats for recording multisets of thoughts. Appendix B describes important conventions for extending the above definition of thought.
The MindSet mathematical formalism has us consider our thought as an element B = (b1, b2, b3, b4, b5, b6) of T x T x T x I x P x C. The MindSet modeling language describes the meaning of this assignment.
b1 is the ID of B
b2 is the FromID of B
b3 is the ToID of B
b4 is the Intent of B
b5 is the Prompt of B
b6 is the Content of B
Note that B is an element of T x T x T x I x P x C and therefore:
MindSet lets authors know that if they follow certain constraints, either
explicitly or implicitly, and if converters are available, then they
will be able to transfer
their thoughts along with their structural relationships from their
chosen file format to an
implementation of the MindSet conceptual format.
Exploratory Irdakiss requires that the author make explicit each thought,
identify it with
some capsule of information. An aThought is, conceptually, any such
explicit expression
of "a thought" that an author construes. An aThought is intended to
be self-contained,
inasmuch as it is to have some permanence independent of us. The author
decides
what is a thought. Generally this means that a thought has an internal
structure which
may be nontrivial but the author choose not to make the components
explicit. For
example, an author working with a word processor might consider each
paragraph to be
an aThought, although they may have an aThought be a word or two, a
sentence, an
entire document, or even null.
The author encapsulates each thought. A thought might typically
be a note, but also an image, code, data, file, etc.
2.1.1 Conceptual pitfall: Not emphasizing the boundary of a thought
In order to assemble aggregates of thought, an author needs to be clear
as to the
boundary of a thought, and especially the difference between internal
structuring within
a thought, and external structuring among thoughts. When we are structuring
thoughts
with regard to each other, then the boundary between what is inside
and outside of a
thought is the only one that matters. Many standards, such as HTML,
muddle this by
introducing the notion of a document, which in general has nothing
to do with a thought.
On the other hand, standards such as XML often emphasize expressing
the internal
structuring within a thought, which is semantically very rich, but
overwhelmingly
complicated. This is typical with markup languages. There is a tendency
to think of
every marked up item as a thought in its own right. Markup is handy
for computers that
want to act on a well defined lexicon, but is primarily a nuisance
for authors who should
not have to care about what they mean. An author working independently
with their own
thoughts has no use for documents or markup, which only muddle their
authority as an
author as to what they take to be a thought.
Documents and formatting are relevant when we want to present material
only for the
sake of other people. Markup and semantics are relevant when we want
to present
material to an information system. But they are all contrived and in
the way when we
are working independently with our own thoughts, or inviting others
to share our outlook
on life. Exploratory Irdakiss focuses exclusively on the external structuring
among
thoughts and therefore imposes on authors the requirement that they
be explicit as to
what is a thought. Exploratory Irdakiss places no requirements regarding
the content of
a thought, and leaves this open for other standards.
An aThought which relates one thought to another, may correspond to
a link in a
network of thoughts, or a branch in a hierarchy of thoughts, or a step
in a sequence of
thoughts. Exploratory Irdakiss does not require but offers an additional
convention for
observing a distinction between the first thought and the second thought,
instead of
relying on the direction of an arrow, which may be arbitrary. The two
thoughts should
be ordered so that the attention of the author is understood to move
from the first
thought to the second thought. The first thought is understood to provide
a key for the
partial decoding of the second thought, and the meaning unraveled is
identified with the
content of the aThought. For example, the first thought, the Key may
be thought of as a
file type, or a table structure, or a question, and the second thought,
the Code, may be
thought of as a file, or a record in a table, or an answer. Exploratory
Irdakiss includes
such an optional convention that can be maintained so that the distinction
between the
first and second thought need not rely, for example, on graphical features
which may be
arbitrary.
An aThought is meant to be manipulable by the author, but also by an
information
system. Therefore an aThought includes prompts and Ids for all three
thoughts. The
prompts are included so that the author might recollect, from the aThought,
what the
three thoughts are and how they relate. The Ids are included so that
the information
system might manipulate the thoughts. Ids are intended to be unique,
but this need not
be enforced, for although the aThought must be well formed, the aLove
is nothing more
than a set of aThoughts, and there may be inconsistencies among the
aThoughts. Also,
changes in thoughts are not necessarily propagated, nor should they
always be. The
author dictates the meaning, and the prompts recorded within the aThought,
along with
the content, can help the author recollect what they had in mind by
relating two
thoughts.
2.1.2 Conceptual pitfall: Not preserving what gives thoughts their
value
It is a misconception that an author treasures their thoughts and may
therefore have the
desire to organize their thoughts very neatly. In fact, we all have
more ideas than we
know what to do with, and we simply do not have the time or the need
to be formatting,
editing, indexing or even reading most of them. Instead, our notes
have value as an
organic heap which helps us generate new ideas, and which as we structure,
brings out
the most important ideas. Ideas are valuable through their relationships
with each
other. It is therefore crucial that import and export of aggregates
of notes focus on the
structural relationships between thoughts. An author would rather have
isolated ideas
lost - they can be reconstructed or replaced as needed - than have
their entire system
structurally mangled beyond recognition. Authors always find time to
create new
thoughts, but dread the drudgery of reformatting isolated thoughts,
each of which by
itself is of questionable value. Exploratory Irdakiss is designed to
respect a system of
thoughts in its entirety.
2.1.3 Conceptual pitfall: Preserving what the environment intended
We want to encourage the creative and unexpected use of software tools.
We are
therefore concerned only with the structural constraints that they
impose. Semantic
interpretation is left entirely to the user, and may not agree with
the intended use of the
software tool. For example, someone working on a genealogical tree
might choose to
import their thoughts into a graphic editor for components of a product.
In doing so,
they will necessarily be subject to the structural constraints of their
chosen software
tool. Exploratory Irdakiss does not place any additional semantic constraints
that would
discourage them from using a tool as they see fit.
2.1.4 Conceptual pitfall: Preserving what we see rather than what we
think
An author chooses to work within an environment as a way of affecting
their thinking.
The structure they are thinking is often different than the one that
they are actually
seeing. A list may look ordered, but an author may take it to be unordered.
In fact,
unordered lists are typically laid out in some order. What is relevant
for an author is that
import and export preserve the conceptual environment. The transfer
of irrelevant
structural information can distort and cloud thinking.
An author fosters a set of aThoughts as a system, known as an aLove,
which aside
from nodes, typically makes use of several additional structuring types,
each of which
may be associated with a subsystem of aThoughts. Each subsystem poses
its own
conversion problem. The structuring type is the most important feature
of the
Exploratory Irdakiss, and is the main purpose for having the standard,
because it
respects the discipline that an author has been imposing on themselves
while working
with large aggregates.
The structuring type simply records the self-discipline the author has
applied, and need
not actually obey the structural constraint, so that structuring types
within an aLove may
be invalid, inconsistent, and self-contradictory. They simply record
the author’s
intentions. For example, an author may have intended to create steps
in a sequence,
but they may have turned out to form a circle.
3) Are any of your thoughts related? A relationship (or link) between
thoughts consists of three thoughts: modeling (correctly or not) that our
mental state moves from A to B by means of C. Also: every thought
"ID" is taken to be a relationship from "FromID" to "ToID" where the latter
may both be possibly null, (in which case we have a node).
A helpful idea here is that we are modeling our experience of thinking.
With that in mind, the arrows are supposed to model our movement from
one thought to another. In other words, we only deal with the
"relationships" between thoughts as a model of the movement of our
minds
from one thought to another, and in particular, to reexperience such
movement.
4) The intent of the relationship is recorded by a two-letter code for a structural link type:
Redundancy. We want to allow thoughts to be redundant (although often they will be unique and even have a unique ID). This is so that we can say that thoughts can recur, and also, that we don't have to globally monitor thoughts to make sure that they are all different. In practice, this is important because we may want to merge different sources which may yield redundant thoughts.
You must divide up all of your material into "thinking states". Your file will be a list of all of these thinking states. The order of the thinking states should not matter.
Each thinking state consists of six fields, in the following order:
ID
FromID
ToID
Intent
Prompt
Content
I have to learn more about TopicMaps, but right now I think that they
are adequate for expressing our standard. My only reservation so
far is
that I think it would be simpler for us if associations were topics.
But I presume there are work-arounds for this. I will be focusing
on
our particular needs, but I hope this may offer insights into how a
segment of the population, especially individuals, may use topic maps.
"from A to B" means:
Attention moves from A to B.
A requires B.
B is related to A.
A is the reason for B.
A is lower priority than B.
Independent Node
Closed Sequence
Open Sequence
Unordered Hierarchy
A is in topic B.
Acyclic Network
Directed Network
Nondirected Network
"Convergent Thinking"
Idea A belongs in Cluster B.
Cluster the ideas, select promising ones. [start with "Divergent
Thinking"]
"Sorting"
Record A has value B.
Select a feature with a range of values. Group records according
to
their values. Then within each group, sort the records according
to the
values of the new feature, and so on.
"Devil's Advocacy"
Position A supports viewpoint B.
Focus on evidence that bolsters an opposing viewpoint, in order to
find out the truth. Promotes objectivity by supporting all viewpoints
with equal and independent vigor.
******************
Doubt Raised: Do I truly need this?
Counterquestion: What else should I be doing?
This inspires divergence.
Structure Generated: NONDIRECTED NETWORK (N,H)=Atlas
We learn about a solution: Whether it is, and How it is.
******************
"Divergent Thinking"
Idea A suggests idea B.
Generate a comprehensive selection of alternative ideas. Come
up with
many ideas, build on them, inspire wacky ideas, do not evaluate them.
[Then switch to "Convergent Thinking"].
"Problem Restatement"
Statement A is the basis for restatement B.
Express the same meaning in different words.
"Problem Restatement"
Aspect A focuses newly on problem B.
Take the opposite view of the problem. Take a leap to focus on a
different aspect.
"Hypothesis Testing"
Evidence A is relevant to hypothesis B. [Note: the more important
part of Hypothesis Testing is considering inconsistencies].
Consider the relevance of evidence to determining the truth of
hypotheses.
******************
Doubt Raised: Is this truly real?
Counterquestion: Would it make any difference?
This appraises scenarios.
Structure generated: ACYCLIC NETWORK (H,S)=Evolution
We learn about a solution: What it is, and How it is.
******************
Although Morgan D. Jones considers only trees, these structures become
acyclic networks whenever the same state can be arrived at in different
ways, which is especially important in calculating probability.
"Decision/Event Tree"
Determination A makes relevant possibility B.
Structure and distinguish alternative scenarios. A scenario is
a chain
of events. Display choices and outcomes. Branches are mutually
exclusive, and collectively exhaustive. Brings out alternatives,
identifies sequence of determining events. Helps in making choices.
"Probability Tree"
Condition A makes relevant possibility B.
Calculate the likelihood of a scenario. See the impact of estimates.
Recognize sources of uncertainty.
"Utility Tree"
Outcome A makes relevant the Potential B.
Rank courses of action according to expected benefit. Branch
to show
options to gamble on, and attach the estimated probabilities and
expected utilities. Separate the effects of probability and utility,
make both explicit.
******************
Doubt Raised: Is this truly problematic?
Counterquestion: What do I have control over?
This selects context.
Structure Generated: CLOSED SEQUENCE (S,H)=Chronicle
We learn about a solution: How it is, and Why it is.
******************
Identify the weak link, the crucial link, the missing link, within the
middle of a chain of problems.
"Chronology (Time Line)"
Context A influences Event B.
Sort and organize events chronologically to appreciate the context
for
events, and to understand the influence of prior events.
"Problem Restatement"
Reason A is context for problem B.
Continuously reframe a problem to select the expression that most helps
and interests us. Focus the problem so that it is not too broad
or
narrow, not too vague or clear, not driven by assumptions or solutions.
Consider the problem in a wider context. In particular: start
with the
concrete issue, and continuously shift the issue to a higher level
by
asking why it is important, until the issue becomes completely general.
Then work with the level that is most crucial.
******************
Doubt Raised: Is this truly reasonable?
Counterquestion: Am I able to consider the question?
This ranks judgements.
Structure Generated: OPEN SEQUENCE (S,N)=Canon
We learn about a solution: What it is, and Why it is.
******************
"Pros-Cons-and-Fixes"
Disadvantage A addressed by Fix B
Identify strengths and weaknesses of an idea. Modify the idea
to make
up for these deficiencies. Consider the positive aspects first,
then
the negative aspects, and then solutions to the negative aspects, to
find out the negatives that cannot be eliminated.
"Ranking"
Benefit A overshadowed by Benefit B.
Rank in a list according to preference. Each item on the list
should
feel overshadowed by the item of higher preference.
"Pair Ranking"
Benefit A overshadowed by Benefit B.
Compare each pair of items, as to which you prefer. Make rationale
explicit for each pair. Rank based on the total outcomes of the
pairings. Check the ranking by going down the list again (emphasize
neighbors on the list, just as in "Ranking").
"Weighted Ranking"
Criteria A overshadowed by Criteria B.
Benefit A overshadowed by Benefit B.
List criteria. Pair-rank criteria. Apply same criteria to all
items.
Apply criteria with a weight appropriate to its importance. Compare
each pair of items. Rank based on the weighted outcomes of the
pairings. Check the ranking by going down the list again (emphasize
neighbors on the list, just as in "Ranking").
******************
Doubt Raised: Is this truly wrong?
Counterquestion: Is this the way things should be?
This examines legitimacy.
Structure generated: DIRECTED NETWORK (N,S)=Tour
We learn about a solution: Whether it is, and Why it is.
******************
The truth of A explains the truth of B. In other words, the truth of
A
has a wider context, a wider reality,
than the truth of B.
"Hypothesis Testing"
Evidence A is inconsistent with hypothesis B.
Rank explanations in terms of how inconsistent they are with the
evidence.
"Causal Flow Diagram"
Cause A leads to effect B.
Consider graphically how causal relationships between main components
generate the problem. Characterize relationships as direct (increase
causes increase, decrease causes decrease) or inverse (increase causes
decrease, decrease causes increase). Analyze cycles (feedback
loops) as
inherently stable or unstable. Clarify underlying assumptions
different
analysts may have.
******************
Template
Counterquestion: Am I doing anything about this?
This analyzes independence.
******************
Involves internal structuring rather than external structuring.
"Matrix"
A and B are independent features of C.
Compare and correlate the features. Identify possibilities, express
constraints.
"Sorting"
Various features are independent (fields).
Identify features. Isolate and query on desired features.
"Utility Matrix"
Consider options (courses of action) as records having features
(fields). Consider probabilities as features, and the total benefit
as
a feature.
Separate considerations of probability and utility. Consider
entire
scenarios, analyze them from different perspectives, focus on outcomes.
Sum over outcomes, compare overall effects.
Given the structure defined above, I doubt that there is any need for
a
separate structure for cycles - which are quite rare for organizing
thoughts, and many cases where they do appear (like the water cycle
-
"clouds-rivers-ocean", or Socratic questioning) are in the spirit of
the
structure above.
The structural link types (Open Sequence, Closed Sequence, Unordered
Hierarchy, Acyclic Network, Directed Network, Nondirected Network),
which are homogeneous (they involve only one kind of link). They
involve one kind of link type, which makes them simple to record.
The visualizations (Canon, Chronicle, Catalog, Evolution, Tour, Atlas)
which are heterogeneous because they are restructurings of sequences,
hierarchies, and networks. That is, they involve two kinds of
link
types, and they are the basis for mental pictures.
So how could these two different kinds of structures be related?
That
should give some hints. In particular, we can note that the reasons
for
using the structural link types, discussed above, can be paired as
opposites: "attention" to the back and "priorities" to the front,
"reasonings" forward and "requirements" backward, "relevance" outward
and "relatedness" inward. These pairs happen to coincide with
pairs of
restructurings, as follows:
For attention: Directed Network, visualized as Tour, which is Network
restructured with Sequence, (NS).
For priorities: Open Sequence, visualized as Canon, which is Sequence
restructured with Network, (SN).
For reasonings: Closed Sequence, visualized as Chronicle, which is
Sequence restructured with Hierarchy, (SH).
For requirements: Acyclic Network, visualized as Evolution, which is
Hierarchy restructured with Sequence, (HS).
For relevance: Unordered Hierarchy, visualized as Catalog, which is
Hierarchy restructured with Network, (HN).
For relatedness: Nondirected Network, visualized as Atlas, which is
Network restructured with Hierarchy, (NH).
In each case, the structural link type is of the same nature as the
primary structure in the visualization (whether Sequence, Hierarchy,
Network) except in the case of Acyclic Network, where it may still
be
the case that the hope is to create a tree of requirements. I
imagine
that the structural link types are homogeneous structures that arise
because we have the intent to assemble structure, and that intent may
have to be inferred. (For example, there may be many trees, but
the
mental wish is that they all come together into one tree).
priorities: (importance goes beyond particular priorities)
relatedness: (responsibility goes beyond particular roles)
relevance: (joy goes beyond particular gifts)
requirement: (challenge goes beyond particular strengths)
reasoning: (belief goes beyond particular knowledge)
attention: (rights go beyond particular environments)
Letter from Andrius Kulikauskas to ourownthoughts@egroups.com September
13, 2000
Hi! I'm happy to share new findings on the usefulness of various
kinds
of structural links. With the help of your analysis, and more
examples,
I would like these to develop into a style guide for using structural
links. I don't imagine such a style guide as defining a standard,
it
would be so hard to write nonsubjectively. But I think it will
be
important both as an explanation for why we have the "reserved link
types" that we do, and what would be the expected use. I appreciate
your feelings on whether they can be helpful or not.
I looked through the methods in "The Thinker's Toolkit: 14 Powerful
Techniques for Problem Solving" by Morgan D. Jones. His fourteen
methods are: Causal Flow Diagram, Chronology (Time/Line), Decision/Event
Tree, Devil's Advocacy, Divergent/Convergent Thinking, Hypothesis
Testing, Matrix, Probability Tree, Problem Restatement,
Pros-Cons-and-Fixes, Sorting, Utility Tree, Utility Matrix, Weighted
Ranking.
I wanted to see how they relate structurally to the six ways of working
with thoughts that I've written about: Open Sequence, Closed Sequence,
Unordered Hierarchy, Acyclic Network, Directed Network, Nondirected
Network.
My conclusion is that his methods fit very nicely, and in fact, provide
a lot of evidence for the various uses of each structure, and also,
the
direction that the mind moves in establishing each kind of link.
There
is also a seventh kind of structure, which I call Template and basically
is a table of records having fields, so that there are columns of
independent significance that can be analyzed in terms of there
interrelationship. This structure, though, is not an external
structuring, but an internal structuring of thoughts, and therefore
I
think falls outside of the scope of our standard, at least for our
first
version. His tool kit points to the following general uses:
Unordered Hierarchy (Catalog): for channeling convergence.
Nondirected Network (Atlas): for inspiring divergence.
Acyclic Network (Evolution): for appraising scenarios.
Closed Sequence (Chronicle): for selecting context.
Open Sequence (Canon): for ranking judgements.
Directed Network (Tour): for examining legitimacy.
Template: for analyzing independence.
I included above in parentheses the associated visualization types from
Saulius Maskeliunas and my papers. I also include them below where
S=Sequence, H=Hierarchy, N=Network and (S,H)=Chronicle means that a
Chronicle is a Sequence restructured as a Hierarchy.
I also noticed that the uses above resonate with a structure which I
call the "doubts and counterquestions". I write some more about them
at:
http://www.ms.lt/ms/projects/reasonfeatures/991102counterquestions.html
When we have a doubt regarding our experience, so that we can't trust
our experience because we may be brainwashed, the corresponding
counterquestion lets us find our bearings without accepting or rejecting
our experience. So a counterquestion opens up a fresh way of
thinking,
and seems to drive the generation of a corresponding type of
structure. Also, each structure seems to deal with two
of the
following four outlooks on a solution:
Whether it is a solution - is it, or isn't it?
What is a solution - describe it!
How is it a solution - show how we got it.
Why is it a solution - how does it address the problem.
So there is a practical result. If we want to know, about a solution:
Whether it is, use:
Unordered Hierarchy=Catalog (channel convergence) or
Nondirected Network=Atlas (inspire divergence) or
Directed Network=Tour (examine legitimacy)
What it is, use:
Unordered Hierarchy=Catalog (channel convergence) or
Acyclic Network=Evolution (appraise scenarios) or
Open Sequence=Canon (rank judgements)
How it is, use:
Nondirected Network=Atlas (inspire divergence) or
Acyclic Network=Evolution (appraise scenarios) or
Closed Sequence=Chronicle (select context)
Why it is, use:
Closed Sequence=Chronicle (select context) or
Open Sequence=Canon (rank judgements) or
Directed Network=Tour (examine legitimacy)
I'm very happy that because of Morgan D. Jones book I can rely less
on
my own experience. It's important for me to know how these results
accord with your own experience. What must we add, subtract, or change?
What are the core ideas? What hangs together, and what does not?
I include below a list of his methods, describing especially their
uses. In certain cases I have written up his method more than
once,
based on how he variously describes and uses it. He gives a nice
range of examples and exercises.
Half of mathematics is learning how to redefine a concept, such as addition. In math, there are thousands of definitions for what addition means. In programming, this is called polymorphism, that the operation for integers 2 + 5 gives us 7, and for reals 2.3 + 5.1 gives us 7.4, and strings "A" + "B" gives us "AB", and hours 10 o'clock + 5'oclock = 3'oclock. They are really different operations, but it is useful for us humans to think of them all as addition.
What our standard is proposing is a simplest useful definition of "thought", that a thought has a content, a prompt (name or icon, etc.) that can evoke the content, and can be a link from one thought to another, and that link has a global structural intent (it was meant to be part of an unordered hierarchy, or acyclic network, or etc.).
So you can create your own definition of thought. I think we can ultimately come up with the ways this can be done, starting with our initial defintions. Here are six ways to extend it:
The TopicMaps standard can be shown to do many of the above, and
the same is true of other standards, like RDF. So these ways of extending
our standard can serve to model other standards.
In general, a thought is a point of mental stability, and that can be defined in ways of increasing sophistication. These extensions are not important for defining our current standard, except that we should be prepared for them, especially because appraising use cases is one of the most valuable things our community can do, and because some of these ideas will entire our usage guidelines. For example, we want to encourage the design of converters that export as much data as possible, and the simplest way to do this is to allow for additional fields.
It's basically saying that the sophistication of any relational database
is made apparent by flattening it out into one big table. So
"relational algebra" may be useful.
The idea of mental stability also brings to mind that the types of structural intent are various extensions of equality. (That's at least how I while define them in the guidelines).
I spoke with Joseph Goguen about the prospects of a theory of how these mental interfaces unfold as extensions of our basic standard. He said that central to algebraic semiotics is the notion of quality. What makes a user interface good? I think that we can develop a theory that explains the relationship between a "solution interface" and a "problem interface". The solution interface is what our mind proposes, and the problem interface is the reality of the facts in the world. Solution interfaces unfold from based on what the mind offer. The problem interface is given by the facts, the cases, for which the solution works or not. A solution interfaces is bad for a problem interface if it is too simplistic (yielding too many exceptional problems) or overengineered (yielding very few exceptional problems). These ideas are not important for the current standard itself, but will be extremely important for advocacy of our standard. I am writing on this at minciu_sodas_en@egroups.com where I am working to develop an endeavor for thinking about "other thoughts" that we might be able to work with Epremis.
The format is useful because it encourages the design of a network
of converters that are simple but badly needed (at least I wish I had
them so I could make use of many different software tools). I
appreciate your thoughts on whether such a format, and such converters,
might be useful to you.
Exploratory Irdakiss is, first and foremost, a conceptual standard,
defining what is an
aThought, and what is an aLove of aThoughts. Exploratory Irdakiss is
an intermediate
conceptual format which can be used with existing software tools for
organizing
thoughts. This conceptual format is a structurally neutral means for
representing
aggregates of information structured by any and all software tools
and standards. An
author needs to agree to any structural interpretations that will be
made regarding how
they have been structuring their notes. Exploratory Irdakiss is designed
to be
conceptually clear both to the author affirming a structural interpretation,
and to the
developer of a converter which maps the file format of a software tool
onto an
implementation of the conceptual standard.