Description
Enhance the Architecture and Configuration to support the new Model facility. A Model can support one or more Relationships. A Context can (optionally) be associated to one (and only one) Model.
Definitions
| Name |
Description |
| Models |
A collection of one or more Model items. |
| Model |
A collection of Properties and Relationships that are used to enhance, describe, and extend a given Subject used within a Context |
| Relationships |
A collection of one or more Relationship items within a given Model. |
| Relationship |
A logical extension of a given Subject within a Context. A Relationship is related to a single Subject from the Context. A Relationship can be related to another Subject or to a collection of Subjects. |
| Views |
A collection of one or more View items for a given Model. |
| View |
A logical, single, interface to one or more Relationship items (from the same Model). The View contains the Subject core data merged with the data from all of the defined Relationship items. |
<Models>
<Properties>
<Property name="model.classname" value="org.openptk.model.BasicModel"/>
</Properties>
<Model id="Employee">
<Properties>
<Property name="model.description" value="Employee that has Manager information"/>
</Properties>
<Relationships>
<Relationship id="directReports">
<Properties>
<Property name="relationship.classname" value="org.openptk.model.ChildrenRelationship"/>
<Property name="relationship.description" value="List of children for a Subject"/>
</Properties>
<Query type="EQ" name="manager" value="${uniqueid}"/>
</Relationship>
<Relationship id="reportsTo">
<Properties>
<Property name="relationship.classname" value="org.openptk.model.AncestorsRelationship"/>
<Property name="relationship.description" value="List (ordered) of ancestors for a Subject"/>
</Properties>
<Query type="EQ" name="uniqueid" value="${manager}"/>
</Relationship>
<Relationship id="organization">
<Properties>
<Property name="relationship.classname" value="org.openptk.model.OrganizationRelationship"/>
<Property name="relationship.description" value="List (ordered) of the Subject organization"/>
</Properties>
<Query type="EQ" name="uniqueid" value="${manager}"/>
</Relationship>
<Relationship id="peers">
<Properties>
<Property name="relationship.classname" value="org.openptk.model.SiblingsRelationship"/>
<Property name="relationship.description" value="List of siblings for a Subject"/>
</Properties>
<Query type="EQ" name="manager" value="${manager}"/>
</Relationship>
<Relationship id="location">
<Properties>
<Property name="relationship.classname" value="org.openptk.model.LocationRelationship"/>
<Property name="relationship.description" value="The Location data related to the Subject"/>
</Properties>
<Context id="Location-MySQL-JDBC"/>
<Query type="EQ" name="uniqueid" value="${loc}"/>
</Relationship>
</Relationships>
<Views>
<View id="extended">
<Relationships>
<Relationship id="reportsTo"/>
<Relationship id="directReports"/>
<Relationship id="peers"/>
<Relationship id="location"/>
</Relationships>
</View>
<View id="orgstruct">
<Relationships>
<Relationship id="reportsto"/>
<Relationship id="peers"/>
<Relationship id="directreports"/>
</Relationships>
</View>
<View id="location">
<Relationships>
<Relationship id="location"/>
</Relationships>
</View>
</Views>
</Model>
</Models>
Proposed Relationship Hierarchies
Relationships were implemented based on the description above and work well. However there is a restriction to allow only one relationship below a given subject. Hierarchical relationships would be useful in several scenarios.
Use Case 1: Locations which a managers employees are assigned: A user has a relationship to their children (direct reports for a manager) and each of them have a location where the user has a attribute that (through another relationship) contains the details of the location.
This example requires that a user relationship exists which first locates all of the direct reports of the manager and returns a list of (employee) subjects then passes that output to another relationship which performs a read of a location subject for each subject in the first output. This then returns the output as a list of (location) subjects.
The following Relationships would be defined as above:
<Relationships>
<Relationship id="directReports">
<Properties>
<Property name="relationship.classname" value="org.openptk.model.ChildrenRelationship"/>
<Property name="relationship.description" value="List of children for a Subject"/>
</Properties>
<Query type="EQ" name="manager" value="${uniqueid}"/>
</Relationship>
<Relationship id="location">
<Properties>
<Property name="relationship.classname" value="org.openptk.model.LocationRelationship"/>
<Property name="relationship.description" value="The Location data related to the Subject"/>
</Properties>
<Context id="Location-MySQL-JDBC"/>
<Query type="EQ" name="uniqueid" value="${loc}"/>
</Relationship>
</Relationships>
A hierarchy could be added as follows.
Option 1: ComplexRelationship
<ComplexRelationship id="directReportsLocations">
<Relationships>
<Relationship id="directReports">
<Relationship id="location">
</Relationships>
</ComplexRelationship>
In the example above the directReportsLocations ComplexRelationship would aggregate the two relationships directReports and location. The ordered list of Relationships would be used to chain the relationships together (the output of the first would be exposed to the second and the last relationship output would be returned.
Option 2: Relationships inside a relationship
<Relationship id="directReportsLocations">
<Properties>
<Property name="relationship.classname" value="org.openptk.model.ChildrenRelationship"/>
<Property name="relationship.description" value="List of children for a Subject"/>
</Properties>
<Query type="EQ" name="manager" value="${uniqueid}"/>
<Relationships>
<Relationship id="location" />
</Relationships>
</Relationship>
The above assumes that the location relationship is defined in the Model and is a reference to it. | 