Redefining containers

[yoavnash]

The usefulness of the container concept in CUDS, as it's used today, is arguable. On the one hand, it allows packing CUDS objects together, which is useful, for example, to ship them over the network as one unit. On the other hand, it creates the overhead of marking (in compile time) the containment relation as an "active relationship" in every ontology that the user wishes to install. Moreover, such containers are not helpful for specifying access rights since such information inflates the size of each CUDS object.

A new redefinition of this concept could bring great value to OSP-core and its users:

• A container is not a CUDS object, but a separate kind of object.
• A container allows SimPhoNy users to cluster together CUDS objects.
• This cluster must not necessarily contain only active relationships and objects can be in the container even if they are connected at all.
• Similar to the 'repository' concept in AllegroGraph or GraphDB that separate the data, but also allow "federated queries"
• Nested containers are allowed (as opposed to AllegroGraph repositories).
• Maybe allow raw files to be associated with a container
• A container can contain also user-defined metadata (e.g., via DCAT). For example, machine name, creation date, etc.
• A container can contain information about access rights.
• Parsers, like those mentioned in #620, can create containers in a predefined structure. As an example, this is helpful for ASCII files coming from testing machines that are very similar.

In code, this could look like this:

from osp.core import Container
my_container = Container(name="myContainer") 
with my_container:
    c = ns.SomeClass() # c is added automatically to my_container 

In this way, containers are still useful as before for packing objects together in a recursive manner, but eliminate the need for defining active relationships, and allow to add additional information, for example, for access rights, with low overhead on the CUDS objects.

the containers themselves can be stored separately from the CUDS objects, for example, in an SQL database while CUDS objects are stored in a triple store, for the sake of modularity that separates such operational information from the actual data.

[yoavnash]

Notes:

• A session could have a default container that could be invisible
• Goal is to unify wrapper, session, and container

[yoavnash]

A sustainable fix to #626

[kysrpex]

This is the progress in the design process so far (I would say almost ready for implementation if not ready): https://owncloud.fraunhofer.de/index.php/f/358369261.

[yoavnash]

This issue is being addressed separately as part of the discussions on the new cuds concept.