Perfectly sensible.
The crux, of course, is that a link to a versioned object
needs a mechanism for specifying what it wants -- latest
version, original version, or specified version.
I especially like that link objects chain to later versions,
as well as to earlier ones, because that makes it possible to:
a) Follow the link to the document proxy
b) Follow the chain to the latest version (assuming the
default is "link to latest version").
That operation matches existing semantics, while allowing
for accessing fixed-version/specified version, as well.
Two points:
a) A link attribute is needed to specify "fixed version".
Assuming that the "fixed version" was specified by tacking
an additional field onto the link (htpp://...#fixed), then
the accessing browser need know nothing about the process
-- the access-management is totally handled by the server.
b) An unexplored issue in the discussion is what happens
when versions branch. Assuming I read this part
correctly:
"A version with multiple next versions represents a
branching from one "development track" to two or more."
Then the versioning scheme wants to allow for multiple
branches. But in that case, how does the server resolve
a link to the "latest version", when there are competing
versions to choose from?
Murray Altheim wrote:
>
> To those of you who know Eliot Kimber, this message is no surprise.
> Eliot is one of the most brilliant people I've met in the computing
> field, and a co-author of the Hytime specification. He's also one of
> the nicest and most generous in being willing to take the time to
> explain complex ideas to relative novices (like me) over the years.
>
> I'm forwarding this into the list because it has strong overlap with
> some of the OHS requirements regarding versioning. At this point the
> project he describes is proprietary to DataChannel (who owns Isogen,
> the company he works for), but as he states in his message, the specs
> are public and he's hoping to open source it at some point.
>
> -------- Original Message --------
> Subject: Re: [topicmapmail] TMs and Versioning
> Date: Wed, 11 Jul 2001 11:16:00 -0500
> From: "W. Eliot Kimber" <eliot@isogen.com>
> Reply-To: eliot@isogen.com
> Organization: DataChannel, Inc
> To: Topic Map Mail <topicmapmail@infoloom.com>
> References: <MBBBJFPGEFFJABFNFAKMMEDNCAAA.bcngroup@erols.com>
>
> Paul Stephen Prueitt wrote:
> >
> > Patrick's dialog with Jaworski is informative in several regards.
> >
> > I wonder if the notion of version might have with it the notion of
> > aggregation (into a category structure) from the past to the present. Some
> > type of reinforcement learning might make modifications to the "current"
> > topic map, in order to reflect lessons learned. So, the current topic map
> > might reflect a situated ness that has the context of an evolution as well
> > as a relevance to the present.
>
> In the versioning link management system we're building in Austin, we
> have the concept of "resource" (not particularly original to version
> control), which is the set of all versions in time of a "thing" (where
> "thingness" is asserted by the person creating the resource and its
> versions--we impose no particular rules for mapping resources to
> real-world objects). Each version of a resource knows about all its
> previous and all its next versions (if any). This means that versions
> can be related in a directed graph. Versioning as this level is of
> "storage objects" (and, more completely in our implementation, entities
> in the XML sense).
>
> A version with multiple previous versions represents some sort of merge
> of the previous versions (or simply a selection among multiple possible
> precursors to use as the latest version). A version with multiple next
> versions represents a branching from one "development track" to two or
> more.
>
> Thus, the system maintains all the information needed to remember the
> evolutionary history of the components of a topic map. In addition, we
> provide "pointers" that are arbitrary relations between versions and
> other resources--these can be used to capture any sort of dependency
> reflecting any business logic. For example, in topic map authoring
> application you might have specialized dependencies that reflect things
> like "source used as base for forming new argument" or "merge source" or
> whatever. In our base system we use pointers to remember the
> document-to-document dependencies inherent in XML and in HyTime (e.g.,
> entities declared by, bounded object set membership, etc.).
>
> By using a simple form of indirection ("referent tracking documents"
> (RTDs) as defined by myself and Peter and Steve Newcomb in our paper to
> XML 1999), this storage object versioning mechanism can be extended to
> the versioning of hyperlink references by creating for a *target* thing
> a proxy document that represents the thing pointed at. These proxy
> documents are themselves versioned such that for a given semantic
> "referent" (a thing pointed at for a particular rhetorical or practical
> purpose), you can know what specific thing that referent was represented
> by at any point in time. Because the RTDs can point to anything
> addressible, they can be used to effectively track versions of
> individual elements within larger documents, for example (or in fact,
> versions of any nodes in any groves of any type the underlying system is
> capable of managing). This allows for unbounded precision in your
> versioning memory at essentially constant cost regardless of the
> granularity chosen (that is, it costs the same to point to an entire
> document as it does to one character).
>
> If a referer (e.g., an occurrence pointed to by a topic or association
> role member pointed to by an association) points to the RTD *resource*,
> the resolution of the pointer to a version or versions of the RTD is
> dependent on an arbitrary selection algorithm applied at the time the
> pointer is resolved, e.g., "latest available", "current as of time x",
> "with property y value w", etc. If the a referrer points to a specific
> version (or versions) the reference is hardened. Once a version or
> versions have been retrieved, the pointers they contain are resolved to
> the ultimate target of the RTD, the referent itself.
>
> This mechanism makes it possible to maintain complete knowledge of the
> version-to-version relationships of things over time while enabling
> version-independent reference to those things. It enables the creation
> of hyperlinks that are insensitive to the versioning details of the
> things related. It allows for dynamic construction of result hyperdocs
> (and thus result topic maps) by varying the algorithms used to resolve
> references to RTDs. For example, you can easily ask the question "what
> was the effective topic map at time "x").
>
> [By further organizing versions into different branches, you can gain
> further control by limiting the resolution of pointers to versions on a
> particular branch. For example, a resource may have two versions current
> at the same time, one in each of two branches. By making your selection
> criteria "versions current at time X in branch Y", you can further
> control the history. In an authoring system, different branches might
> represent different stages of completeness (e.g., a development branch,
> a review branch, and a published branch). (From a management standpoint,
> branches also allow for control of access to versions by limiting a
> user's access to a particular branch.)]
>
> I think this mechanism satisfies all the requirements inherent in Paul's
> statement above. Enabling and doing what Paul describes is one of our
> chief motivators for building this system. In particular, we see our
> system as a base for enabling enterpise-scalable topic map systems of a
> very general nature.
>
> We have not yet had time to integrate any topic map implementations with
> our system, but it is certainly in our plan to do so. In one sense, a
> topic map system could be a relatively simply extension module built on
> top of our basic linking and version management facilities. We have
> certainly architected the system to expressly enable that sort of
> extension.
>
> [Unfortunately, this system is current proprietary DataChannel
> technology that we are not at liberty to sell or give away except in the
> context of professional services engagements. However, we are trying to
> find a way to open source some or all of it sooner rather than later.
> But, the basic architecture is publicly defined (in large part in our
> RTD paper) so there is nothing preventing others from implementing this
> approach.]
>
> Cheers,
>
> E.
> --
> . . . . . . . . . . . . . . . . . . . . . . . .
>
> W. Eliot Kimber | Lead Brain
>
> 1016 La Posada Dr. | Suite 240 | Austin TX 78752
> T 512.656.4139 | F 512.419.1860 | eliot@isogen.com
>
> w w w . d a t a c h a n n e l . c o m
> _______________________________________________
> topicmapmail mailing list
> topicmapmail@infoloom.com
> http://www.infoloom.com/mailman/listinfo/topicmapmail
>
> ...........................................................................
> Murray Altheim <mailto:murray.altheim@sun.com>
> XML Technology Center
> Sun Microsystems, Inc., MS MPK17-102, 1601 Willow Rd., Menlo Park, CA 94025
>
> In the evening
> The rice leaves in the garden
> Rustle in the autumn wind
> That blows through my reed hut. -- Minamoto no Tsunenobu
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:58:07 PDT