Revise ProductAccessibility instances/schema (openMINDS_controlledTerms)

[Raphael-Gazzotti]

The current ProductAccessibility instances define access based on payment status (freeAccess and paidAccess). However, accessibility should be independent of whether a product is free or paid.

This would involve decoupling accessibility from payment status.
We may also introduce new access types to cover authentication-based restrictions (such as registeredAccess, authenticationAccess, authorizedAccess...).

Reference:
ProductAccessibility Documentation

[apdavison]

accessibility should be independent of whether a product is free or paid

why?

[lzehl]

related to #132

HERE MY SUGGESTION for updating Research Product Versions:

AccessMode: (maybe this is not only related to access)

virtual
physical

AccessType: (former ProductAccessibility)

open access
login-controlled access (only login required)
consent-controlled access (login + consent required)
single-payment controlled access
recurring-payment controlled access
admin-controlled access (admin grants access on demand)
review-controlled access (review committee/process for access grant)
admin-mediated access (no direct access; only through human intermediary)
system-mediated access (no direct access; only through technology intermediary, trusted federated systems)

AccessLocation:

on-site
off-site
mediated on-site

For software and services we may want to distinguish the code availability (stated below) from the accessibility of using the products functions (stated above):

CodeAvailibility

open-source
closed-source
source-available

[lzehl]

On RPVs these could be either separate properties (access mode, access type, access location, + for SWV MV WRV: code availibility) or one combines at least the common access stuff under "accessibility" with an embedded new Accessibility schema with those three properties (mode, type, location).

@openMetadataInitiative/openminds-developers please comment. This would be a potential v5.0 update.

[apdavison]

An idea for what a new Accessibility schema and associated controlled terms could look like, following on from discussion of axes in the developers' meeting yesterday:

Accessibility
    mode: AccessMode [virtual, physical]
    type: AccessType [open, authorization-required, mediated]
    payment: PaymentType [none, one-time, recurring]
    authorizationProcess: AuthorizationProcess [none, registration-only, admin-controlled, review-controlled, owner-controlled, membership-controlled]

[lzehl]

feedback from @MBAbrams @archgogo

• maybe use "on-site" instead of "physical"
• maybe use "committee-controlled" instead of "review-controlled"

@apdavison I like the suggestion. Question: Embargo would be separate from this correct? Where and with what? E.g. embargo reason, embargo startdate, (expected) embargo enddate?