Bugs, feature requests and thoughts from ELIXIR/de.NBI hackathon

[joncison]

List of suggestions from http://tinyurl.com/registryhackathon7

What are the highest priority developments on the bio.tools registry ?

• [ ] pull mechanism, a URL is registered, and the registry pulls the content from here, validates and imports this implies that such content would not be world-editable : changes would have to be made on the provider side it would also be needed to register a contact email to report errors
• [ ] character restriction : UI should tell you how many chars you have left
• [x] a staging post for adding content, that is kept private until folk want to publish errors in JSON when edited in UI, couldn’t edit description in UI, had to edit in the JSON directly (bug)
  • staging post no longer needed given lower info. requirement, editor bug fixed
• [ ] declaration of schema version in JSON or XML output
• [ ] cloning an entry, to facilitate editing of similar entries
• [x] custom license - provide link to license text
  • license would be "Other", add link via <link><type>Terms of use</type></link>
• [ ] tool, which is also offered as a service with similar but not same functions. Need way to preserve then edit the description (conversion tool for Christian Anton)
• [x] make regex visible on publication fields
  • examples, not regex, now given
• [x] change EDAM term using UI, this changes the label but not the URI in the JSON (bug)
  • fixed
• [ ] fine-grained user control similar to google doc style PLUS “drive by” edits, with some moderation page that can accept these suggestions
• [ ] enhance credit system: use of subdomains, with basic branding (but this a political decision)
• [ ] support for card view, or basic query UI, in local places
• [x] basic docs on how to provide a basic view of content, from download of a JSON for a collection etc.
  • https://biotools.readthedocs.io/en/latest/
• [x] must have unique names for tools (via URI) - and at least tag duplicates
  • fixed
• [ ] twitter announcement of every new tool registered - especially once we have the new API / reference set of tools

More

• [ ] add a role of “consultancy” role to the field for tool-specific consultancy
• [ ] add a section “friend of bio.tools” which is a link to relevant bioinformatics support sites,fora, community projects etc.
• [x] user feedback system that lets user rate quality of tools This would help to identify access or other problems and would useful to rank tool search results Sebastian Juenemann: no good idea. Any rating creates some kind of ranking and rankings creates competition. Also such systems must then be protected from abuse and fraud. Strictly separate ratings and registry (only link to external resources for feedback and rating).
  • will not fix
• [x] provide a DOI per registered service that enable authors to reference it in a paper
  • use unique biotoolID assigned for each tool
• [ ] support of metrics for frequency of tool discovery, access, update etc. Sebastian Juenemann: Again, this is not top priority for a registry and should be used with caution to prevent competition, abuse, and so on.
• [ ] consider quality measurements like available source code
• [ ] regularily check for broken links, report them to authors and mark non responding authors or broken links
• [ ] suggest reviewer guidelines
• [ ] request authors to register tools of their submission into EDAM registry
• [ ] EDAM ontology switch terms deposition and submission

Sebastian Juenemann:

• [x] Offer the possibility to keep new registry entries unpublished until published explicitly by the authors upon they are publicly available and cannot be unpublished anymore. This allows for joint creation of new entries without publishing unfinished tools/services.
  • no longer needed now info. requirement is lower
• [x] Enable sub-domains for different levels in the affiliation hierarchy (or for the collections) for the registry front end (e.g. denbi.bio.tools; or europe.bio.tools -> europe.germany.bio.tools -> europe.germany.berlin -> ....) and maybee offer front end customizations for each sub-domain to allow for affiliation specific branding (again, denbi here is currently the main topic until de.NBI joins ELIXIR)
  • sub-sub-domains not supported, but you can emulate the structure using '-' (dash) character, e.g. europe-germany-bio.tools etc._
• [x] Sustain old tool cards (in the registry) for old versions or for tools/services which are outdated in terms of the schema they are supporting (they were created under). This way the registry also keeps track of the history of all tools/services ever registered and not only of the most recent (and currently maintained) one.
  • _all entries / biotoolIDs (hence Tool Cards) persist once created (although deprecated tools, or unfindable / 404 entries may be hidden)

Versioning

• [x] Schemas should have a version so it is defined to a parser/importer what version of a schema to apply to validate. This might ease transition to new versions. Maybe a scheme like “Semantic Versioning” might be applied: http://semver.org/
  • done
• [x] add in Web UI the possibility to select top level term for defining input and output for field “data type” and “format”
  • will not fix instead there's an "I don't know" button prompting to specify terms as free text (in cases where an EDAM term didn't exist or couldn't be found)
• [ ] the description field is restricted to 1000 characters, is this restriction needed? If yes, it would be helpful to show how many characters are already used
• [ ] IPK plan to push updated or new service registrations as part of the internal deployment process that is done using maven.
• [ ] allow own License

Link to CTD (common tool descriptor) schema: https://raw.githubusercontent.com/WorkflowConversion/CTDopts/master/schemas/CTD_0_3.xsd

[joncison]

Much of this done or in the pipeline, need to tick off issues above, or create individual issues for remaining tasks, before closing this monster list.

[joncison]

Need to discuss this first then breakdown into separate issues