Wizbit Store

The Wizbit Store is a place which contains a series of Wiz.Bits, a Wiz.Bit can represent a file or a Subject in RDF terms. The Wizbit Store (Wiz.Store) provides an API for accessing Wiz.Bits.

A Wiz.Bit

A Wiz.Bit has a blob store and a commit store. The blob store, stores the actual data associated with this bit. Within the blob store there are named  streams for storing data and/or metadata. For storing most ordinary bits a data stream, a subject metadata stream and an object metadata stream would be used, each streams history is tracked in the commit store.

The commit store is a database which stores the pointers to the blobs for each specific revision of the bit which has been committed.

Commit Store

The Wiz.CommitStore stores the individual commits and the relationships between those commits, the relationships concern the ancestory of commits, providing a method of determining the parents or children of an individual commit. The commit store is best demonstrated by the Wiz.Timeline visualisation. A screen capture of which is shown here, in this diagram normal nodes are shown in red, tips are shown in yellow.

There are 3 special kinds of nodes in a commit store these are a tip, a primary tip and a root, and 1 general commit node. Each of these can be addressed directly from the commit store. Via a commit checksum or a tip name. 

Named tips have an internal name that is simply a UUID. Human-readable information will be associated with the internal name by RDF statments.

Examples

Any Specific Node: wizbit://BIT_UUID/COMMIT_CHECKSUM
Primary Tip: wizbit://BIT_UUID
A Named Tip: wizbit://BIT_UUID/TIP_NAME

The commit store also has a simple set of key value pairs associating blobs with stream names, or commit metadata to a bit.

Blob Store

The Wiz.BlobStore is a space on the file system which contains all of the data and metadata streams. These streams are addressed by the commit store by means of a checksum (currently SHA1, but will probably end up as a SHA512). The blob store provides access to blobs which can then be read from and written to.

When a blob is opened for reading and writing a new temporary file is created. When a commit occurs that file is placed in position as the child of the blob which was opened. The commit store is updated accordingly.

Wiz.Bits and Metadata

Each of the data and metadata streams is a blob. A blob can be opened at any specific point in it's commit history, or the latest can be opened. The metadata is stored as a series of tuples in N3 format. Each time a commit occurs the N3 format is extracted from trackers RDF store.

The basic idea behind RDF is that metadata is stored as a series of tuples, in the form of (Subject, Predicate, Object) Predicates are ways of describing the relationship between the Subject and the Object.

Examples

("A Bit UUID", has tag, "Tag Name")
("Tag Name", has bit, "A Bit UUID")
("Folder", has bit, "A Bit UUID")


Both tuples where the Bit UUID is the Subject, and where the Bit UUID is the Object will be stored in the Subject and Object streams respectively.

Synchronisation

Synchronisation is achieved by using a breadth first search over the commit store on both sides of the partnership. A three way merge is performed for types of data which are capable of it, when this cannot be achieved, or conflicts occur the result is new tips are created to accommodate the unmergable differences. Also when bits & tips are purposely created on one side of the partnership they are merged into the Wizbit Store as they stand.