Design
OpenSABER is a collection of interfaces, default implementations and configuration tools to enable any knowledge silo to publish data to the external world and allow trusted agents to issue information into it, via secure standards, privacy protected by a consent driven architecture and expressed via a explicit but extensible vocabulary.
Entity is the most granular data that OpenSABER exposes via its APIs. Each entity is backed by a schema.
A schema is a well-defined structured representation of an entity. The schema can be open or closed. A closed schema means the entity can only have the attributes that are defined. An open schema allows any random attribute to be added anytime. A schema is also referred to as definition in our documentation.
Vocabulary is a body of schema called out in an OpenSABER instance. Each instance can have its own vocabulary. Vocabulary is used by other instances or external applications to interact with the registry.
In simple language, the registry is a data store of some well-known entities. The registry need not house ALL data in itself. The registry could be referencing other registries or data warehouses. OpenSABER is a technical realization of the registry.
- OpenSABER modules should be loosely coupled via published interfaces, allowing the open source community to provide implementations and deployers to have control over the choice of middlewares and implementations as necessary. For instance, OpenSABER need not force technology or vendor lock-ins, where possible. More on middleware design can be found here.
- Trust being a core concern, OpenSABER should design for certifying digitally signed verifiable data.
- Consent driven architecture to satisfy pre or post, single or multiple participants to converge on consensus before data reads or writes. Data protection could be globally defined at the registry or the access patterns could also be modified at a record's attribute or property level.
OpenSABER expresses data in a simple JSON format. A new OPENSABER adopter defines the data schema and can optionally provide a context to this data. Providing a context would mean the JSON-LD interface would be visible and functional. We aspire to provide LD interfaces with rich utility toolsets and minimal adopter learning curve.
The Application layer is freely extendible to use its validation mechanism.
Storage is abstracted out, so that the graph data structure, could be saved in any DB Provider satisfying the storage interface.
A Pipeline design pattern is envisioned to power the various Middlewares which could be plugged in. The Middleware could be chained before application, where we need to address concerns around access, data validations, etc or these could be chained downstream to cater to data privacy, serialization, transport optimizations, etc.
Blueprints is a collection of interfaces, implementations, ouplementations, and test suites for the property graph data model. Providers lists out graph systems which are TinkerPop-enabled. There is also a SQLG project which is an implementation of TinkerPop3 on a RDBMS. The Blueprints API is now merged under Gremlin Structure API.
Gremlin Structure API
Gremlin Traversal API
The data model is left to the adopter's choice to make it a open world definition or a closed world definition. A closed world definition would mean that all records look exactly alike, whereas an open world cannot necessarily guarantee such a consistency.
OpenSABER uses json-schema as a way to specify the definition. Refer to json-schema.org for more details. Remote schema is a natural extension, but this library has not extended to that as of now.
Create some quick definitions for your trials using this online utility - json-schema.net.
The following sample schema have been provided in the repository for adopters to try out. Each of the schema is given as a sample and is by no means exhaustive.
- Teacher
- Person
- Vehicle
You would find that the Teacher schema is split into multiple files, whereas Person and Vehicle are more or less self-contained.
Each of this schema can evolve over time and the idea for OpenSABER is to embrace this change seamlessly.