version compare and partial orgls

[Mark S. Miller <mark>]

Date: Fri, 1 Sep 89 19:46:05 PDT
   From: tribble (Eric Dean Tribble)

   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.

Ah, I remember the issue better now.  It didn't arise in the May
semantics, but because of this the May semantics is incorrect.  What
we presented in May was that the backend is free to create, split, and
coalesce the Stamps used as the Reporting standard as it wishes, given
that this Stamp is not otherwise actively referenced.  The problem is:
who does it report it to, and what are the permissions on it?

Remember that permissions are not in the basic Orgls&Berts level
semantics, but only appear at the GateKeeper level.  The ability to
sharing-inform some data-objects, or data-inform some shared space
belongs with the Stamp which is the reporting standard for those
items.  The GateKeeper maintains (in the Basket structure) an
association between this reporting standard and the clubs that have
various permissions on it.  The permission of interest here is "inform
permission".  

In order for the low-level backend to be free to cons up a reporting
standard out of thin air when necessary, it would have to know enough
to preserve permission distinctions, but the semantics says these
permission distinctions only appear at a higher layer.  There is no
permission system at the layer of the semantics where one can talk
about freedom to cons up a reporting standard.

One reason why we should have a) one canonical reporting standard for
any given data object, and 2) associate inform permission of that data
object exactly with this one reporting standard is:

The semantics provides for syncronization among client requests only
in the "grab" operation for Berts (producing a Hand) and Stamps
(producing a Foot).  We need syncronization among clients wrt attempts
to inform data objects (since different inform attempts may be
mutually contradictory).  If a data object were informable through
multiple Stamps that referred to it, it would be necessary for clients
to have yet another means of staying out of each other's way.

   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.

What else is Partial besides Orgls?  Derived Partial Orgls are NOT
data-informable directly.  If data shows up in the coordinate space
they are mapping onto, they see it.  However, they are NOT empowered
to put anything there.

When you say "treated completely differently", how do you want them
treated? 

   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.

It is straightforward and does not involve informing non'Data'Stamps
(from now on: MapStamps).  Lets say we have:

A: DataStamp (Orgl (basicSpace (cat_Integer), {
	[ 1	-> DataObject (A,1,'a') ],
	[ 2	-> DataObject (A,2,'b') ]}))

B: DataStamp (Orgl (basicSpace (cat_Integer), {
	[ 1	-> DataObject (B,1,'c') ],
	[ 2	-> DataObject (B,2,'d') ]}))

And we want the merge them together into:

C: DataStamp (Orgl (basicSpace (cat_Integer), {
	[ 1	-> DataObject (C,1,'a') ],
	[ 2	-> DataObject (C,2,'b') ],
	[ 3	-> DataObject (C,3,'c') ],
	[ 4	-> DataObject (C,4,'d') ]}))

To do this, we sharing-inform A with:

Orgl (basicSpace (cat_Integer), {
	[ 1	-> DataObject (C,1,'a') ],
	[ 2	-> DataObject (C,2,'b') ]}))

and we sharing-inform B with:

Orgl (basicSpace (cat_Integer), {
	[ 1	-> DataObject (C,3,'c') ],
	[ 2	-> DataObject (C,4,'d') ]}))

after which there are only 4 dataObjects, and only one DataStamp (C).
A and B have both become MapStamps, and are no longer informable.  If
A B and C were partial, after the above sharing-inform operation,
they'd all still be partial but once again only C would be informable.

   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."

Quite correct, there is no one true identity.  However, as being
sharing-informed is a monotonic process, one is getting better and
better notions of identity.  Therefore it is an interesting (but
perhaps confusing) rhetorical device to speak of the true identity as
the goal which the successive EAddresses of a DataObject approach but
never reach.  Alternatively, one can think of the true identity as the
last canonical EAddress a given DataObject will ever have (at the end
of time or some such).  Given this, one can define freezing a
DataStamp wrt sharing-inform:  It is when you make an irrevocable
commitment never to further sharing-inform the DataStamp (to do this,
you mush have grabbed it).  Once this is done, you know that the
current canonical identity is the true identity.

Canonical identity is MUCH weaker than true identity: Canonical
identity is defined wrt currently & locally available knowledge.  True
identity is defined wrt knowledge which is omniscient across all time
and space.  (The kind of knowledge that the basic agent of standard
economic theory is assumed to have.  Where can we hire one?)

   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).

Now I'm totally confused.  Why should archiving ever result in a
frozen Bert of all things?  Orgls aren't data-informable, Stamps are. 

   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.

The complete operation is an inform operation on informable Stamps
(DataStamps to be specific), not Orgls.

   Freezing is an operation on Berts, not Stamps.  

Yes, there is a freeze operation on Berts.  That isn't what I'm
referring to.  See the above description.  The parallel is that when I
complete a DataStamp, I'm making an irrevocable commitment to never
data-inform it in the future.  When I freeze a DataStamp, I'm making
an irrevokable commitment to never sharing-inform it in the future.
Note that only a frozen DataStamp can be cryptographically hashed
repeatedly to verify reported identities.

   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.

Huh?  I don't get this.  EAddresses only use StampIDs, not BertIDs.
Contents of works are never addressed through their BertID, because
Berts are so non-monotonic.  What issue are you addressing.  How did
Berts come up?

   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.  

How did informing Berts come up?  Berts can't be informed (last I
looked).  What are we talking about?

It is going to be interesting to try to come up with understandable
explanations of this stuff.  I'm even more glad that first product
only reveals Docs&Links.