This is the first batch of APIs that my team - the Watson Developer Cloud team - is exposing through IBM BlueMix for everybody to try and use. We have many more APIs in the pipeline but we decided to come out quickly with a small set to start with. We are trying get some early feedback from the developer community on what they find useful, what they'd like to see, how the APIs are designed, the quality of the documentation and example code, etc. Comments and questions are very welcome!
- It says, "During the BETA period, all Watson Services will be available for free on Bluemix." So what are the prices after the beta period? I can't put the time into learning this if it's not viable after the beta.
- What is Bluemix? Is it just the "place where all the services are?"
2. BlueMix is the IBM PaaS - it has a lot of powerful services beyond Watson - http://bluemix.net. It allows you to create and deploy apps in the cloud.
Presently IBM's just getting in the space. I was offered a chance to use BlueMix during the closed beta. I didn't for the same reason you mentioned: they didn't have a pricing plan. I too thought, "What's the point of building something if it will be really expensive later?" Fortunately, IBM seems to be reasonable when they came out with pricing.
I wouldn't build my company around the beta of Watson, but if you experiment during beta, you could have first mover advantage when the pricing comes out and you find it acceptable.
While it's not something that you'll have running completely on your mobile device, it's something that you can easily run on the backend server. Fortunately, BlueMix provides lots of very useful services for mobile devices, including automatic crash monitoring, user feedback, and cross platform push services. Feel free to find me on twitter (same name) and I can provide more details.
I dont think they were intending for this to go out on production applications just yet. You could just play around with the API in some personal or open source project for now. Whatever pricing plan they come out with should be reasonable.
Bluemix is IBM's implementation of CloudFoundry, an open-source Heroku-like platform-as-a-service. Presumably they're making this API available as an add-on to Bluemix applications.
Looks great! One question: Any plan for additional client libraries / demos beyond java, nodejs, ruby/rails? e.g.
- django (python)
- flask (python)
- obj-c
- scala
- go
* Plug for python - lots of ml / nlp / scientific computing done with using python.
What you guys do is awesome. I'm interested in machine translation. I know python and NLTK. I have a grasp of statistics, I'm learning everyday more. Will I be able to design a domain-specific machine translation system with Watson?
Yes but it's not yet available. The current service only provides a fixed domain but we will extend the API and provide tools to allow you to specify a custom domain. Offering the ability to domain adapt all these services will be a key differentiator of the Watson services. Stay posted!
It's great that you've released the functionality. And you asked, so I hope I don't come across too harsh. I'm looking at your examples, here for example:
To make a simple call with the Java example, you've managed to write 372 lines of code.
Three hundred and seventy two lines.
That's some bad code.
There's nothing I can point at and go, that, that's what's wrong, the whole thing just has a lot of code smells. The 'zZz's (what is that DIY escaping all about?). The multiple http calls that should have been abstracted into one function, but aren't. The over commenting. The api structure requiring you to do 3+ calls. The exponential call back time (this is not a good idea, have fun with weird bugs). That you've made your own json objects. That you've used PUT for a pretty tenuous reason. That you've put all the urls in some config file or something, so the code isn't particularly clear at what it's doing.
The ruby & javascript are more terse because those languages are, but they aren't that much better. It's often silly little things, like this:
There really is no good reason to use 'querystring.stringify' in that instance, it's not user input. The code's simply over-complicated.
The code reads like a sysadmin/amateur/uni professor's code, a scripter rather than a professional programmer's. It's like you don't have a senior dev on the team to cast an eye over it and get rid of the excesses.
The APIs themselves are not bad, as I mentioned there's the slightly tenuous PUT stuff, the only other annoyance I could see is that you'd have to ping it all the time to see if it's ready. I appreciate why, and you've made the right call in the callback vs ping, simply because so often when hacking setting up a callback would be hell.
It's better than a lot, like google or paypal, so it's not all bad.
Since the sample Watson code is downloadable and intended to show how to use these services, I find it odd that you cite "over commenting" as a problem. Comments are a great thing in sample code, especially in code that you can download separately, without docs.
For the jobid example, the stringify is necessary because the jobid returned by the server includes a # symbol. Try the code you suggested and you get the result: "Error: ContextExpansion Error: jobid is in incorrect format."
This is a perfect example of why I don't like to take silly shortcuts based on tenuous assumptions like the GP suggests.
Assumptions, more often than not, (1) change, (2) are understood differently by others, and/or (3) (as in this case) are flat-out wrong. Code that takes "advantage" of such silly assumptions usually (1) are poor examples to coders new to the project, (2) complicate reviewing the code for correctness, and (3) waste brain-time figuring out when they can (and can't) be applied.
Just escape everything that should be, whether you think you know what it is/where it came from or not.
This rampant clumsiness is fairly typical for IBM code samples--doing things manually that should use a popular library, or choosing obscure or IBM-invented libraries for common things. For example, the Java example should really use Jetty or CXF for JAX-RS rather than mucking about with HTTP client calls directly...
