Re: Optional Backpointers from Targets to References

These points are valid and represent well what our experience has been here at Novell with our GroupWise document management.  We allow users to create references to documents.  The documents exist in the library database, while the references exist in a user's folders.  A given document can have an unlimited number of references pointing to it and there are valid reasons for wanting those backpointers (yes, we do use backpointers in a real-world solution).

Generally we have seen no business need for Jim's second statement, the ability to discover all folders containing a reference to a given document.  In reality, we don't care what folders contain the references.  More important for us the ability to discover those references (via the backlinks) regardless of where they exist.  We use the discovery to "update" the references, which for us contain key data that gets displayed when a user sees a list of the document references.  So, for example, we store the subject as part of the reference.  That way, when the reference is displayed we don't have to hit the database to get the subject but have it already as part the reference's data.  When a user changes the document's subject, we follow all of that document's backpointers and inform each of the new subject.

In a URI-based system (as with WebDAV), Jim's case #1 also represents a completely valid use for backpointers.

>>> Jim Davis <jdavis@parc.xerox.com> 09/22 12:44 PM >>>
Jim Amsden and other have asked me to explain the usefulness of the
backpointer.

Before I do, I want to emphasize that I am well aware that there are many
reasons why a server couldn't or shouldn't provide backpointers from *all*
targets  to *all* references.  I hope here only to show that there are
*some* applications for which this is useful, and then to argue that it's
worthwhile standardizing the protocol so that  applications that *do* use
this feature will have a standard way to access it on those servers that
happen to provide it.

Reasons it is useful:

1) Referential integrity.  Some applications desire references that are
guarenteed to remain valid, even when the target moves.  The easiest way to
do accomplish this is by storing back pointers from the target to the
reference.
While there is no requirement that the backpointer be exposed in the
interface, there is no harm in doing so.

2) Multiple containment.  Some document management systems have an abstract
notion of a 'document' that can be in many 'folders'.  For any such
document, it is sometimes necessary to obtain the set of folders in which
it appears.  The most direct mapping of these abstractions to WebDAV
(assuming Advanced Collection Resources) is:
 folder ::  WebDAV collection
 document ::  WebDAV resource
 containment :: WebDAV reference

That is, if document D is in folder F, there is a reference resource in F
whose target is D. Then, to find the set of all folders {F, G, H...} that
contain
document D, one first obtains the set of backpointers on D, then
(trivially) obtains the set of collections that contain those references.

3) Generality/Extensibility:  Backpointers are used in countless data
structures (consult any textbook on data structured or algorithms).  There
will certainly be uses we can't anticipate now.  The 'multiple containment'
example above is just the first one.

I hope to have demonstrated the usefulness of the dav:references property.
It will be optional, and hence cost-free, but useful to those applications
and servers who need it.

Received on Wednesday, 23 September 1998 11:36:45 UTC