Osid

OsidObject is the top level interface for all OSID Objects. An OsidObject is an object identified by an OSID Id and may implement optional interfaces. OsidObjects also contain a display name and a description. These fields are required but may be used for a variety of purposes ranging from a primary name and description of the OsidObject to a more user friendly display of various attributes.

Creation of OsidObjects and the modification of their data is managed through the associated OsidSession. The OsidManager is used to create the appropriate OsidSession for OsidObject creation, updates and deletes.

All OsidObjects are identified by an immutable Id. An Id is assigned to an object upon creation of the object and cannot be changed once assigned.

An OsidObject may support one or more supplementary records which are expressed in the form of interfaces. Each record interface is identified by a Type. A record interface may extend another record interface where support of the parent record interface is implied. In this case of interface inheritance, support of the parent record type may be implied through hasRecordType() and not explicit in getRecordTypes().

For example, if recordB extends recordA, typeB is a child of typeA. If a record implements typeB, than it also implements typeA. An application that only knows about typeA retrieves recordA. An application that knows about typeB, retrieves recordB which is the union of methods specified in typeA and typeB. If an application requests typeA, it may not attempt to access methods defined in typeB as they may not exist until explicitly requested. The mechanics of this polymorphism is defined by the language binder. One mechanism might be the use of casting.

In addition to the OsidRecord Types, OsidObjects also have a genus Type. A genus Type indicates a classification or kind of the object where an "is a" relationship exists. The purpose of of the genus Type is to avoid the creation of unnecessary record types that may needlessly complicate an interface hierarchy or introduce interoperability issues. For example, an OsidObject may have a OsidRecord Type of Publication that defines methods pertinent to publications, such as an ISBN number. An OSID Provider may wish to distinguish between books and journals without having the need of new record interfaces. In this case, the genus Type may be one of Book or Journal.While this distinction can aid a search, these genres should be treated in such a way that do not introduce interoperability problems.

Like OsidRecord Types, the genus Types may also exist in an implicit type hierarchy. An OsidObject always has at least one genus Type. Genus types should not be confused with subject tagging, which is managed in the Ontology OSID. Unlike OsidRecord Types, an OsidObject genus Type may be modified. However, once an OsidObject is created with a record Type, it cannot be changed.

Methods that return values are not permitted to return null. If a value is not set, it is indicated in the Metadata of the update OsidObjectForm.

A Relationship associates two OSID objects. Relationships are transient. They define a date range for which they are in effect.

Unlike other OsidObjects that rely on the auxiliary Journaling OSID to track variance over time, OsidRelationships introduce a different concept of time independent from journaling. For example, in the present, a student was registered in a course and dropped it. The relationship between the student and the course remains pertinent, independent of any journaled changes that may have occurred to either the student or the course.

Once the student has dropped the course, the relationship has expired such that isEffective() becomes false. It can be inferred that during the period of the effective dates, the student was actively registered in the course. Here is an example:

• T1. September 1: Student registers for course for grades
• T2. September 10: Student drops course
• T3. September 15: Student re-registers for course pass/fail

The relationships are:

T1. R1 {effective,   September 1  -> end of term,  data=grades}
T2. R1 {ineffective, September 1  -> September 10, data=grades}
T3. R1 {ineffective, September 1  -> September 10, data=grades}
    R2 {effective,   September 10 -> end of term,  data=p/f}
                        

An OSID Provider may also permit dates to be set in the future in which case the relationship can become automatically become effective at a future time and later expire. More complex effectiveness management can be done through other rule-based services.

OSID Consumer lookups and queries of relationships need to consider that it may be only effective relationshps are of interest.

OsidCatalog is the top level interface for all OSID catalog-like objects. A catalog relates to other OSID objects for the purpose of organization and federation and almost always are hierarchical. An example catalog is a Repository that relates to a collection of Assets.

OsidCatalogs allow for the retrieval of a provider identity and branding.

Collections visible through an OsidCatalog may be the output of a dynamic query or some other rules-based evaluation. The facts surrounding the evaluation are the OsidObjects visible to the OsidCatalog from its position in the federated hierarchy. The input conditions may satisifed on a service-wide basis using an OsidQuery or environmental conditions supplied to the services via a Proxy.

Often, the selection of an OsidCatalog in instantiating an OsidSession provides access to a set of OsidObjects. Because the view inside an OsidCatalog can also be produced behaviorally using a rules evaluation, the Id (or well-known alias) of the OsidCatalog may be used as an abstract means of requesting a predefined set of behaviors or data constraints from an OSID Provider.

The flexibility of interpretation together with its central role in federation to build a rich and complex service from a set of individual OSID Providers makes cataloging an essential pattern to achieve abstraction from implementations in the OSIDs without loss of functionality. Most OSIDs include a cataloging pattern.

OsidRequest is the top level interface for OsidObjects used to submit and process transactional requests. An OsidRequest typically has a submitting Agent and is acommpanied by a set of request item Subjugateables reprsenting the parts or line items of the OsidReques t.

OsidRequests have an explicit state model:

• not submitted
• submitted
• processed
• error
• cancelled

Additional states may be added through an OsidRecord or orchestrated Process.

An OsidRule identifies an explicit or implicit rule evaluation. An associated Rule may be available in cases where the behavior of the object can be explicitly modified using a defined rule. In many cases, an OsidObject may define specific methods to manage certain common behavioral aspects and delegate anything above and beyond what has been defined to a rule evaluation.

Rules are Operables. In the case of a statement evaluation, an enabled rule overrides any evaluation to return true and a disabled rule overrides any evaluation to return false. Rules are never required to consume or implement. They serve as a mechanism to offer a level of management not attainable in the immediate service definition. Each Rule implies evaluating a set of facts known to the service to produce a result.

Rule evaluations may also require extra input data in the form of OsidConditions. getConditionRecordTypes() lists the required OsidRecords. These types may or may not be directly managed as part of this rule definition.

An OsidEnabler is an OsidRule used to manage the effectiveness, enabledness, or operation of an OsidObject. The OsidEnabler itself may be active or inactive. When an OsidEnabler is active, any OsidObject to which it is applied is "on." When all OsidEnablers applied to an OsidObject are inactive, then the OsidObject is "off." If isRequirement() is true, then this OsidEnabler must be active regardless of the state of any other OsidEnablers mapped to the OsidObject.

The managed OsidObject may have varying semantics as to what its on/off status means and in particular, which methods are used to indicate the effect of an applied OsidEnabler. These semantics are defined in the types of OsidEnablers.

• Operables: OsidOperators effect the operational status of the Operable.
• Temporals: OsidEffectuators may be used to extend or shorten the effectiveness of a Temporal such as an OsidRelationship.
• OsidRules: OsidRuleApplicators determine if the OsidRule is applicable in an evaluation.

OsidEnablers are both Operables and Temporals. Ineffective OsidEnablers are not operational therefore not active. In other words, isOperational() also depends on isEffective(). OsidEnablers define several built-in dimensions to govern its operational status.

• effective dates: The OsidEnabler is operational during these dates and evaluated using a date.
• schedule: The OsidEnabler is operational when the date is occurs on the Schedule and the date is within the effective dates.
• event: The OsidEnabler is operational when the date occurs within the Event and the date is within the effective dates. Events may be comprised of Schedules and other rules making them discontinuous.
• cyclic event: The OsidEnabler is operational when the date cccurs within the CyclicEvent and the date is within the effective dates. CyclicEvents may be complex recurring events but also recur from one time period to the next, such as annually.
• time period: The OsidEnabler is operational during a TimePeriod.
• cyclic time period: The OsidEnabler is operational during a recurring TimePeriod. For example, any Spring term.

An OsidOperator is an OsidEnabler that governs the operational status of an Operable. The OsidOperator itself may be active or inactive. An Operable is operational when any applied OsidOperator is active. When all applied OsidOperators are inactive, then the Operable is not operational. If isRequirement() is true, then this OsidOperator must be active regardless of the state of any other applied OsidOperators.

Operables are active or inactive. Operables may change their operational status over time, but if two evaluations occur at the same point in time each of the evaluations should see the same operational status. For example, a bridge can be open or closed, but it cannot be open for one car and closed for another car at the same time. OsidOperators are rules which govern the Operable status over time but OsidOperators do not incorporate context that varies from one perspective to the next. OsidOperators define several built-in dimensions to govern its operational status.

• effective dates: The OsidEnabler is operational during these dates and evaluated using a date.
• schedule: The OsidEnabler is operational when the date is occurs on the Schedule and the date is within the effective dates.
• event: The OsidEnabler is operational when the date occurs within the Event and the date is within the effective dates. Events may be comprised of Schedules and other rules making them discontinuous.
• cyclic event: The OsidEnabler is operational when the date cccurs within the CyclicEvent and the date is within the effective dates. CyclicEvents may be complex recurring events but also recur from one time period to the next, such as annually.
• time period: The OsidEnabler is operational during a TimePeriod.
• cyclic time period: The OsidEnabler is operational during a recurring TimePeriod. For example, any Spring term.

An OsidEffectuator is an OsidEnabler used to manage the effectiveness of a Temporal. The OsidEffectuator itself may be active or inactive. When an OsidEffecuator is active, any mapped effective Temporal remains effective. When all OsidEffectuators mapped to an effective Temporal are inactive, then the Temporal becomes ineffective. When an OsidEffecuator is active, any mapped ineffective Temporal either creates a new mapped Temporal or extends the effectiveness of the existing Temporal.

If isRequirement() is true, then this OsidEffectuator must be active regardless of the state of any other OsidEffectuators mapped to the Temporal.

In the case where an OsidEffectuator may cause a discontinuity in a Temporal, the OsidEffectuator may cause the creation of new Temporals to capture the gap in effectiveness. In the case of a new Temporal, the existing OsidEffectuators are applied to it.

For example, An OsidRelationship that began in 2007 may be brought to an end in 2008 due to the absence of any active OsidEffectuators. When an active OsidEffectuator appears in 2009, a new OsidRelationship is created with a starting effective date of 2009. There are now two OsidRelationships, one effective and one ineffective, with the same peers and applied OsidEffectuators.

Temporals are auditable records of changing data and are constant with respect to the context or perspective of an evaluation. For example, if a building has been demolished for one person, another person cannot be a tenant at the same time. OsidEffectuators are rules which govern the closing and creation of Temporals over time, but do not incorporate context that varies from one perspective to the next.

It is up to the consuming process of these OsidEffectuators to manage the Temporals to which they apply. For instance, if multiple OsidEffectuators are in effect with overlapping date ranges, the process should result in a single Temporal that covers the entire period. The process is also responsible for determining the appropriate time resolutions (seconds, hours, days, etc.) for the Temporals as well as maintaining the new OsidEffectuator mappings for new Temporals created. The process may periodically resync with OsidEffectuators to manage Temporals in batch but may also listen for notifications as to any changes to OsidEffectuators.

For auditing uses, resulting new or expired Temporals may not be permitted in the past but might only take place in future time windows. While not necessary for operation, there may be additional auditing concerns that include the retention of OsidEffectuator copies on expired Temporals and journaling the OsidEffectuators for tracking changes to the rules.

An OsidRuleApplicator is an OsidEnabler used to evaluate the applicability of an OsidRule. An OsidRule is applicable when any OsidRuleApplicator is active and the applied data of the OsidEnabler fits within the evaluation context of the OsidRuleApplicatorCondition. Unlike other OsidEnablers, OsidRuleApplicators do not effect the active status of its OsidRules. Applicability is always determined through an evaluation.

If isRequirement() is true, then this OsidRuleApplicator must be active and applicable regardless of the state of any other OsidRuleApplicators mapped to the OsidRule.

OsidRuleApplicators define several built-in dimensions to govern its own operational status. In in active OsidRuleApplicator is never applicable in an OsidRule evaluation.

• effective dates: The OsidEnabler is operational during these dates and evaluated using a date.
• schedule: The OsidEnabler is operational when the date is occurs on the Schedule and the date is within the effective dates.
• event: The OsidEnabler is operational when the date occurs within the Event and the date is within the effective dates. Events may be comprised of Schedules and other rules making them discontinuous.
• cyclic event: The OsidEnabler is operational when the date cccurs within the CyclicEvent and the date is within the effective dates. CyclicEvents may be complex recurring events but also recur from one time period to the next, such as annually.
• time period: The OsidEnabler is operational during a TimePeriod.
• cyclic time period: The OsidEnabler is operational during a recurring TimePeriod. For example, any Spring term.

OsidRuleApplicators define several built-in application conditions to determine if an OsidRule is applicable in an evaluation.

• applied time period: This time period to which this applies. OsidEnablers already include a time period to govern its operational status which is determined by the date range of the time period. However, this time period is used as a reporting time period determined by the context of the evaluation. For example, an OsidRule may be applied during a Spring Term for Fall Term Registration. "During Spring Term" is the operational status and "for Fall Term" is the contextual condition. The dates in applicable time periods typically do not matter.
• applied cyclic time period: A recurring time period to which this applies.
• applied resource: A single resource, group of resources, or demographic of resources to which this applies.

An OsidConstrainer marks an interface as a control point to constrain another object. A constrainer may define specific methods to describe the constrainment or incorporate external logic using a rule.

An OsidProcessor is an interface describing the operation of another object. A processor may define specific methods to manage processing, or incorporate external logic using a rule.

An OsidGovernator is a control point to govern the behavior of a service. OsidGovernators generally indicate the presence of OsidEnablers and other rules to provide a means of managing service operations and constraints from a "behind the scenes" perspective. The OsidGovernator is a focal point for these various rules.

OsidGovernators are Sourceable. An OsidGovernator implies a governance that often corresponds to a provider of a business process. OsidGovernators are Operable . They indicate an active and operational status and related rules may be administratively overridden using this control point. Administratively setting the enabled or disabled flags in the operator overrides any enabling rule mapped to this OsidGovernator.

OsidCompendium is the top level interface for reports based on measurements, calculations, summaries, or views of transactional activity within periods of time. This time dimension of this report may align with managed time periods, specific dates, or both. Oh my.

Reports are often derived dynamically based on an examination of data managed elsewhere in an OSID. Reports may also be directly managed outside where it is desirable to capture summaries without the detail of the implied evaluated data. The behavior of a direct create or update of a report is not specified but is not limited to an override or a cascading update of underlying data.

The start and end date represents the date range used in the evaluation of the transactional data on which this report is based. The start and end date may be the same indicating that the evaluation occurred at a point in time rather than across a date range. The start and end date requested may differ from the start and end date indicated in this report because of the inability to interpolate or extrapolate the date. These dates should be examined to understand what actually occurred and to what dates the information in this report pertains.

These dates differ from the dates the report itself was requested, created, or modified. The dates refer to the context of the evaluation. In a managed report, the dates are simply the dates to which the report information pertains. The history of a single report may be examined in the Journaling OSID.

For example, the Location of a Resource at 12:11pm is reported to be in Longwood and at 12:23pm is reported to be at Chestnut Hill. A request of a ResourceLocation......A data correction may update the Longwood time to be 12:09pm. The update of the ResourceLocation from 12:11pm to 12:09pm may be examined in the Journaling OSID while the 12:11pm time would not longer be visible in current versions of this report.

Reports may be indexed by a managed time period such as a Term or FiscalPeriod. The evaluation dates may map to the opening and closing dates of the time period. Evaluation dates that differ from the time period may indicate that the transactional data is incomplete for that time period or that the report was calculated using a requested date range.

OsidCompendiums are subjugates to other OsidObjects in that what is reported is tied to an instance of a dimension such as a person, account, or an OsidCatalog.