Data Model Proposal Alternative One

This page presents a proposal alternate to Data Model Proposal in which a directory-like model is used as a basis, thus allowing the model to be surfaced using an established, well-known programming interface (such as JNDI). The goal of this proposal is to allow analysis of the relative benefits and drawbacks of re-using this particular known model (and subsequently API).

This proposal aligns itself with the goals given in Data Model Goals M4.

Contexts and DigitalSubjects

There are a number of obvious ways, using a directory model, to represent the notion of there being a set of Contexts, each containing a set of DigitalSubjects.

1. Hierarchical:
   • Each Context would be presented as an entry immediately subordinate to the directory root. Note that the directory root is named by the null name, thus each context would be named something like “context=MyBuddiesList”.
   • Each DigitalSubject would be presented as an entry immediately subordinate to the Context which it is in. To continue using directory naming, a DigitalSubject would be named like “subject=August West,context=MyBuddiesList”.
2. Hierarchical With Hierarchical URI Names:
   • Same thought as above in terms of hierarchy, but use URIs in the names like: “subject=xri://August.West,context=@MyBuddiesList”
3. Hierarchical With Flat URI Names:
   • Same as above, but here, we bend the rules a bit. Rather than using a hierarchical name, all names would appear to be in a flat namespace like: “subject=xxx://MyBuddieList/August.West”. Note that using this solution would still allow the representation of a Context as containing a set of DigitalSubjects, it just doesn't tie the subjects' identifiers to the hierarchy. <todo: move this to another page and link from here: One may argue that this breaks traditional X.500 naming rules, but this isn't entirely true. Imagine a directory server which has objects in a hierarchy where all subordinate objects are merely aliases to top-level objects and where the server always dereferences aliases. This would result in the same behavior. This is only a counter-argument, not a suggestion to actually represent the data in this way. When mapping this model to actual directory data, it's more reasonable to simply rewrite the name of the objects.>

In any of these ways, the relationship between a Context and its set of DigitalSubjects is the same. This allows normal, existing parent/child operations to be used.

Context Relationships

Where an association between contexts is to be made, two obvious solutions come to mind:

1. An attribute on the source context may be employed. This attribute could be called “relatedContext” and it's format could allow for a number of fields including the identifier of the related context(s), as well as metadata such as valid times, etc. Each value of this attribute defines the relationship of this context with another (or a set of others). Note that a similar attribute on the destination context could be employed if a backlink is needed.
2. Context Relationship objects which are immediately subordinate to (thus viewed as contained by) the Context object could represent these relationships. A Context Relationship's objectClass (type) would be used to differentiate it from DigitalSubject objects. This object would hold attributes such as “relatedContext” and other metadata. The benefit of this solution is that it allows easier separation of per-related-context data.

Typed Digital Subjects

The objectClass attribute could be used to denote the type of digital subject (this is the typical 'directory' way of doing it), or some other attribute may be used. The problem with “objectClass” is that it's syntax (type) limits the allowed format to be a very limited, simple alpha string. Thus it's likely that some new attribute would be used.

Attributes of DigitalSubjects

The most obvious solution here is to simply use directory attributes. These have an identifier, and a set of values.

Attribute Types

<todo: need feedback on what goal #6 on Data Model Goals M4 means in terms of “type”>

Attribute Values

The type of an attribute value is controlled by that attribute's schema definition, and specifically by the syntax definition associated with that attribute. It may be desirable to define a set of higgins syntaxes (likely, one uber higgins syntax which could be derived into any other needed syntax). A higgins syntax would allow for (probably named) metadata to be attached to values of that syntax. One specific metadata element would be reserved for the attribute value's source (resolvable to an DigitalSubject in another more "meta" context).

Attribute values in a directory may be defined to be compound or singular.

DigitalSubject Relationships

There are two obvious ways of solving this requirement. These are identical to the two solutions given for Context Relationships. In these solutions the attribute used could be named “relatedSubject”.

DigitalSubject Relationship Types

Depending on the solution picked for DigitalSubject Relationships, The type is either metadata on the relatedSubject attribute, or in the case of solution 2, could be an attribute itself (named something like “relationshipType”), or the objectClass attribute (see Typed Digital Subjects discussion above)

DigitalSubject Relationship Properties

Again, this depends on the solution picked for DigitalSubject Relationships. The properties are either metadata on attributes, or attributes on objects. If defined as attributes on objects, the directory data model allows for what are called “operational attributes”. These are effectively attributes hidden unless specifically asked for.

Addressing

For Contexts and DigitalSubjects, this is discussed above in Contexts and DigitalSubjects. The same scheme would apply to relationships if those were modeled as objects rather than attributes.

For Attribute names, it gets slightly sticky. Traditional X.500 directories limit the character set used to name attributes. Here is where we would likely break away slightly from strict adherence to an X.500 model and allow any string (or more likely, any URI). What would this mean in terms of using traditional directory APIs? In the case of JNDI, nothing – Attribute identifiers are a String. Extremely strict applications (which currently consume JNDI) may need to be relaxed. It's quite unlikely that these types of applications exist.

Fully Qualified Data

See discussions above on Contexts and DigitalSubjects and Addressing.

DigitalSubject Joining

The number of virtual directory products in existence (i.e. Penrose) are evidence that this may be done.

Multilevel Context Provider Support

This isn't strictly a data model topic, but it's on the Data Model Goals page so we'll address it. As long as the DigitalSubject Joining requirement is met, this goal should be met. However, if the goal is to present a model whereby one Context may hold subordinate Contexts, and this hierarchy is presented to the consumer (I don't think this is what the goal is getting at), then this goal may be met simply by representing subordinate Contexts as objects subordinate to the higher Context (differentiation of sub-Contexts and DigitalSubjects would be done using the objectClass or some other attribute).