back to main documentation page
Sidestnd is focused on management of metadata resources (files). When working with files, we commonly need to determine if files are identical, similar or different. If not done properly then there will be issues, for example different copies with the same name floating around.
To determine whether files are identical, Sidestnd works with content-based hash values as identifiers for files. Hash values are a low-level, binary way to distinguish between files: the file content is either the same or it is not and this is expressed in the hash. When organising and deduplicating files it is preferable to use hash values and move interpretations about differences or similarities to a higher logical level.
There are many ways to define these higher level logical groups. Sidestnd takes inspiration from library science. This leads to a data model with the following grouping abstractions:
The logical grouping that is "lowest" or closest to the files is the "manifestation" abstraction. A manifestation is a specific representation of content. For example, when a PDF version is exported from a Word document then each is considered to be a manifestation.
When we say that two representations are realisations (or renderings) of the same thing, we have to define what "same thing" means. Here, it means the intellectual content without the file and format-specific characteristics. It is the state that was good enough to be realised in at least one representation. It is often called a version. A version is a logical grouping that can be seen as "our ideas at this point of time". If there are multiple manifestations within a version, it is common practice to treat one representation as the "source" of which the others are "derived", but this is not mandatory.
When there are multiple versions, there must be the same overall intellectual product - they are "versions of" something. This abstraction is called the work. A work is realised by one or more versions (which in turn is realised by 1 or more manifestations).
The relationship between work and version is called a composition relationship. This means that the version only exists in the context of the work - it cannot exist outside of a work. The relationship between version and manifestation is also a composition relationship.
In summary, each metadata resource file will be classified according to the manifestation, version and work groupings. This does not mean that there is a single best solution or truth. Reasonable minds can have differences of opinion if something is a new work or a different version of an existing thing. That is unavoidable. The main benefit is that we have something that can help us talk about these things.
There are several types of identifiers in Sidestnd.
The identifier of a metadata resource is based on its contents. It uses the calculated SHA256 value in combination with the file extension. The original filename is stored separately (in the manifestation object that represents the file).
Each grouping level in the data model (work;version;manifestation) has its own (type of) identifier.
The work identifier is the most important because it sets the context for the version and manifestation level. A 32 position GUID is used as the work identifier. For all intents and purposes, this guarantees that a work identifier is unique. The main disadvantage of using GUIDs is that they do not give any insight into what the work is about. A human-readable identifier is therefore added in the form of a name property on work. It is a a kind of secondary identifier that must be unique within the scope of the person or organisation owning the work (where the work GUID is globally unique).
The version identifier does not have to use a GUID because it only has to be unique within the scope of the work that it is part of (the composition relationship). Each version has a mandatory property name that functions as a version identifier. It must be unique within the scope of the work that it is part of.
Manifestation identifiers work in a similar way. A mandatory property name functions as the manifestation identifier. It must be is unique within the scope of the version that it is part of.
Additionally, users and organisations have their own identifier schemes. Each user is primarily identified by their emailaddress. A 32 character hexadecimal string that is based on a md5 hash of the user's emailaddress is created as well. This is mostly for internal system purposes. Additionally, users are assigned a 5 character short id. Each organisation is primarily identified by a domain name. A 32 character hexadecimal string that is based on a md5 hash of the organisations's domain name is created as well. Again, this is mostly for internal system purposes.
URIs build upon/use identifiers. They are essential for exposing resources. The following URIs are available:
/works/{workguid} returns HTML page/rest/1.0/works/{workguid} returns JSON representation of (metadata) about work/works/{workguid}/versions/{versionname} returns HTML page/rest/1.0/works/{workguid}/versions/{versionname} returns JSON representation of (metadata) about version/works/{workguid}/versions/{versionname}/manifestations/{manifestationname} returns HTML page/rest/1.0/works/{workguid}/versions/{versionname}/manifestations/{manifestationname} returns JSON representation of (metadata) about manifestation/users/{userid} redirect to HTML dashboard start page when userid is logged in/users/{userid}/works/{workguid} redirects to /works/{workguid} for a work that is owned by userid/users/{userid}/works/{workname} redirects to /works/{workguid} for a work that is owned by userid/organisations/{organisationid} returns HTML page/rest/1.0/organisations/{organisationid} returns JSON representation of (metadata) about organisation/resources/{resourceguid}.{resource original extension} returns file /u/{usershortid}/{alias} returns file (only if user has created a file alias)Please note: resource URIs and manifestation URIs do not return the same thing. A manifestation URI returns metadata about the resource that it represents, whereas a resource URI returns the file itself.
Also, URIs are case-sensitive.
Metadata resources usually have a low risk in terms of security or privacy. Even so, there might be reasons to limit access. There are several options to organise/limit access.
At the most basic level, Sidestnd uses security-by-obscurity. Most URIs use GUIDs. There is no index file for crawlers to use. Also, there is no global search function in Sidestnd. This means that there is no easy way to find or query for information unless a URI is explicitly shared.
Additionally, a user can limit access to a work to invited members only. A similar mechanism exists for organisations. An organisation can create a member group and make access to its works members only. Creating such a group can be as simple as automatically admitting everyone with an emailaddress from that organisation, or by explicitly inviting users one by one.
If metadata resources must be protected further, then it is always possible to publish them as a password-protected ZIP file and have a separate mechanism for sharing the password.
Sidestnd provides two comprehensive methods to export your information:
The exported JSON file includes all URIs and aliases created for the work, ensuring complete portability of your data. This approach guarantees that nothing remains locked within Sidestnd, giving you full control over your metadata resources.
Especially when you are starting out with Sidestnd, working with a single file at a time can be a little bit cumbersome. For these situations, Sidestnd Flux is a tool that can help you organise, classify and prepare a set of files.
You can upload a ZIP file with metadata resources and then iterate towards a classification with works, versions and manifestations. When everything looks good, you press a button and all actions are executed.
Currently, Sidestnd Flux is only available for publishing as an organisation.
Many metadata resources use a reference mechanism to other files. For example, JSON or XML schemas often employ import or include mechanisms to utilise common components. For validators to work properly, they must have access to all linked parts. It would be annoying if the validator would have to download a ZIP file, extract it contents and (only) then be able to validate.
Sidestnd addresses this with its "complex file" support. The process works as follows:
This results in the addition of two manifestations:
This approach enables validators and processors to work with complex file structures without needing to extract the ZIP file themselves, while maintaining the integrity of all references.
This is a simple question with a complicated answer. In principle, the rule is "once published, always published". In practice, this is not how things work. Therefore, there are several mechanisms for downgrading or making content inaccessible, even though doing so is not encouraged.
Once a work has "approved" status, two options exist for managing its lifecycle:
This approach ensures that published content remains stable and reliable for users while providing appropriate options for managing content throughout its lifecycle. Once a work has status approved, it cannot be deleted easily anymore. If deletion is necessary, then there are two ways forward.
While Sidestnd allows flexibility in naming (subject to the general conditions of use), the following uniqueness requirements must be met:
Make names self-descriptive:
Keep names consistent:
While Sidestnd doesn't enforce these consistency recommendations, following them significantly improves the usability of your metadata resources and helps other users understand the relationships between different elements.
Sidestnd offers three mechanisms to monitor works managed by others, each providing different levels of engagement:
The most basic option is to click the star icon next to the title of a work. The work will now be listed on the start page under "Bookmarks" for easy access. This option will not give you notifications, but it makes it easy to find the work again.
Next, there is the option of clicking the follow icon next to the title of a work. This means you'll receive push notifications whenever the work changes. Push notifications will be shown online on the start page, and if desired sent to your account's email address.
The most comprehensive option is to clone a work. Cloning means creating a copy with a new owner (you), which makes it possible to add/organise your own files. After clicking the copy icon next to the title of a work, you will get a popup window with clone options. Cloning is further described below.
Cloning creates a new work (with its own GUID / URI) based on an existing work. It allows you to build upon content you don't own. It is similar to a fork in open source software. As the owner of a cloned work, you can add versions and manifestations and develop the work in a way that might not have been possible with the original.
A private context is a dedicated area within Sidestnd that supports reverse proxy scenarios. It is the key enabler for embedding Sidestnd into a different site (with different URI). It is also the mechanism by which higher traffic limits are offered. Private context is a Sidestnd Plus / Sidestnd Premium feature.
It is described in more detail here.
A federation is a Sidestnd Premium feature that makes it possible to create a hierarchical system of connected organisations. There is one root organisation, and 1 or more levels with (child) organisations, each connected to one parent. The main advantage of a federation is that it lets child organisations add information to works that were published by an ancestor organisation without having to clone that work.
Federations are described in more detail here