OsidObject is the top level interface for all OSID Objects. An OSID Object is an object identified by an OSID Id and may implements optional interfaces. OSID Objects 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 object to a more user friendly display of various attributes.

Creation of OSID Objects and the modification of their data is managed through the associated OsidSession which removes the dependency of updating data elements upon object retrieval. The OsidManager should be used to test if updates are available and determine what PropertyTypes are supported. The OsidManager is also used to create the appropriate OsidSession for object 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 record Types, OSID Objects 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 OSID object may have a record Type of Publication that defines methods pertinent to publications, such as an ISBN number. A 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 record Types, the genus Types may also exist in an implicit type hierarchy. An OSID object always has at least one genus. Genus types should not be confused with subject tagging, which is managed externally to the object. Unlike record Types, an object's genus may be modified. However, once an object's record is created with a record Type, it cannot be changed.

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