Extensions

These notes cover additional features that are not yet part of the API specification. They are, or are planned to be, implemented in the proof-of-concept system and may be added to the main API in the future.

Contents

• Graph registration
• Graph annotation
• Dataset Registration

Graph registration

In the normal API a managed entity is a resource with associated properties (a closed bounded description). There are circumstances where we would like to be able to store a complete graph that describes multiple resources without have to create tracked item registrations for each of the contained resources. For example, we would sometimes like to be register a complete Ontology (using #-URI patterns) with the Ontology itself corresponding to the managed entity.

We support this through the ?graph flag which enables us to register a complete graph as a payload. To cater for the lack of unique root a graph must be registered through a PUT directly to the entity uri.

Action	URI	Payload	Response
PUT	/register/entity?graph	RDF graph containing some assertions about /register/entity	201 if the graph is successfully created

If the item correspond to the entity URI does not exist then this is treated as a registration and the item is created. If the item does exist then this is treated as an update to the entity, creating a new versioned resource.

Graph annotation

A related but distinct situation occurs when we wish to annotate an item which some complex derived metadata which cannot be treated as simple properties of the item. An example is the results of a deep analysis of a registered dataset.

This is supported though the ability to annotate a registered item with a graph of data.

Action	URI	Payload	Response
PUT	/register/_item?annotation=graphname	RDF graph to store as an annotation	201 if the graph is successfully created
GET	/register/_item?annotation=graphname		The stored annotation graph

The annotation request stores the RDF payload as in a graph whose name matches that of the URI in the PUT/GET requests. The register item itself is also updated to record the existence of the annotation graph:

</register/_item> a reg:RegisterItem;
    eg:annotationGraph </register/_item?annotation=graphname> .

Dataset registration

The VoID description of an (external) dataset can be registered just like any other reference entity.

The registry provides additional experimental support for browsing of datasets.

1. A top level data set search page provides faceted browsing of all registered void:Dataset instances, breaking entries down by type (reg:itemClass) and category (reg:category). In principle additional filtering by spatial coverage or other metadata could be included.
2. When viewing a void:Dataset a special default view is provided which highlights the key VoID metadata and shows links to sub sets and incoming/outgoing link sets.
3. From the view of a void:Dataset, or a result on the dataset search page, a graphical browse option is provided. This allows a graph of data set interconnections to be incrementally created from a starting data set. Each data set displayed graph provides buttons to show incoming or outgoing links, to remove the data set from the graph view or to jump back to the normal registry view of the dataset. TODO screenshot

The latter two facilities depend on description of link sets associated with the void description to also be registered. This can be done using the above annotation facility. The data set registration itself should be an entity corresponding to the void:Dataset resource itself. Then a fuller void description including associated resources such as void:Linksets can recorded as an annotation graph of name void. In order to support directionality of link sets (which is not part of void itself) an addition property of void:Linkset is recognized - reg:sourceDataset - which indicates which of the void:target data sets acts as the subject of the linking predicate.