Storing and Presenting "Relations" Data at MIT

I. Relations

I.a. What are Relations?

A "Relation" will be a three-part entity consisting of a subject, a verb, and an object. It will be somewhat similar to an Authorization in the Roles Database, except that it will represent data about some connection between a person (or more generally, an agent) and another object. A Relation may exist as a record in a database table, or it may be a "virtual" record, implied or derived dynamically from other data. In general, a Relation, whether "real" or "virtual", will have the following format:

Person or agent	Relation function	Object	Start date	End date (optional)
The person or agent who is the "subject"	A verb or connector between the subject and the object	The object to which the person/agent is related	The beginning date on which the relation was recorded	Optionally, the date on which the relation will no longer be in effect. If NULL, then there is no recorded end date.

Here are some examples of the sort of data that might be stored in Relations. We will omit the Start_date and End_date fields for simplicity.

Person or agent	Relation function	Object
Joe	Is faculty/staff member	Org Unit 10000429 Department of Biology
Sue	Is student	Course 18 Mathematics
Mary	Has completed EHS training	Unit 100 General Chemical Hygiene
Carl	Is parent of student	Rob

I.b. Components of a Relation

A Relation has three main components, defined as follows.

Person or agent

In many cases, a relation will connect a person to some other object, or to a different person. A system for storing and retrieving relations should allow for other sorts of "agents" (subjects) as well, such as services, organizational units, groups, etc..

When creating a relation, the person/agent is picked from a list of valid agents. Each agent will have a unique identifier (such as an MIT ID number or a Kerberos principal). Agents all have a type, e.g., (i) MIT internal person, (ii) external person, (iii) group, (iv) MIT 8-digit org unit, etc..

Relation function

This is the connector, or "verb". It will have a name and a unique identifying numeric ID.
Each relation function (RF) belongs to a "domain".
Each RF has an associated agent type and one or more object type. Any relation created with a given RF must have an agent of the appropriate type and an object of one of the appropriate types.
Each RF also has an associated object-hierarchy, which organizes objects. Any relation created with a given RF must have an object that falls within the appropriate object-hierarchy.
An RF can have one or more child RFs or parent RFs -- a relation for a given agent, RF, and object implies similar relations for child RFs.

Object

This is the "object". The agent is connected to this object via the RF. Objects are picked from previously-defined hierarchies of objects.
Each object is of a specific type, and belongs to at least one object hierarchy (or more specifically a web, since a given object may have more than one child and more than one parent, though an object cannot be its own descendant or ancestor.)
Each object will have a code, unique within the object type and unique within any object hierarchy to which it belongs.

Data Model for Relations

Other entities will represent groups of each of the main components:

• Persons/agents will be grouped into Agent Types

  An agent-type may be (i) a person, (ii) a server, (iii) a group, etc.

• Relation-functions will be grouped into Domains

  A domain is a group of related types of data. Domains will be used to control access to the data, i.e., Authorizations will be created that limit a user or server's access to limited Domains. They also can be used to specify a set of data (falling under the same Domain) that can be requested in a single API call.
  Domains may be organized into a hierarchy (or more accurately, a web).

• Objects will be organized into Object-hierarchies

  Each Object-type is associated with one or more object-hierarchies (or more accurately, webs). An object-hierarchy may contain objects of more than one object-type.

• Each object belongs to one object-type.

  For example, within the object-hierarchy of Departments, there will be objects of types (i) root, (ii) high-level node, (iii) school or area, and (iv) DLC (department, lab, or center).

I.c. Why use Relations for storing and retrieving data?

Relations are a simple and consistent way of representing "atoms" of data. In some situations, this representation has advantages over other ways of organizing data, such as records or more complex structures.

Here are some advantages that are offered by the use of Relations to represent data:

• It will be easy to build a consistent interface for distributing the data to applications
• The organization of the Relation-function (verb) and Object components into hierarchies accommodates the building of authorizations for access to limited amounts of data
• The format makes it easy for an application to get a yes/no answer to questions about a person or agent, e.g., "Is this person a current student with a major in some course under the School of Science?"
• The format also accommodates simple questions of the form "For person X and relation-function Y, what are all of the objects for which the person has that relation?"
• The simple format lends itself to building rules whereby a Relation implies an Authorization (see examples in later sections of this document).
• The format lends itself to building future workflow services. It will be easy to construct workflow rules based on the simple and consistent format of Relations.
• We have confidence that we can build interfaces for Relations, use them effectively, and control access to them because of our experience with similar 3-part entities, the Authorizations in the Roles DB.

I.d. Data flow into and out of Relations

The details of the implementation of data flow through Relations will change over time. However, we want the interface presented to applications to remain constant, even if the back end evolves in its approach to handling data.

There should be interfaces that permit these actions by a server:

Interface options presented to applications, independent of how data will be handled by the back-end

• Ask a yes/no question about an implied authorization derived from Relations data, e.g., "Can user X perform Function Y with Qualifier Z?" (Note that the answer will be "Yes" regardless of whether the Authorization is an implied one or one that was explicitly granted to the end-user using the Roles DB application.) The permission to get an answer to this question is controlled by other authorizations.
• Ask other questions about implied authorizations derived from Relations, e.g., "For what Qualifiers can user X perform Function Y?" The permission to get an answer to this question is controlled by other authorizations.
• Ask a direct question about the existence of a Relation for a person or agent e.g., "Does agent A have a relation for relation-function F to object O?" The permission to get an answer to this question is controlled by authorizations.
• Ask other questions about Relations, e.g.,
  • "What relations does person P have within domain D?"
  • "For which objects does person P have a relation where the relation-function is F?"
  Access to the answers to these questions will be controlled by authorizations.

The back-end processing will evolve over time. We might see one or more of the following implementation strategies exist for various relations over time.

Strategies for handling relations in the back-end

• Relation data is extracted from data in the Warehouse by a batch extract program and inserted into a table of Relations
• Relation data is dynamically derived from data in the Warehouse data via back-end processes without needing to replicate it in a separate physical table
• Relation data is obtained in real-time directly from the System of Record: The middle tier that supports Relations and implied authorizations calls an interface maintained by the System of Record

II. Relations and implied Authorizations

Rules will be defined for deriving implied Authorizations from Relations. Each rule will be of type 1a, 1b, 2a, or 2b, all of which work in slightly different ways. Note that there can be more than one rule for a Relation Function, and more than one rule for a Roles DB Function. Rules are always "additive", i.e., if any rule applies, then the implied Authorization is put into effect. There are no "negative" or exception rules.

II.a. Types of rules for implied authorizations

Types of rules for deriving Implied Authorizations

Type 1a	Where there is a relation for a person such that		generate an implied authorization for the person where
	Relation-function is...	and relation-object has object-type...	Function is...	and qualifier is...
	a given relation-function (or a child of the relation-function)	a given object-type T1	a given Roles DB function	the same object as the relation object
Type 1b	Where there is a relation for a person such that		generate an implied authorization for the person where
	Relation-function is...	and relation-object has object-type...	Function is...	and qualifier is...
	a given relation-function (or a child of the relation-function)	a given object-type T1	a given Roles DB function	the parent object of the relation object of object-type T2
Type 2a	Where there is a relation for a person such that		generate an implied authorization for the person where
	Relation-function is...	and relation-object is...	Function is...	and qualifier is...
	a given relation-function (or a child of the relation-function)	a specified object O	a given Roles DB function	a specified qualifier Q
Type 2b	Where there is a relation for a person such that		generate an implied authorization for the person where
	Relation-function is...	and relation-object is...	Function is...	and qualifier is...
	a given relation-function (or a child of the relation-function)	either a specified object O or a descendant of object O	a given Roles DB function	a specified qualifier Q

II.b. Examples of implied authorization rules

Below, we'll list some examples of implied Authorization rules.

Rule type	Relation-function	Relation-object type (for types 1a and 1b)	Relation-object (for types 2a and 2b)	Function	Qualifier is parent object with object-type (type 1b)	Qualifier (for types 2a and 2b)	Notes
1a	EHS REPRESENTATIVE	room sets		VIEW ROOM SET INFO			Any EHS REPRESENTATIVE for a room set can view online data about that room set
1b	EHS REPRESENTATIVE	room sets		VIEW EHS TRAINING REPORT	parent object of type DLC/PI		Any EHS REPRESENTATIVE for a room set can view EHS training data related to the DLC/PI unit (Princ. Investigator within a DLC) that manages the room set
2a	IS FACULTY OR STAFF		Sloan school	VIEW LIBRARY MATERIALS		Acme Management Journal	Access rule applies only to employees of the Sloan school
2a	IS STUDENT		Sloan school	VIEW LIBRARY MATERIALS		Acme Management Journal	Access rule applies only to students of the Sloan school
2b	IS FACULTY OR STAFF		All depts.	VIEW LIBRARY MATERIALS		Group of all MIT-accessable materials	Any faculty/staff member can view this set of materials
2b	IS STUDENT		All courses	VIEW LIBRARY MATERIALS		Group of all MIT-accessable materials	Any faculty/staff member can view this set of materials
2b	IS FACULTY OR STAFF		Branch of the org unit hierarchy that excludes Lincoln Lab, Haystack, and Whitehead	VIEW LIBRARY MATERIALS		Group of on-campus-only materials	Faculty/staff members within limited set of DLCs can view this set of materials

II.c. Diagram of Relations and implied Authorization rules

III. Access to relations data

In the previous section, we've discussed how we can define rules whereby Relations can imply Authorizations for a wide range of Functions.

In this section we will discuss a different Authorization issue: How do we create and apply Authorizations to control access for viewing or updating Relations data?

We can define a comprehensive set of rules for applying people's Authorizations (or servers' Authorizations) in the Roles Database to determining which Relations data they are allowed to view. Below we will only show examples for allowing people to view data, but in the future, similar sorts of rules can be written to control who can update Relations data as well. (Note that we will be showing ways of mapping Authorizations from the Roles Database into sets of Relations viewable by people with those Authorizations. If we combine these rules with the rules described in section II [where Relations data implies Authorizations], then we can see that it is possible to define rules that allow people with one sort of Relation to view data about other sorts of Relations.)

Rules for translating Authorizations into which Relations a person can view will be of three types:

1. Authorizations based on the Object component of the Relation to be viewed,
   i.e., an Authorization allows a person to view Relations for a given set of Relation-Functions, a given set of Objects, and any Agent
2. Authorizations based on the Agent component of the Relation to be viewed,
   i.e., an Authorization allows a person to view Relations for a given set of Agents, a given set of Relation-Functions, and any Object
3. Authorizations for ones own Relations,
   i.e., a rule allows all people to view Relations for a given set of Relation-Functions where the Agent component matches the person viewing the Relation

III.a. Types of rules for who can view Relations data

Types of rules for viewing Relations data

Type 1	If a person has an Authorization where	allow the person to view Relations such that
	Function is...	Relation-function is...	and relation-object is...
	a given Roles DB function	any relation-function within a given Domain	the same as or a child of the Qualifier from the Authorization
Type 2	If a person has an Authorization where	allow the person to view Relations for agent A such that
	Function is...	Relation-function is...	and there exists a different Relation for agent A where Relation-Function is...	and relation-object is...
	a given Roles DB function	any relation-function within a given Domain	a different specified relation-function RF2	the same as or a child of the Qualifier from the Authorization
Type 3	For any person regardless of their Authorizations	allow the person to view Relations such that
		Relation-function is...	and relation-object is...
		any relation-function within a given Domain	the same as the person who wants to view the data

III.b. Examples of rules for who can view Relations data

Rule type	Function (Types 1 and 2)	Domain for viewable relation-functions	Relation-function applicable to viewable agents (Type 2)	Notes
1	VIEW EHS ROOM SET DATA	People affiliated with PIs and Room Sets		If you have an authorization to VIEW EHS ROOM SET DATA for a DLC, DLC/PI, or Room Set, then you can view Relations data in the domain "People affiliated with PIs and Room Sets".
2	VIEW EHS TRAINING REPORT	EHS Training Data	TRAINEE IS AFFILIATED WITH DLC/PI	If you have a VIEW EHS TRAINING REPORT authorization for a given DLC or DLC/PI and if a given EHS trainee has a Relation that links the person to that DLC/PI, then then you can view all Relations data for that trainee under the domain of EHS Training Data.
3		HR Records		Anyone can view their own Relations data in the domain of HR Records.