e.g. some tools have many "Topic" annotations and this breaks the compactness of the "Grid view". Limit it to show 3 topics only. Do this for all relevant fields.

A thread for gathering & discussing requirements for improving the usability of the ontology tree widget

accepting "open" tools only
types of tool
commercial tools are OK
but consultancy services are out of scope
etc.

This causes any change that is made after the save button is clicked to be lost.

Alert service when new tools appear with a particular function, topic etc.

jmcejuela says ...

Use case: group wants to show case all its tools in its own webpage, with all the info kept in the elixir registry

This should be simple enough for any group to pull the JSON and create an interface list of it. However, this could be made easier and more standard for all users as a general widget. Furthermore, the widget could include something like "Powered by Elixir Registry" to make some kind of publicity of the registry itself.

Matus commented that one group already has this specific to their needs. Cannot promise anything at this moment, but would like to standardize this and use the widget on the rostlab.org webpage.

matuskalas says ...

Thank you @jmcejuela . Various institution would benefit from having something like this.

It is, however, a request for the Tools Registry, not EDAM. But let's leave it here until the Tools Registry has it's own GitHub repo ;-)

jmcejuela says ...

True, I realized that later when I posted :-)

Thanks!

API is described in a google doc

Would be nice to get a real API page description with operations and object types, such as provided (for example) by swagger.

(from NL hackathon)
Add collection works only after you have pressed "save resource" > (sometimes, not always)

Suggested by reviewer !

Graphic for scientific domains (EDAM topics) could provide an intuitive / usable way to browse.

Requested at various hackathons.

Low priority, but this has been requested

(moved from edamontology/edamontology#39)
It would be useful having hints for what is expected in the registration form. For example, for publications, should these be *doi numbers *pubmed ids * citations in txt?

When I download a JSON repressentation of the record entry it's "empty":

{
  "resourceType": [
    ""
  ],
  "interface": [
    {
      "interfaceType": ""
    }
  ],
  "topic": [
    {}
  ],
  "publications": {
    "publicationsPrimaryID": "None"
  },
  "function": [
    {
      "functionName": [
        ""
      ]
    }
  ],
  "contact": [
    {}
  ],
  "affiliation": "ELIXIR-NO"
}

When we add a new tool, tool will be prefixed by the affiliation.

If GenOuest user creates for example the emboss registry entry, tool will appear as GenOuest/emboss, though this tool is not owned by GenOuest. This can be confusing for users and could be an issue for upstream authors.

registry does not support CORS (cross origin requests) preventing querying the registry directly from a browser with Javascript. This complexifies the integration with other tools.

Would be nice to get CORS access, at least for GET requests

it doesn't make sense to not display this

A summary of requests / issues from the hackathon (tinyurl.com/registryhackathon5)

Bugs

• Sometimes the popups, even after ‘disappearing', stay above input fields blocking them from receiving any input
• Make sure the primary publication is required/not required in both the API and web interface consistently
• After saving changes of the entry in bio.tools, no further changes can be made. The page needs to be reloaded in order to be capable of storing additional changes.

Features

• Add an endpoint to GET the latest version of a resource, not only a specific one
• Some of the tools are quite similar (in general terms). A nice piece of functionality would be to create a new entry while using information from already existing entry. copy-pasting and subsequent editing of JSON file is pretty annoying.
• It would be nice to have possibility how to style the Summary description of the resources. At least paragraphs, bold or italics.
• Use only URIs for EDAM attributes, instead of URIs and/or terms
• Quicker page loading
• (Lukas) The service seems to be slow (or is doing a plenty of backend operations). After logging in I have been waiting for 10+ seconds until I was capable of working. (other) The initial loading of the home page is slow. It seems to do complex SQL DB queries, however, no data are cached, therefore, after each reloading I have to wait for a long time until the DB query finishes.-
• (Egon) add means to group entries (e.g. all around WikiPathways: website, webservices, RDF version, etc…)
• (Egon) Question: what about more social tools? Like CiteULike which can have a role in, for example, text mining?
• (Egon) support for the ORCID in registry account
• (Egon) support adding developers/contributors by ORCID
• (Egon) ability to bookmark (and socially share otherwise) share a search query (with a lengthy URL, for example) UPDATE: already implemented in the dev version
• (Egon) provide and allow searching for entries with publications with a high #altmetrics score
• (Egon) convertor for Swagger configuration files (e.g. used by WikiPathways, eNanoMapper, Open PHACTS, BridgeDb) to Registry XML
• (Egon) Question: can you define dependencies? E.g. if one tool uses another tool also in the registry?
• example: https://bio.tools/tool/BioConductor/BridgeDbR/1.4.0 and https://bio.tools/tool/BioCatalogue/BridgeRest/1 depend/use https://bio.tools/tool/maastrichtuniversity.nl/BridgeDb/
• (Egon) feature request: allow a search with “collection:ELIXIR-NL”
• (Egon) add a field for Wikidata Q-code (which effective links to all Wikipedia language sites). Discussion start: edamontology/edamontology#36
• (Egon) Have the GUI use the latest EDAM ontology, pref even the development version. This provides an incentive for people to improve the ontology, and without much delay get return-on-investment by being able to use their own contribution in the Registry GUI
• (Egon) ability to add one (or more) screenshots of a tool (“a picture says…”; good for search results :)
• Thinking about interface and functionality ‘standards’ over tools, services and resources
• What standards have been defined over the tools, services and resources stored in the resource registry? e.g. which tools currently support MINSEQE?
• Which tools are programmatically available via an interface that supports the given standard? e.g. at a low level, which services expose REST interfaces e.g. at a higher level, which services support queries for data using standard ‘x’ (as yet to be defined, e.g. by the interoperability platform).

Service alerts – registry to support alerts / notify for when a service changes ; you can sign up to receive these alerts. This important for APIs, less so for tools (buy maybe still useful?)

Karel Berka says ...

"I thought about use of bookmarklet for individual services from the tool papers DOIs (- something like http://www.altmetric.com/bookmarklet.php) Alongside with citation bookmarklet from Crossref (Similarly to http://www.nature.com/nature/journal/v482/n7383/482027a/metrics)"

https://bio.tools/?q=PAA

• Allowing link / pre-filter for the "BioMedBridges tools" (i.e. per affiliation)
• API revisions requested by ELIXIR Hub
  API requests (Query the resources by one or several fields. ie. resourceType="ELIXIR", Return entries just with the information that is relevant for us. ie. fields="title,description,topics,institution", Pagination option ie. start=50&entries=100)
• API support for custom views of columns
  e.g. for EBI, showing specific rows (only EBI tools) but also only specific columns (i.e. info in the EBI Tools Census)
• Requested by WP 7 - new attribute to capture an API is WP7-compliant, then pull all databases from the registry with this attribute set.

Provide this for common tasks as part of improved docs (suggestion from user)

So Green tab if all mandatory fields completed, Red tab if mandatory fields are not complete

Improve appearance of registry documentation (linked to from menus) ... here are nice examples:

https://www.docker.com/whatisdocker
http://biojs.net/
http://www.psidev.info/groups/molecular-interactions

This needs the docs / HTML to be in repo so it can be easily edited, and ideally triggering a Website refresh via CI

shortDescription is limited to 80 characters in Debian Med

description is unlimited

both are desirable!

we can improve the Debian Med short descriptions in due course

When creating a new tool, publication is mandatory. However it is not the case through the API.
All tools do not have a publication, this field should not be mandatory

To access to a tool page (web or API), one need to specify its version.
would be best to get an access to latest version

/affiliation/tool/latest

or

/affiliation/tool

Need to go through and see what can be linked, e.g.

License - link to tldrlegal e.g.
https://tldrlegal.com/license/gnu-general-public-license-v3-(gpl-3) )

softwareType - link to biotoolsXSD on GitHub
https://github.com/bio-tools/biotoolsxsd#resource-types-valid-values-of-resourcetype

interfaceType - link to biotoolsXSD on GitHub
https://github.com/bio-tools/biotoolsxsd#interface-types-valid-values-of-interfacetype

Tools annotated as "private" should not be visible by default to the world, i.e. only to those logged in under the corresponding affiliation

We are using generic URL validators and yes, they don’t like the # element :(

Call tldrlegal to get info (prob. short summary) of license info, exposing this in the Query Interface

Numbers over time (can be in 1 or 2 graphs):

• number of records over time
• of EDAM annotations
• of size of entries
• of number of operations
• of number of users(!), accounts(!), affiliations(!), institutions, ORCIDs, DOIs, PMIDs, collections, etc !!!
• of countries!!! How? (See also next)

Geographical distributions and growth over time!

Somehow...

There is no way to recover a password if lost
One should be able to update his password (for security) or regenerate a new password.

use the corresponding Deb Tag

this required to support import into bio.tools

Lots of people have asked for this! Lots of ways to do it, need some score:
by function primarily
by input/output
then topic
etc.

Do this in all places (Query Interface, Registration Interface, Tool cards)

(moved from edamontology/edamontology#37)
When annotating, it is intuitive for me to press the "save resource" button to save the progress of my annotation. However, having the first tab annotated only, it gives me an error that it cannot be saved because of "topic:null". So, I suggest to have an additional button for saving the annotation progress (at least: browser cookies).

It's awesome that the default sorting is by modification date!
But:

• It should state 'modification' or so, instead of 'addition'
• There should be a corresponding column available in the grid view
• It should be possible to sort by ALL columns/attributes (otherwise hard to search for some stuff)

Deb tags in "biology" category are equivalent to EDAM Topic
Deb tags in "fields" are equivalent to high-level EDAM Topics

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
• 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
• 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)
• make regex visible on publication fields
  • examples, not regex, now given
• 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
• 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/
• 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.
• 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
• 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:

• 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
• 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._
• 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

• 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
• 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

(moved from edamontology/edamontology#41)
We would like to be able to select multiple topics without adding a new tree to search in

Metadata for databases and identifiers known to GO:
https://github.com/geneontology/go-site/blob/master/metadata/db-xrefs.yaml

There is scope to import some of it (e.g. data access URLs into bio.tools)

See also: edamontology/edamontology#69
cc @tonysawfordebi (Tony Sawford at EBI)

Following many request, people do not like having to log in a second time. Something more direct would be better.

(moved from edamontology/edamontology#40)

If you have a name of a contibutor in the registry already, then upon entering the same it should be recognized and autocompleted. Same applies to institution, collection, etc.

Deb tags in "purpose" category are equivalent to EDAM Operation

It is enough just to render the contact name as a link, giving the URL as well looks messy / is not necessary.

Some of this may have been fixed (the issues is to check / fix as necessary)

1. ProP has wrong data format : GIF should be only one of the formats, we should amend it by adding 'textual format' (or child of)
2. SIgnalP has wrong data format : binary format, should be textual
3. Empty documentation on some tools
4. Wrong licenses (is "CBS License" needed, i.e. special license?)

They just look a mess ... better showing them as a pop-up or in the "Tools Pages" only. The "Grid" view is for comparing tools so peripheral text is out of place

Also maybe "cards" view too