version compare and partial orgls

[Eric Dean Tribble <tribble>]

You'd be amazed how hard it was to parse this message once I'd thought
of the new terminology.  I suspect the following will wander a bit....

   Hmmm, interesting.  You're right, in that the sense in which a
   unifiable orgl is partial is separable from the sense in which an
   informable orgl is partial.  I have been assuming that this
   distinction isn't made; it isn't clear to me whether or not the
   distinction should be made.

I think we're on slightly different tracks (the whole DataThingie
issue).  The distinction between dataStampss and Stampss does not
exist in the semantics.  DataStamps arise by convention as the default
reporting standard used by map operations to identify DataObjects.
They are only used when the user does not supply a reporting standard
that includes the DataObject to be reported.

Partiality however is built into the semantics in very important ways.
It is used in the definition of sensors, the data-inform operations,
backfollow, etc.  I think this requires that data-inform and
sharing-inform properties be treated completely differently.  Note
that Partial means the same as data-informable for Orgls.

   Note that the two versions of hamlet are both represented (probably)
   by MapOrgls which map to DataStamps.  These MapOrgls may be complete
   even if they map to DataStamps which are informable and/or unifiable.

Since new 'DataStamps' get made for every insertion (batched by the
frontend, of course), I expect all those orgls to be complete!  They
remain informable, however, which implies that they can be unified.

   The way one unifies one version of Hamlet *to* another (it is
   important to always use assymetric terminology when speaking of unify)
   is by unifying the DataStamp(s) that that version of Hamlet maps to to
   a corresponding mapping of the other DataStamp.

Assymetric technology is quite important.  I think the new terminology
implies assymetry: one of the stamps is informed about sharing with
the other.  

Remember that the data for a big document may be broken into many
arbitrarily sized pieces.  We figured out how to coallesce many
DataBerts into a single DataBerts (I don't remember how at the
moment).  I have suspect that we need to recheck this and make sure we
know how to do this.  It feels tightly intertwined with other inform
issues.  The solution might require informing non'Data'Stamps.

   Now an EAddress (StampID * iD, Position * pos) can be interpreted as
   saying: "I don't know what its true identity is, but its identity is
   the same as the object at pos in the Stamp identified by iD.".  If
   this Stamp is a unifiable DataStamp, then that is the best we can do
   wrt identity in our current state of ignorance.

There is no *one true identity*.  There is the canonical identity,
which is a somewhat weaker notion.  It provides the same power,
however, and correctly maps to the semantics of sharing-inform and the
idea of "best knowledge."

The following paragraph is paraphrased to use the new terminology.
The new court ruling about quotes says I can legally do this :-)

   Now the question it seems to me comes down to: "When we
   want to let a DataStamp know that it will never get data-informed
   or sharing-informed, are these two separate actions?"  Or
   equivalently: "Does a DataStamp have two state flags: 1) whether or
   not it is complete (can be data-informed), and 2) whether it can be
   sharing-informed (the alternative being frozen?); or does
   it only have one flag which turns both of these abilities off
   simultaneously?".

For starters, the capabilities are different.  When a Stamp is
complete, it is no longer data-informable.  Archiving will certainly
result in frozen Berts onto data-informable Orgls.  That's the only
way to have parts of published documents stored (like the part used in
a quote).

The religious question is whether freezing has anything to do with
whether a Stamp is sharing-informable.  It is the obvious parallel to
the complete operation on PartialOrgls.  I think this parallel is
deceptive.

Freezing is an operation on Berts, not Stamps.  Freezing a Bert means
that it can never refer to a new Stamp or Orgl.  The purpose of
freezing is to prevent a Bert from referring to different data (so
that accurate references can be made).  Thus links to frozen stuff
always refer to the same contents (in the sense of equality).  The
links and alternative versions come and go all the time, though.  I
could create a new version of a document, with more links to the data,
but then later delete.  As a result, information about sharing is not
even monotonic for frozen and published Berts.

I can imagine many situation that would require sharing-informing a
frozen Bert.  Imagine all the people that freeze the Berts for their
man pages, or Hamlet, and now want to merge the two identical
documents.  Or imagine documents that quote documents not yet online.
People would just enter the material and publish, and add the sharing
information when the quoted document gets put online.

The only way I can think of to implement the examples above is to
share-inform frozen Berts.  

I've gotten sufficiently distracted that I can't recall other things I
wanted to add here.  Another time.

dean