Skip to content

Extensions

Jump to bottom
Jeremy Tandy edited this page May 23, 2013 · 12 revisions

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

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 with 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;
    reg:annotationGraph </register/_item?annotation=graphname> .

Typed templates

By default when a registered item is viewed the default tab shows the RDF properties of the entity as a table of property/value pairs. Other tabs show the item metadata and the history of changes to the item.

To support customizable views of particular entity types, such as VoID data sets (see below) an experimental system of typed templates is provided.

A new system register /system/typed-templates holds the list of registered templates. Each registered template provides a description of a single template comprising an RDF type which can trigger it, the name of a Velocity template which will perform the rendering and a priority. For example:

@prefix ui:   <http://purl.org/linked-data/registry-ui#> .

<concept-scheme> a ui:Template;
    rdfs:label "concept scheme template";
    ui:template "concept-scheme-render.vm";
    ui:templatePriority 50;
    ui:type skos:ConceptScheme;
    .

Items often have several different types, which may mean that multiple typed templates can match. The matching template with the highest priority number will be used.

The template itself cannot be dynamically uploaded the registry remotely, for security and stability reasons. A registry instance can configure the file system area in which templates are stored and can provide separate facilities for dynamically adding template files to this area if such facility is desired.

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 developed.
  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 on the graph visualization 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.

Screen shot of explorer

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.

Messaging and notification

The conceptual design of the UKGovLD Registry includes the idea that a change of state to the contents of the registry may trigger some external agent to analyse the registry contents in the context of the change (e.g. identifying new linksets when a dataset is registered and adding the appropriate annotations, or maintaining SKOS broader or narrower relationships between Concepts etc.). Alternatively, changes may be captured and replayed in read-only mirror copies of the register within a distributed deployment.

To meet this requirement, an internal messaging service has been implemented.

Any command which involves a change of state (Register, Update, StatusUpdate, Annotate) notifies the message service. It passes the details of the command (the target URI, operation done, including for the registration command the RDF payload). These are packaged up into a Message object, a copy of which is broadcast to all registered listeners.

The messaging service is currently an internal layer so a message and listener are both java classes and only code in the same VM (indeed same classloader) that can be a listener. Future plans are to plug in a relay service which can then relay a serialized version of the command message to an external publish/subscribe messaging service. Message protocols such as STOMP (which are defined "on the wire" and has a very broad range of clients) appear to be good options, although Atom type feeds are also under consideration.

Clone this wiki locally