Not that anyone would ever mistake me for a query language guru, but that’s really part of the problem; I’m not a query language guru, because I’m a Web guru, and to a certain extent those two roles are incompatible.
The Web doesn’t do generic query, and it’s a better large scale distributed computing platform as a result. The cost of satisfying an arbitrary query is too large for most publishers to absorb, as they do when they internalize the cost of operating a public Web server and answer GET requests for free.
The Web does per-resource query, which is a far more tightly constrained form of query, if you can even call it that. It makes use of hypermedia to drive an application to the results of a query without the client needing to perform an explicit query. Think of a Facade in front of an actual query processor, where the user provides the arguments for the query, but has no visibility into the actual query being performed. FWIW, this isn’t an unfamiliar way of doing things, as it’s how millions of developers use SQL when authoring Web apps; a user enters “30000” in a form field, hits submit, and then some back-end CGI invokes “select name, salary from emp_sal where salary > 30000”.
I’m confident that SPARQL will be used primarily the same way SQL is used today, and that you won’t see many public SPARQL endpoints on the Web, just as you don’t see many SQL endpoints on the Web. There’s nothing wrong with that of course, but I think it’s important to keep our expectations in check; SPARQL is likely not going to enable new kinds of applications, nor help much with multi-agency data integration, nor do much else that doesn’t involve helping us with our triples behind the scenes.
Following up on my finger-wag at Google for not properly supporting mashup developers by messing up versioning, I have to now send them full props for one thing they’re doing very, very, right.
One half of Postel’s Law says “Be liberal in what you accept”, and Google has done exactly that in at least two places. First is in Google Maps, where you can enter pretty much anything resembling a street address, and more often than not it’ll grok it. That’s not to suggest it couldn’t be improved mind you – about a quarter of the time I probably have to refine what I enter, but still, that’s not bad. Without this capability, Maps mashups would be a lot more difficult to develop in part because there exists no widely adopted standard format for an address, leaving prose as the only option for interchange. By doing this Google is absorbing the costs of solving the problem, and relieving mashup developers of the burden. Quite the contrast to their API versioning policy! 8-O
Another example of this I’ve noticed is Google Calendar, where it can accept dates also in prose, even relative ones like “tomorrow”. And this is despite having somewhat decent time and calendaring standards. So why the prose? It just simplifies integration, as the calendar integration with GMail demonstrates; it can pick out dates from an email without requiring the sender conform to any particular standard. Actually, I don’t know if that’s GMail or calendar doing it, but I hope it would be the calendar so that it can be more easily reused in other calendar-integration scenarios.
FWIW, I recall Peter Norvig saying something in his recent highly publicized run-in with TimBL about the value of this approach (mining existing content) over authoring new content; just can’t find the quote I’m looking for right now, but I’ll add it when I do.
How did I miss this (via Nelson)? I even asked for it!
Tech Crunch reports on a cool new service from Meebo, called Meebo Me, which allows people to embed a (flash) app in their pages which permits a one-on-one dialog with the owner of the page via Meebo. Neat-o. I thought I saw something like this a while ago, but whatever… It was a snap to setup, so that’s what I did as you can see on the sidebar (if you’re at my page). Hmm, would the universe explode if I included the app in my feed? 8-).
I’m already seeing a bunch of “meeboguest” users appear and disappear in my meebo window (hmm, it’s a good thing I’m not an A-lister!), presumably as folks visit my page then close their browser window. It also appears that I don’t have to wait for them to contact me – that I can, at my own discretion, send a message to them.
It seems that this Web thing will never grow old.
Update; I suppose a downside to incoming messages is that they’re anonymized by default and therefore only usable in the context of that session. So if you leave me a message, I can’t get back to you if you close your browser window … unless you de-anonymize yourself by setting a meebo username.
I previously pointed to the announcement of the shutdown of a version of the Google Adwords API, and commented that this really isn’t the way to go about versioning your Web 2.0 APIs.
I’ve been digging into Google Maps recently, and noticed that they’re making the same mistake;
The v=2 part of the URL http://maps.google.com/maps?file=api&v=2 refers to “Version 2 ” of the API. When we do a significant update to the API in the future, we will change the version number and post a notice on Google Code and the Maps API discussion group.
After a new version is released, we will try to run the old and new versions concurrently for about a month. After a month, the old version will be turned off, and code that uses the old version will no longer work.
Obviously we’re still pretty early into the whole “mashup” thing, but not too early that we shouldn’t be thinking about best practices IMO. And best practice #1? Don’t do what Google’s doing here, which is asking all their users – mashup developers who have committed themselves to this service – to absorb the cost of their inability to develop an extensible API.
I think a good rule of thumb for service providers is to assume that you’ve got a million mashups using your service, and therefore that the cost of incompatible changes is prohibitive for the mashup developers. Any other approach is sure to drive those developers to other service providers who do a better job evolving their APIs; bad juju if your business depends on attracting eye-balls.
So what constitutes a “better job”? I suggest it has something to do with declarative Javascript, but my argument needs some work so I’ll save that for another post.