bluebrain / nexus

Blue Brain Nexus - A knowledge graph for data-driven science

Blue Brain Nexus

Blue Brain Nexus is an ecosystem that allows you to organize and better leverage your data through the use of a Knowledge Graph. In addition to the products listed here, you’ll find a rich ecosystem of libraries and tools.

Products

The Blue Brain Nexus ecosystem encompasses a broad range of capabilities that are brought to you across three complementary products and a suite of utilities.

Nexus Fusion

Enabling Collaborative Data and Knowledge Discovery

Fusion is our extensible web application. It hosts different apps to accommodate various use cases. It comes by default with Studios (where you work with data), Admin (for managing the Nexus instance), and will soon support Workflows to organise your data activities. It runs on top of the Delta web services, and integrates neatly with our Forge python framework.

Read more about Fusion | Source Code

Nexus Forge

Building and Using Knowledge Graphs Made Easy

Nexus Forge is a domain-agnostic, generic and extensible Python framework enabling non-expert users to create and manage knowledge graphs.

Read more about Forge | Source Code

Nexus Delta

Managing the Data and Knowledge Graph Lifecycle

A scalable and secure service to store and leverage all your data, neatly organised in a Knowledge Graph. It offers an API to perform all your data management operations, this way it can easily integrate with your software stack. Its advanced indexing capabilities automatically build views from your metadata.

Read more about Delta

Utilities

The Nexus ecosystem leverages a set of smaller open-source utilities.

Discover the utilities

Quick Start Guide

Do you know what a knowledge graph is? Or want to deepen your understanding? Follow our introduction.

Want to get started with Nexus right away? We provide a tutorial that uses our sandbox environment to let you try the functionalities.

Ready to deploy your own instance of Nexus? Follow our guide.

Roadmap

Curious about our upcoming features? Read our open Roadmap to find out more.

More information

The Blue Brain Nexus documentation offers more information about the software, its architecture, an api reference and the current roadmap.

Please head over to the getting started section for a description of various options on running Nexus and introductory material to Linked Data and the Shapes Constraint Language.

For more details, you can talk with the development team directly on Github Discussions or contact them by email.

Getting involved

Please refer to the CONTRIBUTING page in order to know how to report issues/bugs or how to contribute to the project.

Funding & Acknowledgment

The development of this software was supported by funding to the Blue Brain Project, a research center of the École polytechnique fédérale de Lausanne (EPFL), from the Swiss government's ETH Board of the Swiss Federal Institutes of Technology.

Copyright © 2015-2024 Blue Brain Project/EPFL

nexus's Issues

Add support for full text search on listings

From nexus-kg created by umbreak : BlueBrain/nexus-kg#527

Add support:

GET /v1/resources/{account_label}/{project_label}?q={full_text_search_query}

Add discoverability

Issue by umbreak
Thursday Jul 26, 2018 at 10:05 GMT
Originally opened as https://github.com/BlueBrain/nexus-kg/issues/425

---

Create a documentation template

Consider using rfc-8288 for describing links

https://tools.ietf.org/html/rfc8288

Describe the service communication patterns

Cannot fetch the volatile view and resolver

From nexus-kg created by umbreak : BlueBrain/nexus-kg#529

When attempting to fetch the default resolver https://bbp-nexus.epfl.ch/{env}/v1/resolvers/{org}/{proj}/nxv:InProject it does not work, even though listings on https://bbp-nexus.epfl.ch/{env}/v1/resolvers/{org}/{proj} shows it is there with the @id nxv:InProject.

We are attempting to fetch resources from the primary store, but those resources are not stored there. Related to #489

BBP staging nexus query endpoint after number of queries goes down

Hi,
When trying to execute number of consecutive queries staging gives 500. I tried it several times and it always does it. Let me know if you want me to reproduce it. I would appreciate if somebody looks at this. Thanks.

Cannot retrieve any PatchedCells from BBP's staging deployment of Nexus

Hi,
When I use the following filter filter:='{"value": [{"path": "rdf:type", "value": "nsg:PatchedCell", "op": "eq"}], "op": "and"}' on queries endpoint in staging I get empty result set. I know there should be at least 5 cells there. Could you have a look what is going on there? Thanks.

Github pages contexts and schemas not resolved properly by RDF/JSONLD tools

From nexus-kg created by umbreak : BlueBrain/nexus-kg#502

Playground and Jena won't resolve correctly the contexts and schemas in the way they are being redirected from GitHub pages.
https://bluebrain.github.io/nexus/contexts/resource issues a 301 redirect to
https://bluebrain.github.io/nexus/contexts/resource/

Changing the uris to

• https://bluebrain.github.io/nexus/contexts/resource/
• https://bluebrain.github.io/nexus/contexts/resoure.json

would resolve the issue. But I don't like it. Let's see what else we can do...

External URL resolver

From nexus-kg created by umbreak : BlueBrain/nexus-kg#422

Allow references by tag/revision (for immutability support)

From nexus-kg created by umbreak : BlueBrain/nexus-kg#501

References happen in the following cases:

1. Resource referencing another resource. E.g.: "hasProtocol": {"@id": "other/resource/id"}
2. Schema reference using owl:imports. E.g.: "imports": ["other/schema/id"]
3. Context reference on a resource. E.g.: "@context": "other/context/id"

It would be possible to do it using resource with the query params ?tag={tag} or if ?rev={rev}.
That would work without any problem for the cases 2 and 3. However if we change the value of the @id on the case 1, that does not make sense from the triple store perspective.

We have to find a way to resolve this linking using some special key. For example:

{
   "hasProtocol": {
      "@id":  "other/resource/id",
      "_tagged" : "{tag}"
   }
}

Maybe there is a better way to do it from the data part. Thoughts @MFSY @bogdanromanx ?

Listing resolvers or views returns the whole payload while listing other resources don't

From nexus-kg created by umbreak : BlueBrain/nexus-kg#530

When listing resolvers or views all the entity payload + nexus metadata is shown in the response.
When listing other resources only the @id, @type and the metadata of the resource is shown in the response.

Inconsistency due to the fact that listings happen through the cache for views and resolvers while they happen through elasticsearch for the rest of resources, as explained: #489

Limit the resource payload

From nexus-kg created by umbreak : BlueBrain/nexus-kg#543

There are akka properties which define the maximum size for transmitting messages across nodes on the cluster

• akka.remote.netty.tcp.send-buffer-size
• akka.remote.netty.tcp.receive-buffer-size
• akka.remote.netty.tcp.maximum-frame-size

We should match those values to the maximum payload we allow for resources in the platform, otherwise we won't be able to messages across the cluster nodes which are bigger than that size.

broken links at https://bbp-nexus.epfl.ch/dev/datamodel/

As a new visitor, I have found a number of broken links at https://bbp-nexus.epfl.ch/dev/datamodel/.

One pattern seems to be that content exists at 'staging' where it is missing for 'dev'.
eg.
Not found: http://bbp-nexus.epfl.ch/dev/v0/schemas/bbp/
Found: http://bbp-nexus.epfl.ch/staging/v0/schemas/bbp/

I am trying to understand Nexus - I have no familiarity with neuroscience, but as an independent researcher I believe there is lots of potential here - given that there would be sufficient and clear documentation.

Thanks.

BBP staging gives "503 Service Unavailable"

Hi,
Subj. Could you please have a look. Thanks.

Include credits in the documentation and README files

Cannot install tutorial requirements

Hi,

I'd just started the tutorial basic_operations_nexus_v0.ipynb but due to recent changes in pip I can not run the first cell:

!pip install git+https://github.com/HumanBrainProject/[email protected] pyyaml requests

The workaround would be to update the setup.py to something like that in [email protected]

try: # for pip >= 10
    from pip._internal.req import parse_requirements
except ImportError: # for pip <= 9.0.3
    from pip.req import parse_requirements

Migrate to SBT 1.0

Added includeDeprecated in ElasticView

From nexus-kg created by umbreak : BlueBrain/nexus-kg#541

includeDeprecated: Boolean could be an interesting field to add to the Views.

This will delete a resource from the index whenever the latest version of the resource in the platform is deprecated

Store Nexus Product page under docs/

It makes sense to host here the content of the marketing-oriented Product Page under the docs/ folder on the master branch (as per https://help.github.com/articles/user-organization-and-project-pages/#project-pages-sites ). Any objection to this?

Improve the documentation

• Add the project description
• Describe the components
• Describe the component view
• Intro to RDF (to be handled in #10)
• Port the SHACL Documentation (to be handled in nexus-kg)

Github resolver

From nexus-kg created by umbreak : BlueBrain/nexus-kg#421

PR Dashboard

Put up a PR dashboard to minimize the review time, something along the lines of: https://github.com/joeattardi/github-pr-dashboard

Creating a resource POST with reserved Json-LD key @reverse might fail

From nexus-kg created by umbreak : BlueBrain/nexus-kg#411

When a payload is posted with the special key @resverse on the @context object and without an @id, the graph.primaryNode call might detect a "wrong" primaryNode.

Note that the logic in graph.primaryNode itself is not wrong, because if when designing the the resource one decide to add the @reverse key on a property embedded to the "primary" one, it is effectively saying that the primaryNode becomes that property.

I is an edge case, but we have to find out what to do with it. For schemas posted against the platform without @id, is not an edge case.

This was already discussed in #405

Use ElasticSearch for queries when the filter does not contain a path traversal

From nexus-kg created by umbreak : BlueBrain/nexus-kg#446

We need a conversion from the Filter DSL to the ElasticSearch query DSL

The issue https://github.com/BlueBrain/nexus-kg/issues/234 is related to this task

Describe the typical anatomy of a service in the main docs

Documentation for running Nexus locally

This should include docker-compose file to run locally.

Add incoming and outgoing

From nexus-kg created by umbreak : BlueBrain/nexus-kg#400

We have to find a way to add to the Sparql view incoming and outgoing routes which has a similar functionality to v0 incoming and outgoing. Not sure how this is going to be look like and how it makes sense though...

• /v1/resources/{org}/{project}/{schema}/{id}/incoming
• /v1/resources/{org}/{project}/{schema}/{id}/outgoing

Update Grafana Dashboards

Setup grafana dashboards to describe multiple services with only the relevant information.

Export dashboards to nexus project.

Update documentation to list the minimum configuration for monitoring.

Add an RDF and Semantic Web intro to the docs

Nexus staging gives "The context resolution did not succeed"

Hi,
Using the recent context from neuroshapes master "@context": "https://bbp-nexus.epfl.ch/staging/v0/contexts/neurosciencegraph/core/data/v1.0.2" on queries endpoint gives: {"@context":"https://bbp-nexus.epfl.ch/staging/v0/contexts/nexus/core/error/v0.1.0","code":"IllegalPayload","message":"The context resolution did not succeed"} I would expect that something merged to master as available on staging/prod. Thanks.

Document image versioning scheme

Add an explanation to semver in the release section of the docs

Distributed cache on Sets won't work as expected on concurrent scenarios

From nexus-kg created by umbreak : BlueBrain/nexus-kg#438

DistributedCache Relies on a simple counter. This is dangerous when performing writes from multiple nodes as it won't converge in concurrent modifications.

Improve current implementation using ORSets or custom data type.

Expose nexus artifacts publicly

The artifacts produced during the release process are not available outside the organization. This affects the ability to try out / test / fork / contribute to the project.

Artifacts that are required:

• jars (sbt generated artifacts)
• docker images
• npm packages

v1 API discrepancies

The API endpoint in v1 starts with the same base (like from v1). So the client should expect to have certain commonalities on the format of the responses. However...

resource created response:

Admin

{
    "@context": "https://bbp-nexus.epfl.ch/staging/v0/contexts/nexus/core/resource/v0.4.0",
    "@id": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/projects/bbp/example4",
    "_rev": 1
}

KG

{
    "@context": "https://bluebrain.github.io/nexus/contexts/resource",
    "@id": "nxv:someId",
    "@type": ["nxv:someType"],
    "_constrainedBy": "https://bluebrain.github.io/nexus/schemas/view",
    "_createdAt": "2018-08-23T14:36:40.329Z",
    "_createdBy": "https://bbp-nexus.epfl.ch/v1/realms/bbp-test/users/0745c962-a736-4616-9221-cb0b62c22cf8",
    "_updatedAt": "2018-08-23T18:09:50.473Z",
    "_updatedBy": "https://bbp-nexus.epfl.ch/v1/realms/bbp-test/users/0745c962-a736-4616-9221-cb0b62c22cf8",
    "_rev": 3,
    "_deprecated": false
}

resource fetch response

ADMIN

{
    "@context": "https://bbp-nexus.epfl.ch/staging/v0/contexts/nexus/core/resource/v0.4.0",
    "@id": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/projects/bbp/example",
    "@type": "nxv:Project",
    ...
    "_rev": 2,
    "_deprecated": false
}

KG

{
    "@context": [
        "https://bluebrain.github.io/nexus/contexts/view",
        "https://bluebrain.github.io/nexus/contexts/resource"
    ],
    "@id": "nxv:someId",
    "@type": [ "nxv:someType" ],
    ...
    "_constrainedBy": "https://bluebrain.github.io/nexus/schemas/view",
    "_createdAt": "2018-08-23T14:36:40.329Z",
    "_createdBy": "http://iam.dev.nexus.ocp.bbp.epfl.ch/v1/realms/bbp-test/users/0745c962-a736-4616-9221-cb0b62c22cf8",
    "_updatedAt": "2018-08-23T16:34:47.143Z",
    "_updatedBy": "http://iam.dev.nexus.ocp.bbp.epfl.ch/v1/realms/bbp-test/users/0745c962-a736-4616-9221-cb0b62c22cf8",
    "_rev": 2,
    "_deprecated": false
}

resource list response

ADMIN

{
    "@context": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/contexts/nexus/core/search/v0.1.0",
    "_results": [
        {
            "_id": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/projects/01pkyhg5n5raht2/xo04q2x8q2ml20t",
            "_source": {
                "@id": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/projects/01pkyhg5n5raht2/xo04q2x8q2ml20t"
            }
        },
        {
            "_id": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/projects/07e2ort0jydqqba/rjuq67rh63ynuyl",
            "_source": {
                "@id": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/projects/07e2ort0jydqqba/rjuq67rh63ynuyl"
            }
        }
    ],
    "_total": 2,
    "_links": {
        "_next": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/projects?from=50&size=50",
        "_self": "http://admin.dev.nexus.ocp.bbp.epfl.ch/v1/projects"
    }
}

KG

{
  "@context": [
    "https://bluebrain.github.io/nexus/contexts/search",
    "https://bluebrain.github.io/nexus/contexts/resource"
  ],
  "total": 3,
  "results": [
    {
      "resultId": "http://nexus.com/result1"
    },
    {
      "resultId": "http://nexus.com/result2"
    },
    {
      "resultId": "http://nexus.com/result3"
    }
  ]
}

Even though the API seems mostly consistent in terms of URI, path and query params, from the json payload perspective it isn't at all. We have to make some decision on what to choose. From my side, few notes:

• I'd get rid of links at all and directly add the fields we are interested in as metadata (like _constrainedBy in kg).
• I would replace _self by accessId (is more explicit).

Enable community defined schemas

There is a great value in enabling community defined schemas. Different organizations (let say H and B) sharing the same use cases may want to develop a common set of schemas that don't really belong in one organization domain or the other.

Challenge:

• schema naming and identification
• ...

Default views and resolvers

From nexus-kg created by umbreak : BlueBrain/nexus-kg#489

When a project gets created those resources get added to the cache

• Default ElasticView
• Default SparqlView
• Default InProjectResolver

Right now those are volatile resources, not stored in the primary store. They can be listed because we access the cache to list them instead of the elasticsearch index (as done for any other resource).

The advantage of having them volatile is that those resources are not manageable (they cannot be deprecated, updated, ...).

However, there is an inconsistency here. When listing resources /v1/resources/{org}/{proj} those resources will not appear as response. But when listing resources through /v1/views/{org}/{proj} or /v1/views/{org}/{proj}/nxs:view they will.

What we could do is:

• When a project gets created, create the default resources on the primary store if they do not exist already.
• Prevent any modification of the lifecycle of those resources.
  Thoughts?

Add discoverability

From nexus-kg created by umbreak : BlueBrain/nexus-kg#425

Problem creating Nexus Client

What might be causing an error when running the following code? I am trying to use a token, which is a string of letters and numbers.

client = NexusClient(scheme="https", 
                     host="bbp-nexus.epfl.ch", 
                     prefix="staging/v0", 
                     alternative_namespace="https://bbp-nexus.epfl.ch", 
                     auth_client=token)
organization_name = "ngv"
your_organization = client.organizations.read(organization_name)
print(your_organization.data["@id"])

gives the following error:

---

AttributeError Traceback (most recent call last)
in ()
5 auth_client=token)
6 organization_name = "ngv"
----> 7 your_organization = client.organizations.read(organization_name)
8 print(your_organization.data["@id"])

C:\Users\dakeller\AppData\Local\Continuum\Anaconda3\lib\site-packages\pyxus\resources\repository.py in read(self, name, revision)
188
189 def read(self, name, revision=None):
--> 190 data = self._read(name, revision)
191 return Organization(name, data, self.path) if data is not None else None
192

C:\Users\dakeller\AppData\Local\Continuum\Anaconda3\lib\site-packages\pyxus\resources\repository.py in _read(self, identifier, revision)
78 path = "{}/{}?rev={}".format(self.path, identifier, revision)
79 # try:
---> 80 return self._http_client.get(path)
81 # except HTTPError as e:
82 # if e.response.status_code==401:

C:\Users\dakeller\AppData\Local\Continuum\Anaconda3\lib\site-packages\openid_http_client\http_client.py in get(self, *args, **kwargs)
139 def get(self, *args, **kwargs):
140 # return NexusPayload(response.content)?
--> 141 return self._request('get', *args, **kwargs)
142
143 def post(self, *args, **kwargs):

C:\Users\dakeller\AppData\Local\Continuum\Anaconda3\lib\site-packages\openid_http_client\http_client.py in _request(self, method_name, endpoint_url, data, headers, can_retry)
88 headers = headers or {}
89 if self.auth_client is not None:
---> 90 headers.update(self.auth_client.get_headers())
91 req = Request(method_name, full_url, data=data, headers=headers)
92 prepped_request = self.req_session.prepare_request(req)

AttributeError: 'str' object has no attribute 'get_headers'

Add the possibility to remove deprecation flag from a resource

From nexus-kg created by umbreak : BlueBrain/nexus-kg#519

Right now, once a resource is deprecated is not possible to un-deprecate it.

This feature has been requested several times (even though not formally, because I cannot find any issue where to link it).

• Is it for all resources incl. projects etc.? Yes, can be applied to all resources, even Delta-specific resources.
• Do we need a special ACL for this? If you can deprecate, you can un-deprecate. No additional ACLs.

Create Deployment docs

Describe service deployments, configuration and default data to be ingested into the platform.

Add field sorting to json-ld payloads

Publish nexus artifacts to Sonatype and Docker

Unable to find cell by morphology file name in BBP staging

Hi,
With the following payload on queries endpoint I am not able to find any cells:

{
 "@context": "https://bbp-nexus.epfl.ch/staging/v0/contexts/neurosciencegraph/core/data/v1.0.3", "deprecated": false, "filter": {
        "op": "and",
        "value": [
            {
                "op": "eq",
                "path": "schema:distribution / nxv:originalFileName",
                "value": "jy160711_A_idC.asc"
            }
        ]
    }, "resource": "instances"
}

although I see that ReconstructedPatchedCell in explorer. This is required to link EModel data with experimental morphologies and traces. Thanks.

Jena Model to Graph conversion can fail

When having the following json

{
  "@context": "http://schema.org/",
  "@type": "Person",
  "@id": "http://nexus.example.com/john-doe",
  "name": "John Doe",
  "embed": {
    "@id": "file:///Users/some/path with spaces"
  }
}

And attempting to do

JenaModel(json).map(_.asGraph)

will throw the following exception

Caused by: java.util.NoSuchElementException: Either.right.get on Left

because url"file:///Users/some/path with spaces" fails

Document how acls are enforced in searches

Metadata missing on listing views and resolvers

From nexus-kg created by umbreak : BlueBrain/nexus-kg#528

When listing views and resolvers we are hitting the cache instead of the default elasticView.

The cache has a case class representing those resources but there is not enough information on them to retrieve all the metadata (_createdAt, __createdBy, _updatedAt, updatedBy).

This issue arises from the same fact that we use the cache instead of elasticsearch for listings: #489

Assigning identifiers to resources in Nexus

One of the primary goals of the platform is to enable multiple representations for the same data. Based on previous
experiences the structure and sometimes how we represent information changes over time. Instead of fighting these
changes for backwards compatibility to allow clients to continue to function we'd like to go in the opposite direction
where we recognize that some changes have to be backwards incompatible, but allow the clients to upgrade at their own
pace. We planned to track these changes through semantic versions which is why we have schema,
context and instance resource locations contain their versions.

What this all means is that at any given time a piece of information that is recorded in the system can have multiple
representations discriminated through the resource version. For example:

                      ┌────────┐
                 ┌───▶│ v1.0.0 │
                 │    └────────┘
                 │    ┌────────┐
┌───────────┐    ├───▶│ v1.1.0 │
│           │    │    └────────┘
│information│────┤    ┌────────┐
│           │    ├───▶│ v1.1.2 │
└───────────┘    │    └────────┘
                 │    ┌────────┐
                 └───▶│ v2.0.1 │
                      └────────┘

Extending this principle to describe multiple systems that are part of a federation, we can expect having the same
information represented in two systems at various versions, as in the diagram below:

┌───────────────────────────────────────┐   ┌───────────────────────────────────────┐
│Nexus A                 ┌────────┐     │   │Nexus B                 ┌────────┐     │
│                   ┌───▶│ v1.0.0 │     │   │                   ┌───▶│ v1.0.0 │     │
│                   │    └────────┘     │   │                   │    └────────┘     │
│                   │    ┌────────┐     │   │                   │    ┌────────┐     │
│  ┌───────────┐    ├───▶│ v1.1.0 │     │   │  ┌───────────┐    ├───▶│ v1.1.0 │     │
│  │information│    │    └────────┘     │   │  │information│    │    └────────┘     │
│  │     A     │────┤    ┌────────┐     │   │  │     A     │────┤                   │
│  └───────────┘    ├───▶│ v1.1.2 │     │   │  └───────────┘    │                   │
│                   │    └────────┘     │   │                   │                   │
│                   │    ┌────────┐     │   │                   │    ┌────────┐     │
│                   └───▶│ v2.0.1 │     │   │                   ├───▶│ v2.0.1 │     │
│                        └────────┘     │   │                   │    └────────┘     │
│                                       │   │                   │    ┌────────┐     │
│                                       │   │                   └───▶│ v3.0.0 │     │
│                                       │   │                        └────────┘     │
└───────────────────────────────────────┘   └───────────────────────────────────────┘

An additional variation that can occur is related to the cardinality of data. We can easily picture a situation where
data can be described in an expanded or compacted form (i.e.: MINDS - Minimum Information about a Neuroscience Dataset):

┌───────────────────────────────────────┐   ┌───────────────────────────────────────┐
│Expanded                               │   │Compacted                              │
│                                       │   │                                       │
│  ┌─────┐       ┌─────┐       ┌─────┐  │   │                                       │
│  │  A  │◀──────│  D  │◀──────│  E  │  │   │                                       │
│  └─────┘       └─────┘       └─────┘  │   │                ┌─────┐                │
│                   │                   │   │                │  F  │                │
│                   ▼                   │   │                └─────┘                │
│  ┌─────┐       ┌─────┐                │   │                                       │
│  │  B  │◀──────│  C  │                │   │                                       │
│  └─────┘       └─────┘                │   │                                       │
│                                       │   │                                       │
└───────────────────────────────────────┘   └───────────────────────────────────────┘

I becomes immediately obvious that using a single identifier is not sufficient to properly describe data hosted in the
system. We need to both uniquely identify representations and the information behind. We also need to be able to
correlate multiple identifiers.

A generally accepted best practice in dealing with linked data is to ensure that identifiers are directly resolvable
by making use of URLs as identifiers. The downside of using URLs is that they are
location bound as they represent "a reference to a web resource that specifies its location on a computer network and a
mechanism for retrieving it".

The immediate alternative that offers location independence are
URNs but they are not directly resolvable which makes their use
a little less accessible. The latest changes to the URN specification are brought in 2017 in
RFC 8141 that extends URNs to allow slashes ('/') in their NSS but also to pass
parameters to either the underlying resource (using the newly introduced q component) or a resolver (using the newly
introduced r component).

Our proposal to address the above mentioned use cases is to use both URLs and URNs as identifiers. The URL continues
to be the main identifier for resources (representations) while we introduce a new identifier using URN compliant
values to correlate between different representations of the same information in multiple systems.

An example format would be (notice the lack of administrative prefixes in the urn value):

{
  "@context": "...",
  "@id": "https://{fqdn}/v0/data/{org}/{dom}/{name}/{version}/{uuid}",
  "urn": "urn:nexus:data/{uuid}"
}

Allowing this distinction between data and its representations forces an implementation of resolvers for URNs that are
used in the system, but also enables decentralized resolving of URNs making use of federated nexus deployments under
arbitrary topologies.

To be further specified:

• implications of the proposed identifier allocation strategy to API with the considered use-cases
• contract / guarantees of Nexus URN resolvers

Requests with invalid query parameters are not rejected

GET xxx/staging/v0/schemas?=q=person

Notice the ‘=’ before ‘q’. It returns 178 results but the true one, without this '=', returns 17 results. The returned results are invalid because at least one of the result doesn't contain 'person'.

Nexus should reject a request with invalid query parameters.

Limit the resource payload

From nexus-kg created by umbreak : BlueBrain/nexus-kg#543

There are akka properties which define the maximum size for transmitting messages across nodes on the cluster

• akka.remote.netty.tcp.send-buffer-size
• akka.remote.netty.tcp.receive-buffer-size
• akka.remote.netty.tcp.maximum-frame-size

We should match those values to the maximum payload we allow for resources in the platform, otherwise we won't be able to messages across the cluster nodes which are bigger than that size.