Multiple database acting as source of entities

[sygout]

Define the modifications of the service to handle multiple databases where entities are stored.

The assumption is that different communities might use different databases to store their entities.

Onto-ns service could then explore and recover these entities and check if the uri exist in one or more of the database, if not return an error, if multiple but exactly equivalent return the entity (but inform the database managers about duplication) and if multiple different return error and inform databases managers.

[CasperWA]

After discussing this shortly with @francescalb an idea came up to introduce a "personal" or "project-specific" part of the namespace.

The main issue here is mapping the URI/URL to different backends/databases/entity storages.
We can only communicate differences through the core URL, i.e., we cannot include query parameters or other special parts of the URL to distinguish backends as the entities' uri would have to match accordingly.

So if the difference is introduced in this "core" part of the URL between the current namespace and the version, then that would effectively "fix" this issue, allowing for us to have multiple backends mapping to specific URI/URLs as well as still do all of this through the same service running at http://onto-ns.com/meta.

My suggestion is to define the URIs as follows:

<general namespace>/<specific namespace>/<entity version>/<entity name>.

General namespace: Must be the root URL of the entities service - in the case of onto-ns it is: http://onto-ns.com/meta.
Specific namespace: Any name, could in theory even be a sub-divided namespace like MyProject/TestEntities? The name would then map 1:1 with a backend entity storage in order to not have clashes with how to resolve same-named entities coming from multiple backend sources.
Entity version: The entity version, e.g., 1.2.
Entity name: The entity name, e.g., TEMImage.

[jesper-friis]

<general namespace>/<specific namespace>/<entity version>/<entity name>

is a good naming scheme for new entities. But I don't think we want to change the names of the build-in or existing entities.

[jesper-friis]

For requirements on how the URIs should be written, see SINTEF/dlite#788.

[CasperWA]

For requirements on how the URIs should be written, see SINTEF/dlite#788.

Note, this is true only for the DLite-flavoring.