I just left the following comment on Simon Willisons Blog about Paul Ford’s article on OpenCalais called “Learning to fear the semantic web”
“What is troubling me most (in my role as a person working for a news agency and hence a potential competitor of Reuters) with OpenCalais is section 2 “Responsibility of posting users.” of their t&c’s:
In this section posting users have to warrant all kinds of things but NOT THAT THEY HAVE THE IP RIGHTS for the content they are posting to calais.
In this light the following part of this section:
“You understand that Thomson Reuters will retain a copy of the metadata submitted by you or that generated by the Calais service. By submitting or generating metadata through the Calais service, you grant Thomson Reuters a non-exclusive perpetual, sublicensable, royalty-free license to that metadata.”
gets some ‘smell’.
Especially when you combine this with OpenCalais users like bit.ly (a tinyurl like service) that use calais to index every URL they are shortening and you end up with a scenario in which your content is used to enhance the classifiers of your competitors.
Since good meta-data becomes ever more important wrt. the ‘value’ of content it would be interesting to know the position of calais on this issue and how they will cope with content publishers asking them to remove the meta-data (and the improvent in calais classifiers) originating from processing their content.”
What do you think about this?
Google just added a functionality to its MAP API i was waiting for for quite some time: a reverse geocoder. When our editorial staff is geocoding the news, it is often the case the initial address is slighty wrong (or approximate). Hence they have to move that marker a bit and get the new coordinates and address back. While it was easy to have the coordinates until now the new address (even an approximate one had to by entered manually using some guesswork).
At a newswire every second counts, hence it is important do to as much as semi-automatically as possible. So the availability of a reverse geocoder is good news, because it translates coordinates into an approximate address, that we then can use to pre-populate the address fields. The editor have to type less metadata (they just have to delete some information that is too detailed)
I’ve quickly thrown together a concept prototype that illustrates the concept of the editor interface over here (Code ugly as hell, mainly cut n’ paste from Google sample code. Major functionality missing, no styling etc.). It has to be refined and integrated into our Java based CMS. And yes we have a Google Maps Premier license for using Google maps in an intranet application. And no there were no affordable reverse geocoding alternatives for Germany until now(at least affordable for us).
Why did we have to wait so long
So why did we have to wait so long for a reverse geocoder from Google? My guess is that this is closely coupled to the switch to TeleAtlas data for the geocoding API a couple of weeks ago. For years maps.google.com and the API were using different datasets for the geocoding. The google apps were using TeleAtlas whereas the APi was using Navteq. I once was told by some Google engineer that this was due to the unwillingness of TeleAtlas to license its data for API use. Don’t know if that is correct, but now that the API is using the TeleAtlas data they might also have struck a deal to use reverse geocoding data.
P.S.: I’m attending the Google Maps Premier workshop in London on Nov. 7th. Anybody else? And does anybody happen to know a swing component that integrates a decent browser engine (e.g. Webkit, Gecko) into Java Apps running under Window XP?. Right now we are with an IE component.