The Dydra service makes several resources available for users with administrative privileges to remotely administer a service by monitoring and manipulating its resources. See the examples for more details:

System Monitoring¶

GET¶

https://dydra.com/system/status

Returns a system status summary as a single solution.

GET¶

https://dydra.com/system/status.<type>&accounts=<account names>

Performs a status check on a random subset of the repositories in the account and returns a solution field with their names.

GET¶

https://dydra.com/system/accounts/<account names>/repositories/<repository-name>/service_description

Returns the repository service description.

GET¶

https://dydra.com/system/accounts/<account names>/repositories/<repository-name>/service_history

Returns a time-series dataset which recounts the performance of queries which targeted the repository.

GET¶

https://dydra.com/system/accounts/<account names>/repositories/<repository-name>/service_statistics

Returns a statistics which summarizes the performance of queries which targeted the repository.

Account Management¶

POST¶

A POST to this abstract account resource creates an account:

https://dydra.com/system/accounts

Content-Type: application/json

Content¶

{"account": {"name": "<new account name>"} }


DELETE¶

A DELETE to the specific resource deletes the respective account

https://dydra.com/system/accounts/<account>

GET¶

Information about an account is available through several resources

Returns a solution set with the names of the accounts to which the current user has access.

https://dydra.com/system/accounts

https://dydra.com/system/accounts/<account>

Content-Type: application/json

Response¶

{"@type": "account",
"name": account name,
"location": account host-specific HTTP API URL,
"identifier": account service metadata resource identifier
"repositories": an array of account repository metadata
}


Repository Management¶

POST¶

In order to create a repository post to the accounts abstract repository resource:

https://dydra.com/system/accounts/<account>/repositories

Content-Type: application/json

Content¶

{"repository": {"name": "<new repository name>"},
"class": "<repository class>"
}


The options class specifies the repository’s schematic storage model and access patterns.

class

schematic model

internal-view-repository

The repository materializes the results of a view applied to a base repository

internal-text-repository | The repository materializes a free text index for
the string terms in the base repository
internal-text-view-repository | The repository materializes the results of a view
applied to a base repository using free text
indices

hdt-repository

The repository uses the HDT storage model

lmdb-repository

The repository uses a 6x B-tree storage model to index all quad term combinations

revisioned-lmdb-repository

The repository extends the lmdb-repository storage to incorporate a linear index for revision information

DELETE¶

In order to delete a repository, delete the specific resource:

https://dydra.com/system/accounts/<account>/repositories/<repository>

GET¶

https://dydra.com/system/accounts/<account>/repositories/<repository>

Content-Type: application/json

Response¶

Returns a data model which describes the relationships apparent in the repository data and its defined interface views.

{"@type": "repository",
"name": repository name,
"location": repository host-specific HTTP API URL,
"identifier": repository service metadata resource identifier
"getViews": an array of metadata models for defined SELECT views
"updateViews": an array of metadata models for defined MODIFY
"postViews": an array of metadata models for defined TARQL views
"patterns": an array of predicate patterns derived from a formal concept analysis of the repository
"description": the repository description text
"predicates": an array of the predicates present in the repository
"paths": an array of the object/subject predicate pairs present in the repository
}


The service computes the model on demand and caches it for the duration of a processor cycle.

https://dydra.com/system/status/<account>/repositories/<repository>

Content-Type: application/json

Revision Management¶

GET¶

https://dydra.com/system/accounts/<account names>/repositories/<repository-name>/revisions

Content-Type: text/plain

Response¶

Returns a list of the repository revisions.

DELETE all revisions¶

In order to delete all revisions, that is, to clear a repository:

https://dydra.com/system/accounts/<account>/repositories/<repository>/revisions

Content-Type: text/turtle

or

Response¶

Returns a graph describing the task solution field.

DELETE history¶

To not delete all revisions, but instead preserve the revisions starting at a boundary revision and trim the history to that boundary, one can specify this boundary revision with a HTTP parameter revision-id and specify a mode for the delete operation. This affects all revisions before the boundary.

The boundary is to be specified as a Revision Designator Specification, usually a revision UUID, its ordinal, a timestamp, HEAD, or TAIL. If left out, the most recent revision is used, that is, the equivalent to HEAD.

One can either set the mode to delete-history:

https://dydra.com/system/accounts/<account>/repositories/<repository>/revisions?mode=delete-history&revision-id=<revision-designator>

This remove all revisions prior to the boundary with all their data, and results in a state that is equivalent to a new, empty repository into which all remaining revisions have been inserted.

Alternatively, one can specify the mode as project-history:

https://dydra.com/system/accounts/<account>/repositories/<repository>/revisions?mode=project-history&revision-id=<revision-designator>

This also removes all revisions prior to the boundary but instead of just deleting them, it projects their state to the boundary, and thus causes the boundary revision to reflect all data through to that point.

In other words, the mode delete-history will cause the specified boundary to be equivalent to a new, empty repository. While the mode project-history will cause the boundary to have all the content that the repository’s revision had prior to this operation but without its history. All data appears to have been inserted at that revision.

If the mode is not sepecified, it defaults to all, which will clear the repository by deleting all revisions, see section DELETE all revisions.

Content-Type: text/plain

Response¶

Returns a list of the repository revisions that have been deleted, that is, all revisions prior to the specified revision-id.

View Management¶

GET¶

https://dydra.com/system/accounts/<account names>/repositories/<repository-name>/views

Returns a json document which records the metadata about the repository views.

POST¶

In order to create a view, post to the abstract account resource:

https://dydra.com/system/accounts

Content-Type: application/json

Content¶

{"account": {"name": "<new account name>"} }


DELETE¶

In order to delete an view, delete the specific resource:

https://dydra.com/system/accounts/<account>/repositories/<repository>/views/<view>

GET¶

Retrieve metadata concerning a given view:

https://dydra.com/system/accounts/<account>/repositories/<repository>/views/<view>

Content-Type: application/json

Response¶

{"@type": "view",
"name": view name,
"location": view host-specific HTTP API URL,
"identifier": view service metadata resource identifier
"constructPatterns": an array of construct query predicate patterns,
"modifyPatterns": an array of update query insertion patterns,
"wherePatterns": an array of select query insertion patterns,
"predicates": an array of predicate present in the view,
"references": {"services": an array of any device locations present in the view,
"views": an array of any view locations present in the view
},
"description": view description text
}