openMetadataInitiative
(web) service revision - renaming WebService(Version) to Service(Version)
Not all digital services are web services. I would like to bring them together. Their exact type (e.g. "web service", "system service", etc) should be an annotation.
This would also pave the way towards other service types which need totally different schemas. E.g. HumanService(Version) (e.g. Curation, etc) or HardwareService(Version) (e.g. service to a specific hardware, e.g. scanner, neuromorphic chip, etc) etc.
We need to discuss general service types (and which of them have joined or very similar metadata).
discussion result with the dev team: renaming is a good idea. additional properties should clarify the exact type.
digital services are often used as synonym for virtual services We rather mean technology-centered services vs human-centered services
| Service | ServiceVersion | comment |
|---|---|---|
| contributors | contributors | -> Contributor (or other, cf. #513) |
| fullName | fullName | |
| shortName | shortName | |
| description | description | |
| fullDocumentation | fullDocumentation | maybe rename to documentation (value as before) |
| PID | PID | how to enforce this for human service? |
| homepage | homepage | needed in RP and RPV? |
| keywords | keywords | needed in RP and RPV? |
| systemicRole | versionIdentifier | |
| innovationType | versionSpecification | |
| accessMode | accessType | cf https://github.com/openMetadataInitiative/openMINDS_instances/issues/260 |
| supportChannel | accessLocation | cf https://github.com/openMetadataInitiative/openMINDS_instances/issues/260 |
| type | releaseDate | |
| ---- | usageCondition | cf #505 |
| ---- | inputFormat | needed here or should stay with SWV? |
| ---- | outputFormat | needed here or should stay with SWV? |
| ---- | repository | -> FileRepository (optional) |
| ---- | funding | -> Funding |
| ---- | relatedPublication | -> DOI, etc (optional) |
| ---- | isVersionOf | -> Service |
| ---- | isNewVersionOf | -> ServiceVersion (optional) |
| ---- | isAlternateVersionOf | -> ServiceVersion (optional) |
| ---- | function | -> cf #527 |
| ---- | interface | -> (GUI, API, CLI) (optional, NA for human service) |
| ---- | dependsOn | -> RPV (1-N) (maybe teams?) |
type: (human-centered service, technology-centered service) systemicRole: (operations, core, complementary) cf #527 innovationType: (science, non-science) cf #527 accessMode: cf https://github.com/openMetadataInitiative/openMINDS_instances/issues/260
@apdavison within the service working group the question came up if services should at all be versioned, or if they should just be overarching constructs for software versions.
Taking the EBRAINS Lab as example: there is no option to select a version for the EBRAINS Lab. All older implementations are not available anymore for a user. It is composed of software versions from JupyterHub, JupyterLab (multiple versions), and ESD (multiple versions). Newer "updates" of the EBRAINS Lab only contain new ESD or JupyterLab versions and keeping all the old ones for a user to choose from or are made because of bug fixes in the UI. So a new update of the service does not affect the functionality of the service for a user in an old setting.
In principle of course every change (even not relevant for an end user) would mean a version update but does this makes sense? This could lead to a lot of service versions where all older ones are not relevant/accessible anymore (status: not available). In a lot of cases where these updates are happening frequently these updates are not tracked as new versions. Version releases would be an enforcement from our side. Not sure if we can get this through.
On the other hand there might be services where users can actually choose which version of the service they want to use. Example: hybrid times of KG v2.0 and v3.0 (at least we had this hybrid running for a while before deprecating v2.0). And changes between KG v2.0 and v3.0 had high impact on the functionalities for the end user.
Not really sure how to proceed here.
Services need to be versioned for four reasons (possibly more):
- sometimes multiple versions are available at the same time (as for the KG, which still has both v3 and v3beta running)
- provenance/reproducibility. It is important information to know that a particular computation was done using a version of the service that is no longer running, and so may have to be modified to run with the current version
- documentation/tutorials - if there is a video tutorial on how to use the service, for example, it helps to know if it's a tutorial for an older version, the user will be less confused when things look different
- changelogs/marketing/reporting - so that we can tell people about all the wonderful new features...
Given this, I would be inclined to only register new DigitalServiceVersion instances when:
(1) there is a change that will affect the results that a user will obtain - this only really concerns REST APIs; (2) when there is a major change with new features we want to tell people about; (3) when the UI changes significantly.
For the EBRAINS Lab example, probably a single DigitalServiceVersion would do. You may wish to add a new one when there is a new major release of Jupyter Hub, if it changes the functionality/UI significantly.
access mode:
- virtual vs physical
access types:
- open access
- login-controlled access
- consent-controlled access
- payment-controlled access
- admin-controlled access
- review-controlled access
- mediated access
access location:
- on-site
- off-site
- mediated on-site
To be discussed in its own issue: https://github.com/openMetadataInitiative/openMINDS_instances/issues/260
@apdavison thanks for your feedback here. I fully agree with this approach. This seems the most logical way of handling this.
@openMetadataInitiative/openminds-developers updated the overview for the revised service schema above. I'm not sure if it is necessary to split into human and technology-centered services. Please go through and think of edge use cases to see what does not fit or what we are missing.
@apdavison @olinux (@openMetadataInitiative/openminds-developers)
What about the following logic (purely for service and software)?
Service - dependsOn -> Software (1-N) Service - isExposedBy -> interfaces [API, GUI, CLI] (1-N) Service - utilizes -> (SDK/Software, Schema, Webhooks ?TBD?) (maybe merged into dependsOn)?
Software - isExposedBy -> interfaces (optional) Software - dependsOn -> Software (1-N) | or rather point to requirement file? or both options? Software - defaultConfiguration -> configurations [] (optional)
Hardware - isControlledBy -> Software (optional)
I/O formats could be specified on (optional):
- interfaces
- software (they might be the same but do not have to be)
Storage (type, location?, size?) of temporary or longterm I/O data? (optional)
Human components in this (can be covered by contributors + contribution role?): Human - isDeveloperOf -> [Software, Service, Hardware] Human - isOperatorOf -> [Service, Hardware, interfaces (in case of indirect access)]
Service, software, and interface require a file repository to store their files. Question: Do we want to single out certain files besides configurations and documentation?
Point raised within the EBRAINS TC meetings that we should consider for the rebuild of the service submodel: how can we provide descriptions for different audiences (e.g. users, developers, operators, reviewers)?