The Chandler Project Blog

Natively, the repository supports two ways of finding any item, by Universally Unique IDentifier (UUID) and by Path.

1. Current item locators

   Natively, the repository supports two ways of finding any item, by Universally Unique IDentifier (UUID) and by Path. The UUID works as a unique and constant persistent pointer to an item that is valid for the life of the item while the Path to an item is a sequence of intrisically named items acting as containers describing the item’s current location in the repository. Paths can be expressed relative to any items or can be rooted with the repository.

   There can be only one UUID leading to a given item and there can only be one absolute canonical path leading to a given item. Because of this unicity constraint, attaching domain specific meaning to the canonical location of an item is bound to result in clashes since an item can serve more than one domain specific – semantic – purpose.

   The following is a proposal to implement an additional mechanism for locating items that is semantically rich and not constrained in the same ways.

2. Definitions

   a. Bi-directional references

   A bi-directional reference between two items is defined by two attributes – the endpoints of the reference – each containing a pointer to the item being referenced.
   For example:

   Let ‘A’ and ‘B’ be two items and ‘p’ and ‘q’ be two attributes defined on ‘A’ and ‘B’ respectively. If ‘q’ is defined to be the ‘otherName’ of ‘p’, and ‘p’ is defined to be the ‘otherName’ of ‘q’, the act of storing a reference to ‘B’ in ‘p’ automatically causes a reference to ‘A’ to be stored in ‘q’, namely:

   A.p = B causes B.q = A
   and
   A.p.q == A
   B.q.p == B

   b. Ref collections

   A ref collection on an item is defined as an endpoint attribute on this item with a multi-valued cardinality. The cardinality of each endpoint is defined independently of each other. For example, the above ‘p’ attribute could be of ‘list’ cardinality while the corresponding ‘q’ attribute is of ’single’ cardinality.
   For example:

     A.p.add(B)  causes  B.q = A
   and
     A.p.get(B).q == A
     B.q.p.get(B) == B
   

   A ref collection is implemented as an ordered set of item references keyed on the UUIDs of the items being referenced. An item can only be referenced once in a given ref collection. The above get(B) operation is actually defined as get(B’s UUID).

   c. Ref aliases

   When stored in a ref collection, the reference to an item can be assigned a name – a ref alias – by which it can also be looked up in the ref collection.
   For example:

     A.p.add(B, 'b')  causes  B.q = A
   and
     A.p.get('b').q == A
     B.q.p.get('b') == B
   

3. Ref collection-based path spaces

   A ref collection-based path space is defined by a well-known root and a directed pair – up, down – of endpoint attributes.
   For example:

   Let ‘R’ be a root and ‘p’ and ‘q’ be two endpoint attributes having each other as ‘otherName’. Let also ‘q’ be of ‘list’ cardinality and be the ref collection used in the down direction of the path. The cardinality of the ‘p’ attribute, the up direction of the path is irrelevant in this example, it could be ’single’ or ‘list’. Dereferencing the path /a/b/c/d in this space is equivalent to the following operation:

   R.q.get(’a').q.get(’b').q.get(’c').q.get(’d')

4. Properties of ref collection-based paths

   There can be a reference to a given item in any number of ref collections. Each of these references can be assigned its own name, a ref alias, independently of each other.

   Therefore, while each path leads to a different item reference, these item reference may yield the same item and:

   (a) in a given ref collection-based path space, there can be any number of ref collection-based paths leading to a given item.

   Since each ref collection-based path space is defined a by a well-known root and a pair of endpoints attributes defined in the data model’s schema:

   (b) a given item may be referenced by a ref collection-based path in a given space if and only if it is of a kind declaring the attribute for the up direction of the directed endpoint pair.

   (c) a given item may act as a container in a given space if and only if it is of a kind declaring the attribute for the down direction of the directed endpoint pair.

   Consequently:

   (1) a ref collection-based path space defines a semantic space in which items can be arranged in a hierarchy.

   (2) ref collection-based paths are semantically pure.

5. Implementation details

   a. Unicity

   (1) A reference to a given item is unique within a given ref collection

   (2) An alias to a reference is unique in a given ref collection

   While it would be difficult to lift the first constraint, the second one could be lifted. It is unclear whether this is necessary or desirable. Having a given ref collection-based path resolve to several item references instead of one would make exporting such paths more difficult.

   b. Well-known root

   It is desirable to define a way to cache the well-known root for a given ref collection-based path space. Currently, caching the root item on the attribute schema item for the down direction endpoint is being considered and reflects the attribute-centric approach used to define such path spaces.

This entry was posted on Monday, May 24th, 2004 at 7:05 pm and is filed under chandlerdb. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.