search

ibm-cloud-solutions / hubot-ibmcloud-nlc

Adds a framework to enable Natural Language interactions in your Hubot scripts
http://www.ibm.com/
Other
11 stars 1 forks source link

Relationship Extraction will be deprecated (July 27, 2016) #12

Closed aeweidne closed 8 years ago

aeweidne commented 8 years ago

"Relationship Extraction will be deprecated on July 27th 2016. If you want to continue using Relationship Extraction models, you can now access them with AlchemyLanguage." http://www.ibm.com/smarterplanet/us/en/ibmwatson/developercloud/relationship-extraction.html

aeweidne commented 8 years ago

This has been a fairly major undertaking since Watson Alchemy does not provide everything Watson Relationship Extraction does (did). In particular, it does not externalize the parts-of-speech tagging results. We were using this extensively to pull entities (appname, service name, ... ), numbers, and various other items from the statement. It also does not provide entity results for dates/timeframes or urls.

No open npm open source parts-of-speech package provided exactly what we needed. Due to its activity and its comprehensiveness, I chose the 'pos' package. The upside is that it is very reliable in creating parts-of-speech. The downside is in the way it breaks up a sentence for tagging. The division is not on a typical word boundary (whitespace) but is instead around punctuation,special characters, and numbers. This causes difficulty when looking for entities with numbers in them or when the statement contains a url.

Instead of an reManager, we now have a paramManager. The paramManager has a function to getParameters for a given class and statement. Under the covers, it creates a paramDecoder instance. This class handles using 'poc' and Alchemy to obtain nouns, numbers, and cities based on the output of these packages. There is also a paramHandler object which contains a function to handle each of the parameter types (entity, keyword, number, repourl, repouser, reponame, and city). These functions can use the paramDecoder if desired or can use other means (such as regex) to pull what it's looking from from the statement.

The paramManager now makes two passes: 1) Make a full pass for all defined parameter using the original statement. When looking for entities, this pass ignores nouns found in the seed texts. 2) Make a second pass for all parameters without a value using a statement that removes all parameter values found on the first pass. This is especially useful when the numbers and urls are removed.

If some parameter values are not found after two passes, the user is involved using a conversation. The user will be prompted to enter a specific parameter value (using a defined prompt or a default prompt if one is not found). This reply can be natural language. Again, the paramManager will try to pull the value from the statement. If this fails also, the user will be prompted to enter the parameter value as a single word.

Hopefully, at the end of all this all parameter values are obtained.

The definition of the parameters needed for a command are in a json file ... the same json file that contains the text to seed the command with. The general format is:

"parameters" : [{ "name": "appname", "type": "entity", "prompt": "OK. What is the name of the application for which you want the logs?" } ]

aeweidne commented 8 years ago

This is done, but I'd like to capture @houghtoj summary and comments on what the removal of this service meant to us.

@todkap What is the appropriate forum or person to discuss our experience with the Relationship Extraction service removal?

aeweidne commented 8 years ago

@jpadilla My desire is to get them in some form of writeup (slides / doc) and we can use Greg to help communicate this with the appropriate teams. I am trying to set up an interlock with the Watson in Support Architect with you and @nbarker but this is separate. The more we can do to collaborate and share lessons learned the better.

aeweidne commented 8 years ago

There is one more item that @ycao brought up. Watson RE is also used by the weather command. It is used in conjunction with Watson Alchemy to provide the best guess at the desired location. I think the simple solution is merely removing the use of Watson RE and using Watson Alchemy exclusively. The better solution is having the weather scripts go through the cognitive flow. @jpadilla has indicated he is currently looking at this.

jpadilla commented 8 years ago

@aeweidne I think you've got the wrong @jpadilla.

jlpadilla commented 8 years ago

@JonHoughton I'm closing this since we have removed RE from hubot-ibmcloud-weather which was the last remaining part.