Clipboards + Meaning

[David E. Manifold]

On Tue, 9 Dec 1997, Maneesh Yadav wrote:

> Can you elaborate on storing the "meaning of the data"
> 
> you say that it can be done by:
> 
> David E. Manifold wrote:
> 
> > The storage of data by its meaning makes the data
> > useful everywhere that understands the meaning, instead of anywhere that
> > understands the form (format).  
[snip] 
> > To understand how Tunes stores objects by
> > meaning, you can reason by common sense how the clipboard stores meaning.
> > It finds the common elements of all graphics.  The graphic size (rows and
> > columns), the fact that it is stored in 2D (rows x columns) in a grid, the
> > idea of a color palette (just a set of available colors), and the idea of
> > color depth (the range of colors specified in an individual pixel within
> > this graphic).  Tunes will operate like this for all objects, not just
> > graphics.
> 
> But isn't this just defining another standard format (the promise of every new
> format)?

Nope...I'll explain why.

Formats are syntactic.  They specify a byte order that must be followed
for compatibility.  With current formats, the meaning is stored external
to the file: the file has no meaning without a program to interpret it.
After the file is loaded, it only has meaning to the program that loaded
it, because it is stored in an internal format in memory specific to the
program.  

Tunes has no loading and saving.  Once an object is imported to Tunes, it
is stored with its high-level semantic meaning, whether it is currently on
disk or in RAM (persistence demands the transition between the two to be
transparent).  Storing by meaning is not just another format because the
data remains attached to metaobjects that describe its meaning.  Current
traditional systems have no metaobjects, but data's meaning is determined
by the functions that access it.  The way that Tunes stores by meaning is
it has metaobjects to describe operations available on an object, and
requires the metaobjects to be kept with the object for the term of its
existence.  This ensures that every access to the object is in accordance
with its original designed meaning (as long as you don't redefine some
metaobjects).  An object has no meaning without another "meta" object
providing info about how the object is to be used.  In Tunes an object
does not exist unless some metaobject shows how it is used in the system.

It is interesting to note that using the term 'object' does not actually
mean there is a specific section in the computer allocated to store that
object.  There may be, but not necessarily.  What we perceive as an object
when we interact with the computer really is our imagination.  The
illusion of an object is provided by interaction with what we call the
"metaobject", when in reality only the meta-object may exist.  And yet the
metaobject is only understandable and identifiable on the basis of other
objects (second order metaobjects), that describe its actions.  As you
travel up the hierarchy to the nth order meta-object, you reach the object
that provides the entire framework of how objects are treated.  Then you
realize that the entire system is an abstraction of an abstraction.
Current systems are static implementations of abstractions.

What does having a system of metaobjects, which stores objects by meaning,
allow?  First, strict formats are not required.  Formats that store the
meaning required in any specific context can be automatically generated
for that context.  This includes the sending of objects between
systems--which means communications protocols can be dynamic, too. 
Second, objects within the system are not isolated to one use.  A
program's data isn't stored in a program-specific format; Different
programs don't store the same data differently.  It's not that they use
the same format, it's that they don't need to worry about format.  The
data itself comes with meta-objects that provide access to it, and every
program accesses data through the metaobjects.  This encapsulation allows
objects to be used equivalently anywhere in the system.  Also, it means
objects can be dynamically rewritten without anyone noticing.  Dynamic
rewriting can be used to optimize objects, or to store them on a remote
server without special protocols.  Storing objects by meaning allows
interoperability, dynamic internal structure, and distribution.

> WHat about efficiency of storage via compression?  HOw would it fit in to the
> storage model.
> 
> For instance, let's say you want to use sound in you program, a standard
> clipboard format (or meaning as you have implied) would be to store each
> frequency and how long it is played for.  Taking up an insane amount of space,
> but mpeg compression allows us to have full length songs with extremely high
> compression ratios, how could we take advatage of this under the above
> described?

A clipboard has to store information in the lowest common denominator to
ensure that every program will be able to read it.  In Tunes, the only
thing that two objects need to communicate is an agreed-upon meaning.  In
this case, the meaning is a stream of digital sound.  The difference
between Tunes and a clipboard is that the clipboard has to find a common
meaning, while in Tunes the sound samples already have a common meaning. 
Two objects may be "digital sounds."  You won't be able to tell whether
one is compressed or not by this fact.  (Not only you, but any other
program won't be able to tell, either.)  One could be compressed with
Mpeg, the other with Zip.  What makes them both digital sounds is their
semantics.  A digital sound, no matter how it is stored, has the semantic
of being able to produce a sample stream.  If you look at Tunes this way
you could also say storing by meaning is equivalent to storing by
capability.  Semantics are capabilities. 

In this case, to implement compression on an uncompressed sample, you
simply have to provide a compression/decompression routine.  The
decompression routine becomes the new interface to reading the sample
stream object.  The compression routine becomes the new interface to
writing the sample stream object.

If this is still unclear, it could be because the word "store" is
inaccurate.  It would be better to say objects are accessed (treated,
seen, used) by their meaning, but stored by any method available.  The
implementation is independent of meaning, so data can be stored in any
format, but it still has the same outward, semantic appearance which is
its meaning.

David E. Manifold
tril@bespin.ml.org