OSF Web Services Layer

The OSF Web Services are the pivotal layer to the stack. The OSF Web Services provide the standard, common interface to access and manage the OSF engines, via standard API calls and endpoints, either from the Drupal layer or from external systems. The OSF Web Services are generally RESTful in design and are based on HTTP and Web protocols and open standards.

OSF Web Services at present comprise 27 individual Web services, all operating within the same framework. Individual API and Web services documentation is available for these:


 * Auth Registrar: Access
 * Auth Registrar: Group
 * Auth Registrar: User
 * Auth Registrar: WS
 * Auth: Lister
 * Ontology Create
 * Ontology Read
 * Ontology Update
 * Ontology Delete
 * Dataset: Create
 * Dataset: Read
 * Dataset: Update
 * Dataset: Delete
 * CRUD: Create
 * CRUD: Read
 * CRUD: Update
 * CRUD: Delete
 * Revision: Diff
 * Revision: Delete
 * Revision: Read
 * Revision: Update
 * Revision: Lister
 * Search
 * SPARQL
 * Scones
 * Converter: commON (import and export)
 * Converter: irJSON (import and export)

All Web services are exposed via APIs and SPARQL endpoints. Each request to an individual Web service returns an HTTP status and optionally a document of resultsets. Each results document can be serialized in many ways, and may be expressed as either RDF or pure XML. An internal representation, structXML, is used for internal communications across all OSF Web Services and with other layers.

The OSF Web Services have a native security service that governs access rights and permissions (which may be swapped out with an external security service; see description of the middleware layer). These rights occur at the level of the dataset, which gives immense flexibility to how data may be accessed, read, modified, created or deleted (or not). Depending on rights and query, results sets may be returned from a given OSF Web Service instance in a rich variety of ways.

Each OSF Web Service has a unique Web address that enables one or a multitude of instances to communicate and share with one another. This simple, but elegant, method enables OSF Web Service instances to participate or not in potentially global or restricted local networks and collaboration environments. Since any OSF instance on the Web has its own respective Web services and access URIs, a broader distributed network with differential user access and permissions can be readily established.

Each OSF Web Service is accessible or not via a three-dimensional design based on:


 * 1) Users (or groups or roles)
 * 2) The individual Web service, and
 * 3) Datasets.

What this means is that a given user may be granted access or not — and various rights or not from reading to the creation or deletion of information — in relation to specific datasets. Stated another way, it is in the nexus of user type and dataset that access control is established for the OSF semantic system.

In an enterprise context, a given individual (“user”) may have different access rights depending on circumstance. A worker in a department may be able to see and do different things for departmental information than for enterprise information. A manager may be able to view partner information that is not readable by support personnel. A visitor to a different Web site or portal may see different information than visitors to other Web sites. Supervisors or content editors might be able to enter or modify content that is only viewable by others.

Besides management, a key function of the layer is to get external information assets into the system. These external assets may exist in many formats and may be described by many schema. They may come from internal transaction systems or warehouses, or may exist external on the Web or at supplier or partner sites. These information assets may span from conventional databases and relational data systems to XML interchange standards, Web pages and standard internal text or documents. In short, there is no information asset that is not amenable to be included in this framework.

External assets and their structure may be ingested according to defined protocols and may be structurally tagged using the OSF tagging service. The ontologies and entities of a given OSF instance are the basis for tagging using this service. Depending on the source, the net result of the ingest is to produce interoperable data and information for use at the engines layer.