See: Description
Interface | Description |
---|---|
Type |
The Type is a form of identifier that is primarily used to identify
interface specifications.
|
TypeAdminSession |
This session is used to create, update and delete
Types
in the registry. |
TypeForm |
This form provides a means of updating various fields in the
Type. |
TypeList |
Like all
OsidLists, TypeList provides a
means for accessing Type elements sequentially either one
at a time or many at a time. |
TypeLookupSession |
This session retrieves Types.
|
TypeManager |
This manager provides access to the available sessions of the type
service.
|
TypeProfile |
The
TypeProfile describes the interoperability among
type services. |
TypeProxyManager |
This manager provides access to the available sessions of the type
service.
|
The Open Service Interface Definitions for the org.osid.type service.
The Type OSID defines a set of interfaces for managing Type
definitions. Types
are used as an identifier
primarily for identification of interface extensions throughout the OSIDs
and occasionally used as an extensible enumeration. An agreement between an
OSID Consumer and an OSID Provider means they support the same Type.
A Type
is similar to an Id but includes other data for
display and organization. The identification portion of the Type is
globally unique and contains:
Type type = lookupSession.getType("asset", "uri", "http://harvestroad.com/osidTypes/image", "harvestroad.com"); print type.getDisplayName();
The sessions in this OSID offer the capabilities of a Type
registry to centrally manage definitions and localized display
strings and descriptions. Applications may opt to construct their own
Types
directly and bypass this service.
Types are part of an internal hierarchy. A Type
in a
hierarchy includes the Types
of its children. For example,
an Asset
may have a "photograph" Type
included as part of an "image" base Type.
Unless an application will display a type, it can simply construct a type based on the identification components. OSID Providers may benefit by using this service to manage the type hierarchy, to provide a place to perform mappings across different type definitions, and to provide displayable metadata to its consumers.
Types
may relate to other Types
to
describe constraints or compositions. The relationship is expressed as
another Type. For example, a Position
of type "researcher"
may be appropriately associated with an Organization
of type
"laboratory" using a relation Type of "allowed." Or, a root Event
type depends on a root TimePeriod
type using a
relationship type of "depends on."
An OSID Provider may link a Type,
such as a genus, to a
set of constraints that are made known to the application as
Metadata
through an OsidForm.
Types of an
OsidObject
may also be used by an OSID Provider to constrain the
possible relationship Types
that may be possible to that
OsidObject.
In these uses of Types,
there is
a semantic accompanying the Type
definition managed within
an OSID Provider. The Type OSID manages the metadata of the Type
itself. Logic implementing the meaning of the Type
is managed completely within an OSID Provider.
OSIDs emphasize relationships over data typing since type agreements
are often an impediment to interoperability. Generally, the rule of thumb
for record Types
is to first explore other
OsidObjects,
even those in other OSIDs for a place for extra data.
Often, what is hiding behind a list of data elements is a separate service
that can be provided as a separate module and serves to keep the principal
OsidObject
lighter and more flexible.
Genus Types
primarily serve as a quick and dirty way to
unclutter the record Types
with "is kind of like" tags.
OsidCatalogs
can be used for a richer solution. For example,
a genus Type
may be used to identify all Events
on a Calendar
which are classes at a school and is
accompanied by constraint logic such that the Events
occur
at a Location
on campus.
Another pathway to explore is to create a smart Calendar
from an EventQuery
that specifies constrraints on the
Event
sponsor, Location,
or other data required for
classes. Creates and updates for Events in that smart Calendar
will be similarly constrained and surfaced to the OSID Consumer
through the Metadata
in the EventForms. While this path is
certainly more difficult than simply nailing up some logic indexed by a
genus Type, it can be considered if there is a need to expose the logic and
authoring capabilities.
Most OSID interfaces are used to encapsulate implementation-specific
objects from provider to consumer. Type
is an
OsidPrimitive
and as such cannot be used to encapsulate
implementation-specific data other than what is defined explicitly in the
Type.
An OSID Provider must respect any Type
constructed by an OSID Consumer.
Copyright © 2006-2008 Massachusetts Institute of Technology. All Rights Reserved.
This Work is being provided by the copyright holder(s) subject to the following license. By obtaining, using and/or copying this Work, you agree that you have read, understand, and will comply with the following terms and conditions.
Permission to use, copy and distribute unmodified versions of this Work, for any purpose, without fee or royalty is hereby granted, provided that you include the above copyright notices and the terms of this license on ALL copies of the Work or portions thereof.
You may modify or create Derivatives of this Work only for your internal purposes. You shall not distribute or transfer any such Derivative of this Work to any location or to any third party. For the purposes of this license, "Derivative" shall mean any derivative of the Work as defined in the United States Copyright Act of 1976, such as a translation or modification.
This Work and the information contained herein is provided on an "AS IS" basis WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE WORK OR THE USE OR OTHER DEALINGS IN THE WORK.
The export of software employing encryption technology may require a specific license from the United States Government. It is the responsibility of any person or organization contemplating export to obtain such a license before exporting this Work.