↓ Skip to main content
SST - Semantic STEP Technology
SST - Semantic STEP Technology

SST-Core API

SST-Core is an API (software library) for the Golang programming language. It enables the development of high performance Semantic Web applications with a specific extensions based on the SST-Principles to enable the capabilities of the SST-Ontologies. Many of the SST-Core methods and functions are available in the Command Line Interface tool SST-CLI.

Main SST Application Objects

All functions and methods of SST-Core can be divided into two groups:

  • the ones that operates on the persistent data storage in a Repository (left side of the diagram) and
  • the ones that operates on data in memory within a Stage (right side of the diagram).

Repository
#

A Repository is either a remote repository somewhere on the Internet or one in a local file system accessible to the SST application. For server / cloud applications only remote repositories are used. A remote Repository is identified by a URL, while a local one is defined by a directory path. All access to a remote Repository requires a GO-Context parameter that encodes the identity and access rights of the user. An SST Repository is a persistent storage consisting of 3 main component:

  • BBolt which is an embedded, serialisable, transactional key/value database, able to manage huge amounts of data. BBolt is used to store the master data, consisting of RDF Datasets and NamedGraphs with full GIT like revision control capabilities including Commits, Logs, Branches / Revisions. In addition it also contains Document meta information

  • Bleve that is an embedded search engine that uses Lucene-style full-text search and indexing capabilities. The Bleve index contains derived data from the master data. The purpose of splitting into master data and derived data is to achieve high loading/saving speed of master data in combination with customisable query capabilities to be able to serve very many Datasets / NamedGraphs.

  • Document Vault is used to store any kinds of non-RDF Documents (e.g. images or PDF files) that an application might need in combination with RDF data.

Dataset: A Dataset represents a persistently stored default NamedGraph together with other directly or indirectly imported NamedGraphs, using owl:imports within a Repository. A Dataset and the corresponding default NamedGraph share the same base IRI. Note that these IRIs contain NO fragment. A particular Dataset is located within a Repository by the Repository method Dataset(dataset-IRI). A Repository might contain many Revisions or Named-Branches of a Dataset. They are accessible by the Dataset methods CheckoutBranch, CheckoutRevision or CheckoutCommit.

NamedGraph-Revision: All NamedGraph-Revisions are encoded within the Repository using the SST file format. From the resulting BLOB (Binary Large Object) the HASH256 value is calculated and used as NamedGraph-Revision index and the BLOB itself as value for an index-value pair in the BBolt database. In a similar way a Dataset-Revision is calculated from the default.NamedGraph and the HASH values of the Datasets of the corresponding NamedGraph that are directly imported

Dataset-Revision: This is identified by another HASH256 value that is calculated from the HASH value of the corresponding default NamedGraph-Revision and the HASH values of all other directly and indirectly imported NamedGraphs. By this all directly and indirectly imported NamedGraphs are under full revision control of the Dataset. Other NamedGraphs that are referenced but not imported are not under revision control.

Commit: A Stage that is linked to a Repository and that contains either new or modified NamedGraph can be committed to the linked Repository; resulting into a new Commit entry and new Dataset-Revisions and in most cases new NamedGraph-Revisions. In addition a Commit contains a comment that should describe the kind of changes, the person who performed the commit and a timestamp. All this together results into a Commit-HASH256 that identifies the Commit.

Branch: A named Revision of a Dataset. Note that each Dataset can have it’s own Branch names. Branch names are not automatically harmonised between the Datasets of a Repository.

Stage
#

A Stage is an in memory representation of one or several NamedGraph and their interlinked Triples. A Stage might or might not be linked to a Repository into which changes might be committed. A Stage is create by either Checkout a Dataset-Revision from a Repository, creating a new empty one, or importing a Turtle, Trig, SST or other kind of file. A Stage can contain main NamedGraphs, but each one in a single revision only. The content of a Stage can be moved and merged into another Stage. A Stage can be aligned with another Stage that is linked with a repository and that contains NamedGraph revisions that require update.

NamedGraph: This is an in-memory representation of an RDF NamedGraph that is either in Local or in Referenced state: A Local NamedGraph contains all the IBNodes that are “owned” by this NamedGraph and all their Subject Triplexes. A Local NamedGraph might directly import other Local NamedGraphs. On the other hand a Reference NamedGraph contains only those IBNodes that are referenced by other Local NamedGraph and contains no Subject Triplexes.

IBNode: This is either an IRI-node or a blank-node. For SST an IBNode is owned by exactly one NamedGraph; the NamedGraph that has the same base-IRI as it’s IBNodes. The IBNodes in a NamedGraph must all have different Fragments. There is one special IBNode in each NamedGraph that has an empty/no fragment and that represents the containing NamedGraph as a whole. This special IBNode is always of type owl:Ontology.

Collections: The term Collection is defined/used in Turtle and is a more compact way to represent rdf:Lists. Formally rdf:Lists are treated as blank nodes, but for optimisation reasons SST has defined special object types for these:

  • LiteralCollection: They contain only literals that are all of the same Datatype.
  • TermCollection: These are for all other collections, including those with IBNodes, and nested Collections

Triple: or RDF Statement consisting of a Subject, a Predicate and an Object. The Triples an IBNode is involved in are accessible by the IBNode method ForAll(). It will show up Triples in up to 3 different variants that are called Subject Triplex, Predicate Triplex and Object_Triplex, depending on whether this IBNode is used as subject, predicate or object.

Triplex: This defines the direction in which triples can be analysed by an application:

  • a Subject Triplex starts from a Subject IBNode and leads to a Predicate and Object Node/Literal; this is always available
  • a Predicate Triplex starts from a Predicate IBNode and leads to a Subject and Object Node/Literal; this is optional
  • an Object Triplex starts from an Object IBNode and leads to a Subject and Predicate Node; this is optional

A Stage has a Mode parameter that controls which Triplexes are supported within this Stage.