Modelling tool relations and versions (placeholder discussion)

[joncison]

From @joncison on July 18, 2018 14:48

@matuskalas says (from RostLab meeting 2016):

- Modeling of versions may need rethinking: if we have multiple versions for a single tool for instance, then it will be difficult to maintain the description of the resource for each version separately.
- J: yes! something like a “relation” attribute (between 2 entries) which can have a “role” e.g. of “is_new_version_of” and then with functionality to clone “old” description into the new version (for subsequent updates for latest information)
- Modeling of versions may need rethinking #2: interfaces may have separate versions
- Modeling of versions may need rethinking #3: some tools can be unversioned (e.g. Aquaria webapp). On the other hand, it does also sense to enforce versions, which could then always be AT LEAST a revision/commit/tag of the source code. Question stays, however, what to do if a tool is built from multiple separate components/repos and not versioned as a whole. In any case, “1” is a bad default which may cause a mess!
- Modeling of versions may need rethinking #4: As an intermediate conclusion, it would be nice to allow multiple versions within the same tool record, with ordering, and eventually with some version-specific information attributes.
- Find a way to specify that an interface uses another interface (from the same or a different tool). e.g., Aquaria Web UI uses Aquaria REST API. Plus version.
- J: yes! (from your suggestion last year Matus) we have other roles for the “relation” attribute e.g. “uses_data_from”, “providers_interface_to”, “bundles” or whatever …
- M: this is extremely great! We should at some point enable the relations to be specific to interfaces and versions. But that mandates creating stable cool URIs/URLs for these.
- Plus versions across the relations between tools. E.g. version 2.0.1 of ToolA uses DatabaseX version 3.1 whereas otherwise identical version 2.0.2 of ToolA uses DatabaseY version 3.2.

also

"Special-case scenario with LocTree/2/3, Clustal/V/W/W2/X/Omega, may need “is new version of” and something like “obsolete/deprecated, has a newer version” (“is deprecated in favor of”) relations (or status + relations). Both directions are necessary, as e.g. the two versions may have different entry maintainers."

Copied from original issue: bio-tools/biotoolsRegistry#349

[joncison]

From @redmitry on July 19, 2018 10:50

For tools monitoring we solved this by complex, compound ID:
https://dev-openebench.bsc.es/monitor/tool/biotools:pmut:2017/rest/mmb.irbbarcelona.org
There are:
"prefix": "biotools"
"id": "pmut"
"version": "2017"
"type": "rest"
"host": "mmb.irbbarcelona.org"

There is a special "general" (versionless) record which is common for all descriptions (instances):
https://dev-openebench.bsc.es/monitor/tool/pmut
This compound @id is generated by the REST API while mongodb internally uses the compound index.

Currently in development Web:
https://dev-openebench.bsc.es/html/tool/pmut
Aggregates all instances by their versions and types.

Kind regards,

D.

[joncison]

see https://software-guidelines.readthedocs.io/en/latest/field_relation.html#oas-relation

[joncison]

see also quite extensive old work done on defining relations:
https://docs.google.com/spreadsheets/d/1_KGr2DkulwtAjFJzNjTm08zXVphFlVZ8p29Id6XFlxc/edit#gid=708209843