LinkObjects

Link Objects

Culprit: Ken Manheimer

This is a proposal for a new type of elementary zope object, LinkObjects, and a LinkRegistry?, by which content links are explicitly surfaced, and inherently track the location of other local content elements.

Use the Reply link in the Actions box to comment - suggestions, questions, corrections, etc. are welcome.

Problem

The interlinking between pages is, itself, a manifestation of content on a site. Not only must a content management system help site managers and contributors with the evolution of the content pages, it must also provide for the critical challenge presented by evolving site organization. It needs to provide for a way to have content links track relocation of target content elements.

Not all position changes should be tracked, however. Editors need the discretion to move content out of targeted slots without tracking. We need to distinguish between tracked relocation and non-tracked moves.

Finally, we need to keep an eye towards the future, when syndication or other site federation mechanisms could provide for tracking of reorganization across sites.

Context

Content management includes interconnection between bits of content - linking - as well as the contents of the pages themselves.

The Zope catalog internally maintains a sort of registry that may be applicable to this task. It maintains an internal mapping from an id for each object tracked by the catalog and the object's physical path. For objects that are actively cataloged, the catalog effectively is notified about and tracks location changes of an object, as well as changes to its content.

Organization Objects (see OrganizationObjectsProposal) are intended to be based on a generalization of something like the catalog, where a registry for various kinds of content relationships, not just text-specific indexes, is maintained. This proposal fleshes out part of that superstructure, sketching a requirement that uses something like the catalog's object-location registry for purposes beyond text-index resolution.

Forces

Digital Creations is increasingly focusing our efforts with Zope on content management, and management of the organization of a site is an important component of that job. In particular, Zope's flexibility makes it a prime vehicle for managing rapidly changing, evolving sites. This is an area where we can excell - and, in the emerging web-speed world, an area with ever increasing demand.

There are many uses for explicit recognition of a piece of content's links in addition to change tracking. The Dublin Core Relation attribute represents general concern with this piece of metadata. Backlinks and generic navigation links like next and previous represent structuring in a site, and so on.

Solution

Provide a mechanism so interlinking between content on a site, and incoming links from outside, can automatically track changes in the organization of the site, when appropriate.

Establish "link objects"

which indirect through an object location registry (like the one currently internal to the catalog) to get the URL (via getPhysicalPath()) of the the target objects. DTML and ZPT based documents could expressly refer to these link objects. StructuredText could use these objects instead of substiuting an href for the desired text - and, in general, this sort of approach (see the next item) will probably be the primary way that link objects are employed.

Translate content links to internal LinkObjects

For example, in html this would cover the URLs? for href and name anchors, img src, etc. StructuredText and other *ML formats have corresponding structures. (I'm referring to something like what the Parsed XML effort provides - a fast, efficient DOM storage.)

Note that the expressed form of the original link would need to be preserved. This would be to enable presentation of new location in similar style - for instance, relative versus absolute links.

[Ideally, translated documents like wvWave-parsed MS Word files, could be similarly manipulated, but i'm not clear about the impact on round-tripping or even whether editing via the wvWave parsing is possible.]

Register Intrinsic and Explicit Link References Via Event Channel

A document's intrinsic content links and other link oriented metadata (many of which would belong in the DublinCore Relation field - see the Implement the Dublin Core's Relation / Source Elements proposal) are automatically propagated via the event channel (see the OranizationObjectsProposal?) to the object location registry, and link objects are substituted for them in the document's internal representation.

Provide a new "relocate" operation

(at user and programming levels), to contrast with the existing "move".

"Relocate" would revise the indirection to the object to point to the new location, so internal links would track the change, while the old move operation would keep its old behavior, and not cause tracking of the change.

This opens the door to collective reorganization operations, like moving offspring from a CommonNameSpaces? page down to its own namespace, with all incident links to the pages tracking the change.

Institute the object/location mapping for consumption outside the site

along the lines of the XML Linking Language linkbase, so that other sites can track locations. (Presence of a linkbase entries for a document should depend on the document being freely published.)

(Note that LinkObjects also offer the basis for presenting an option for content consumers (including the author, as well as other visitors) to create the target content of internal links that don't already exist, a la ", contingent to the user having the privilege, the feature being enabled, etc. This will afford one of wiki's low-impedence features without being bound to specialized content types. See CommonNameSpaces? for more details.)

Resulting Context

A system with rich link tracking options.

Use cases:

Editor Adds or Changes Content

Content links are assessed:

• For some documents types, links are automatically identified
• Some, the editor has to explicitly specify them as metadata
• For all, user may be able to specify additional objects for metadata links - eg, next and previous, parents, etc.

Links are propagated:

• Event channel propagates edit commit, links assessed by LinkRegistry? organization object.
• If LinkRegistry? is syndicated, updates to syndication partners are queued for immediate or eventual propagation.

Links are internally represented as link objects.

Links are externally presented via consultation with LinkRegistry? - so they track current location, etc.

Visitor Traverses Document Links

They track the current location, or can indicate a stale link without the user having to traverse them (like, eg, the red superscript x that WikiForNow? uses for absent-but-uncreatable targets).

Visitor to External Site Follows Stale Incoming link

Publisher encounters "Not Found" condition, consults link registry to obtain new location. If it's a relocated object (and published at new location), publisher returns http "Address changed/Revise your URL" status (or whatever that is, i forget) with new location. If it's for a moved or deleted object (and the object is published), present an error page which indicates the new location.

Editor Relocates Content

LinkRegistry? entry for object is updated so incoming link references inherently resolve to new location.

Editor Moves or Deletes Content

LinkRegistry? entry for object marked as moved or deleted, but new location is not registered as being current. Ie, incoming LinkObject? references will not point to new location - but they can be set to indicate that they are broken until a new object falls into place, and even consulted for the new location. (LinkObjects can present links to a create form for the absent target, if the feature is enabled and the visitor is privileged.)

Editor Relocates Content Collection

Eg, via lineage gather or merge - all LinkRegistry? entries are updated to track new locations.

(See CommonNameSpaces? .)

Risks

• This proposal depends on some deep additions to Zope, depending on the infrastructure for OrganizationObjects and use of something like Parsed XML for representing content. While these are substantial projects in their own right, if they are going to be done, this seems like exactly the kind of worthwhile thing that those projects would enable.
• It may be awkward if translated foreign-format content, like pdf or wvWave converted MS Word, do not play in target-location tracking. This should be seen, however, as one of the trade-offs incumbent in using such rigid content formats - and it may be possible to back-translate just the URLs? to the original formatted documents. (Perhaps our pdf-to-html and Word-to-HTML hosting tools will enable that, if not now, eventually.)
• The distinction between moving content (hence not tracking the new location) and relocating may be subtle, and lead to user errors.

  This can be mitigated with strategically placed help, eg for the form that offers the move and relocate options.

  Another way to offer the functionality is to include a checkbox with the move button, where the checkbox has the legend "Track links" or something like that.

See Also

OrganizationObjectsProposal

Parsed XML

XML Linking Language

"Implement the Dublin Core's Relation / Source Elements", metadata/dublin_core_relation