Sidestnd Premium

Federation

overview

A federation is a hierarchical system of connected organisations. There is one root organisation, and 1 or more levels with (child) organisations that are each connected to one parent.

In the context of metadata resource management, a federation is useful because it is a more granular system. In "normal" Sidestnd, an organisation is owner of a particular work. The owner can add versions and/or manifestations. If another organisation wants to add their own versions or manifestations, they cannot do that unless they clone the original work. This works reasonably well (because the clone can be updated over time), but it is heavy-handed - for example, because it leads to a new work URI.
Federation offers something that is half-way between ownership and cloning: it offers a controlled mechanism for child organisations to add information to a work that has been posted by an ancestor organisation (without actually cloning the work).

Suppose that a government organisation X is responsible for metadata management and that other government organisations are encouraged to go to X to get their metadata files. This will work well for many centralised files, but there are two potential snags: local changes and locally unique files (where local means "in the context of the other government organisation, which in this case we'll name Z).

Ideally, customers of Z have one place where they get their metadata resources. So it would be nice if Z "inherits" all metadata resources from X and is able to transparently add their own changes and unique files. This is what federation aims to achieve. Instead of having to clone a work to add information to it, a child organisation can add to a federated work.

implementation

Federation is part of Sidestnd Premium. It works like this:

• a root organisation is the administrative holder of the Premium contract;
• the root organisation defines a Federation, which is a map of all organisations that participate in the Federation;
• an organisation that is included in a Federation is called a Participant;
• there is one and only one root Participant, but there can be as many client Participants as necessary;
• once established, the root Participant can publish works like they usually do. In addition, they can do the following:
  • publish works with visibility Federation-only;
  • make visibility time-based by using Embargo - after X visibility changes to "public".
• a client Participant sees not just their own works but also the works that are published by any ancestor in the Federation. Additionally, they can:
  • add versions and/or manifestations within versions (as long as common constraints are honoured)
    • it is clearly shown that the addition was done by the child Organisation, not the root
• a root Participant can take ownership of a manifestation or version that has been added by a child Participant

Layout customisation

Sidestnd Premium users can upload their own CSS and media files. Further customisation - e.g. page templates - can be discussed.

Support

Sidestnd Premium has a "top of the stack" support model. Any request from the Premium contract holder will get same-day attention and will push all other support request back. This is not a hard guarantee that a problem will be solved immediately, but it means that Premium concerns get premium attention.

Traffic allowance / file size

Source code guarantee

Sidestnd is focused on long-term management of metadata resources. Realistically, groundworkdatamanagement - the company behind Sidestnd - cannot give a legally binding promise that it will exist in ten years or so. There are two promises that we can make:

• you own your data; you can get a full export of all your data at any time;
• as a premium user, you will get access to the Sidestnd source code if the code is not updated for 3 months.

The source code guarantee means that if - for whatever reason - development on Sidestnd stops, a Premium user will get access. This would make it possibly to keep running the software on AWS or otherwise convert it (for example, to let it run on Azure or locally). The period of 3 months is chosen as a reasonable trade-off.