cygri’s notes on web data

Over at Read/WriteWeb: Mozilla Does Microformats: Firefox 3 as Information Broker

The comments are interesting too.

O’Reilly Radar: Google Deprecates Their SOAP Search API

They don’t switch it off yet, but there will be no more support, no more bugfixes, and no more new API keys.

As a user of the SOAP API (I use it to, uh, automate the tedious task of egosurfing), I think this is a real bummer. Google says we should use their AJAX search API instead, but like all AJAXy offerings, it is nice for front-end integration but useless for server-side stuff and scripting.

I wonder what this means. Apparently the expected business value of such an API didn’t materialize for Google. And the web services community loses their poster child example. Some people seem to think this spells the end of SOAP, which I think is nuts — the fact that the API uses SOAP certainly didn’t have anything to do with Google’s decision.

On the bright side, this means my next toy project that needs a search service will use a REST-based offering.

Jukka Villstedt’s Kaivo now has a website. It’s a GUI prototype for navigating and editing RDF-like data and subject of Jukka’s master’s thesis. Similar to Tabulator, Kaivo displays graph data in an outline form. But unlike Tabulator, it can be configured to display nodes within the outlines as tables that afford much quicker scanning and sorting. Tables can also be nested. The display is compact. And the whole thing looks damn slick. There’s a whole bunch of screenshots.

Displaying arbitrary RDF in a usable way is hard, and I think Kaivo shows quite an interesting direction.

Sean B. Palmer on #swig:

I wonder if it might be a good rule of thumb to “reuse properties until it hurts; and then change”, in order to propel the property consensus that’s meant to be such a central feature of the Semantic Web

Spot on.

(Credits for the title go to danbri)

Andy Seaborne announced yesterday that he is working on a SPARQL algebra for inclusion in the spec. His current draft is here: SPARQL Algebra.

I have criticized SPARQL’s lack of a formal semantics before, and I’m glad to see the working group addressing this.

Andy’s draft is based on the “compositional semantics” introduced by Pérez et al., with some tweaks to better account for FILTERs inside OPTIONALs. I think that’s an excellent choice, a good compromise between meeting user expectations and straightforward implementation on relational stores.

The downside is that the semantics of some queries change. This is bad news for early adopters. The changes will affect implementers because they have to tweak their code. Users will not be strongly affected as far as I can tell, the semantics of all the most typical kinds of queries remain identical. No need to worry, unless you have nested OPTIONALs or FILTERs inside OPTIONALs.

The second downside is that SPARQL, which already was in the Candidate Recommendation stage, will remain a moving target for some time.