v1.5 Release Notes

This is an incremental software release that adds several improvements across the board. Nexus Delta architecture has changed substantially, becoming more modular thanks to the introduction of plugins. However, the API remains backwards compatible to v1.4 (except for very specific endpoints documented below).

For the detailed list of updates in this release, see the list of addressed issues since v1.4.

If you are currently using Nexus Delta from 1.4.x, please visit the migration instructions for the necessary steps to successfully upgrade.

Nexus Delta

The main goal of this release is to allow parts of the service to evolve quickly while keeping a stable core functionality. The solution we have come up with makes use of plugins to achieve the desired degree of modularity.

A secondary goal of this release is to improve JSON-LD support, fully aligning our service with the JSON-LD specification.

Lastly, we have stabilized and aligned our API while addressing some bug fixes.

Please visit the migration instructions for the exact steps necessary to upgrade from the previous release.

Plugins

After working on Nexus Delta for 4 years we have learned that there are different parts of the API evolving at different pace with different degrees of stability. At the same time, we acknowledge the diversity of requirements for the various teams using Nexus Delta.

Giving some thought about how to improve these two aspects, we have realized that a plugin architecture, for part of our API, could be the solution.

Plugins support painless extensibility and evolution of different features of the Nexus Delta API while keeping isolation and stability to the rest of the feature set.

In order to adopt and validate this new design, we have identified a set features that have been implemented as plugins:

If you’re interested into building your own plugin, please visit the plugins section.

JSON-LD

Note

Please read carefully this section. Some changes introduced might have breaking consequences on clients consuming the Nexus Delta API if, and only if, your client does not already use a JSON-LD aware library

JSON-LD has been our primary representation format since the beginnings of Nexus Delta. It is a powerful format that allows clients to use simple JSON while it adds support for Linked Data, opening the door to work with knowledge graphs.

Our previous JSON-LD support was, in some cases, inconsistent with the specification. We have fixed that, introducing the following changes:

  • An @base defined on a remote context (a context that is specified as a link) does not have any effect on the resource payload.
  • When an @base is not present in the @context section of the payload, the base field defined on resources’ project is used.
  • When having an array of remote contexts, resolution is performed sequentially, overriding definitions when necessary.
  • A default @context gets added to the payload only when the client didn’t provide it and the payload doesn’t contain any JSON-LD aware content (the payload is not able to produce some triples).
  • When fetching a resource using the query parameter ?format=expanded, a fully expanded JSON-LD document is returned, instead of the hybrid JSON-LD response used in the previous versions.

In terms of new features related to JSON-LD, we are happy to announce that we now support:

  • The use of @graph in order to produce named graphs.
  • The response format N-QUADS using the HTTP Accept header application/n-quads.

Sparql

We have added support for multiple Content Negotiation types when querying the SPARQL view, allowing clients to request different response formats. The Content Negotiation is controlled by the HTTP Accept header. The following values are supported:

  • application/ld+json: Returns an expanded JSON-LD document. This is supported for a subset of SPARQL queries.
  • application/n-triples: Returns the n-triples representation. This is supported for a subset of SPARQL queries
  • application/rdf+xml: Returns an XML document.
  • application/sparql-results+xml: Returns the sparql results in XML.
  • application/sparql-results+json: Returns the sparql results in Json (default).

Views

  • ElasticSearchView/SparqlView/CompositeView have a new field permission that allows clients to customize the permission needed in order to perform queries.
  • ElasticSearchView has a new field settings, allowing clients to specify the Elasticsearch index settings.
  • ElasticSearchViews no longer expand the value of @type field if sourceAsText is set to false. The value used will be the one provided by the client.
  • ElasticSearchViews no longer inject and expand the value of @id field if sourceAsText is set to false. If @id is missing in the payload provided by the client, it will not be present in the Elasticsearch document _source. The identifier of the resource can be retrieved from Elasticsearch _id field .
  • AggregateElasticSearchView can point to a viewId which is another AggregateElasticSearchView.
  • AggregateSparqlView can point to a viewId which is another AggregateSparqlView.
  • CompositeView statistics endpoints return a list of projection statistics. This is a breaking change introduced to align the API with other statistics endpoints.
  • Project information is indexed into Blazegraph and Elasticsearch

Resolvers

  • CrossProject has a new field useCurrentCaller that supports performing resource resolution with the caller identities, instead a fix set of identities provided in the identities field of the resolver.
  • Prevent from having multiple resolvers with the same priority, enforcing deterministic resolution of resources.
  • When debugging resolver resolution, clients can use the query parameter ?showReport=true in order to get full insight about which project was used up to resolve a resource.

SSEs

  • Introduced own SSEs endpoints for schemas, resolvers, storages, files and views.
  • All SSEs are now guarded by the permission events/read.
  • The top @type field on SSEs have changed to convey more precise information.
  • SSEs response from API endpoint v1/resources/{org}/{project}/events contains project events as well as other resource types events.

Miscellaneous

  • Resolution of remote context and owl:imports for resources/schemas is done at creation and update time. This means that further changes to the remote context or owl:imports link won’t affect the already existing resources. This fixes a bug which caused inconsistencies on our data.
  • When an organization is deprecated no changes can be introduced to the project or resources belonging to that organization.
  • Listings response from API endpoint v1/resources/{org}/{project} contains project resources as well as other resource types resources.

Nexus Fusion

In this minor release, we have added two new sub-applications to fusion. We have also updated the Admin app to match the v1.5.0 release of Nexus Delta.

Search sub-app (Beta)

  • Choose an Elasticsearch index to search on.
  • Configure facets and attributes.

Workflow sub-app (Alpha)

  • Create workflows.
  • Create steps and sub-steps to describe the workflows.
  • In each step, link activities and add inputs.
  • Visualize data by adding data tables, activity tables, or input tables.

Data Cart

  • Save resources locally in your data cart, either from the resource view or from a data table.
  • Download and copy IDs from the cart resources in bulk.

Studio sub-app

  • Support for Elasticsearch queries in Studios.
  • Brand your deployment of Nexus Fusion for your needs.
  • Configure sub-apps visibility for anonymous users.
  • More under the hood improvements.

Nexus Forge

See Nexus Forge documentation for release notes.