redmitry
commented
6 years ago 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
@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_versionof” 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_interfaceto”, “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."