Expose node description metadata

[applio]

Greg comment: Figure out what we want to do about the node annotations/titles thing. This might have different answers on the server and locally.

[applio]

Jon Fuller comment from 31 Aug: Summarising what I think that we discussed when we were in Konstanz.

In the Python API a method returning the: Node Description Node Name Parameter Name Parameter Description anything else?

would allow a user of Jupyter to see the workflow image and reference the correct node without needing to change how users already interact with the REST API and without needing to change workflow concepts that we already use.

In order to support that we'd need to make one small change on the KNIME Server in order that the REST API can also return the Node Description (and we need to check that we would return the correct Node Name). Once I get confirmation that is what we need, then I can open the ticket and queue that somewhere near the top of the backlog.

[applio]

Jon Fuller also commented from 31 Aug: Apologies for the confusion. Thorsten just pointed out that the final agreement was purely to return the 'Description' in addition to the Parameter Name. 'Description' is the field that is specified in the Node Configuration dialog.

So API method returning: Parameter Name (that's already part of the REST API) Parameter Description (scrum 3 would need to add that)

Hope that clears things up.

[applio]

If I might summarize what I believe is being suggested by Jon after influence from Thorsten:

• Changes are to be made to the Server REST API
• Node Annotation will not be exposed by the Server but other things (that potentially very, very few people would actually find helpful) will be

While I could expose these other pieces of information through Python, (1) it's unclear how useful anyone would find them and (2) until it is exposed on the Server it seems premature to expect that they will definitely be supported on the Server.

[bernd-wiswedel]

I know you both (@greglandrum and @applio) have a strong preference to make the 'node annotation' (the text below the node on the canvas) accessible, both on the server and version '1.0'. I also know that Michael will hate that and he communicated that already.

"I always found the use of the node "annotation" for BIRT weird. It's an informal field for informal comments and suddenly (parts of) it gets used for an interface function. To me this information really needs to be part of the configuration dialog.

I see the one disadvantage: the info is not readily available (=visible) in the workflow itself - but maybe we should fix this instead then? I'd kind of always wanted to be able to quickly see the main options of nodes (file read...) anyway."

In that context we were talking about server and REST interface but I am almost sure that also translates to the crawler that Davin wrote.

[applio]

I should have thought to also copy Michael's comments into this issue -- thank you for adding them @bernd-wiswedel.

I agree that today we should not make the 'node annotation' readily available to the user.

I very much like the idea of making more relevant info available/visible to the user in the KNIME GUI when looking-at/hovering-over a node. Even if this functionality were somehow delivered by St. Nicholas in 2018, there will be a significant delay before end users change their behavior to start adding helpful metadata-commentary to their nodes in the newly supported way. This sounds like a good approach but there is nothing for us to change in the knimepy package until later, unfortunately.