The Arrow System Paper

[RE01 Rice Brian T. EM2]

> I think that the simplicity of the arrow system as presented in the paper
> is the kind of thing that I would look for in a proposed computing system,
> from the standpoints of implementation and usability.  I think that the
> overview of existing systems given in the paper makes a strong argument
> for a simpler system (as well as being interesting in itself).
> 
cool. thank you.  that part of the paper was initially "ad hoc", but
gradually i've been finding ways to integrate it into the argument.  it
still has a small ways to go, in terms of separating out small parts which
don't belong and some other issues.

> One question that I am inclined to ask is to what degree the arrow system
> can be integrated with external systems.  I have a few ideas about this,
> but maybe not very good.  Or, to look at it another way, if the arrow
> system has the potential to store and manipulate information in a way that
> would make more efficient human-computer interaction possible, what steps
> can be taken to accomplish more efficient human-computer interaction
> given the tools of (a) our current computing systems and (b) a program
> constructed to manage structures of arrows.  In other words, what first
> steps can we look for (or make) in this area?
> 
well, we should only have to figure out how to represent arrow worlds and
implement their dynamics on an existing computing system, and to
constructively implement their reflective actions.  as to interfaces, i
think that i should elaborate the sketch of the ontology graph (which is
very difficult to draw) in a more detailed way.
i'm not sure, offhand, about answers to (a) and (b), but you can guarantee
that i'll be thinking a lot about it in the coming hours and days.  i should
have an answer soon.

> I was a bit lost on a few of the definitions, but again, I think this is
> mainly due to my own ignorance.  Just to list a couple, e.g. why is an
> ontological frame required?  Are the terms context, ontology, and
> ontological frame a necessary part of the arrow system, or are they only
> introduced for the purposes of constructing an argument within the paper?
> 
> I lost the distinction between these terms, but I'm not sure to what
> degree this affected my understanding of the paper.
> 
i have to admit that you've hit upon the most unclear part of the system,
and the one that forms the greatest (most debatable) part of the Arrow
argument:  that the Arrow system, with an appropriate conceptual model (not
necessarily part of the system, but easily understood within the system)
could form a whole that enables the interface with society that we would
want of an information system.

ok, now for the laymen's terms.  the important thing about an ontology is
that it is an information filter; it interprets everything in the world in a
relatively small number of terms.  a mathematical model is then a kind of
ontology, where everything is a group of variables.  the same thing goes for
a state machine, a data format, a communications protocol, or even a
computer language.  in the paper, i used the example of HLLs as ontologies
in reflective programming systems to explain how the arow system (or any
cybernetic useful information system) should architecturally differ from the
ordinary type of system.
in a Self system, for example, everything isn't just an object, it's a
_Self_ object.  that's what makes it an ontology.  of course, you'll say,
that's obvious.  the difference is that i'd like to reify that and compare
_what something is_ in one ontology with what that same thing is in another
ontology.  that's the purpose of giving agents _frames_ of ontologies.  the
structure that the frames impose over their ontologies is not specified, and
is left up to the user or at least should be discussed by Tunes.

how this relates to context, i'm only just now formalizing (many apologies).
a context is supposed to take a model and make it implicit to the agent's
actions.  it's supposed to specify what is true here and now, not then and
there, and what variables can change here and still leave "hereness"
unchanged.  this is supposed to be the user's greatest handle on the system:
the ability to specify, generalize, and crosscut context in free ways.

i leave it to you to think about, and i'll return with more answers when i'm
clear on my own thoughts.