Will Adobe still support SVG?

I am scared by the new alliance between Adobe and Macromedia. What will happen to SVG after this merger? Some critics are already foreseeing the wonderful integration of Flash and SVG to form a new standards-friendly product. And while it is true that Adobe was a strong supporter of SVG, that was only because they needed something to match the popularity of Flash.

Flash is a proprietary product but it has a much larger installed user base than SVG. And now that Adobe owns Flash would it make any sense to push for an open standard? Well, I think they won't. It would be no surprise if Adobe drops support for SVG entirely and focuses on providing a better Flash solution that could monopolize the whole market. Under these circumstances the Adobe SVG Viewer, the best available SVG viewer (maybe excepting Batik Squiggle) might not have a future at all and this could be a big setback for SVG.

The recent adoption of SVG by two major web browsers (Opera 8.0 and the upcoming Firefox 1.1) is most encouraging. Although the implementations will not be perfect right from the start, they will surely improve over time and they could counteract any move from Adobe. At least that is where my hope is.

Sketsa is only getting better

Sketsa 3.1 is now out and comes with many important improvements. I have watched the development of this excellent SVG editor over the last couple of months and I must say that the developers from Kiyut never failed to impress me.

First of all, Sketsa is the most standard friendly SVG editor I have worked with. I use it to post-process UML diagrams exported by uml2svg and Sketsa is the only tool that rises to this challenge. But, even though it has made a good impression on me right from the start, there were still some problems that needed to be fixed, like the poor support for grouping and several glitches with text handling. What I did was to provide constant feedback on the areas that needed improvement and is was a pleasure to find out that the developers of Sketsa are very receptive to suggestions, they have a tendency to respond fast and fix things right away.

The new Sketsa 3.1 comes with much better support for ungrouping, an enhanced DOM Editor, a more accurate Lasso Tool, and many other improvements. If you are serious about SVG editing you should give it a try.

Folksonomies vs. Ontologies

According to Wikipedia a Folksonomy is a the practice of collaborative categorization using freely chosen keywords. Folksonomies offer an alternative to classification using ontologies that is more flexible and scalable and is therefore well suited for collaborative categorization by non-professionals.

Although ontologies are widely used to classify the information we posses about world, they are not flawless. Some people think that in the context of the Web the very purpose of ontologies (classifying objects into classes) is flawed. Clay Shirky has a recent interview on ITConversations entitled "Ontology is Overrated" on the topic. In my view everyone attempting to build a general ontology runs into a major problem: some concepts can be classified in different ways according to the expected use. Is Australia a continent, a country or a rugby team? No matter which of the classes is chosen there will be some users that will find the classification arbitrary. This is one reason why directory services (not only tools like LDAP, but also web directories like ODP and even file systems) offer the possibility to add aliases (symbolic links) between related categories that are part of different subtrees. While this could solve the classification problem in many of the cases, the amount of links that one has to add can be restrictive.

What the folksonomies do is completely renounce to the hierarchical relations. Metadata is attached instead to each object in the form of tags (labels). A major advantage is that an object can have an arbitrarily large number of tags. Related tags can be determined automatically and used to increase the accuracy of the searches. Moreover these tags are added by the users themselves and not by experts. So it is the users that create metadata for their own individual use that is also shared throughout a community. Two such communities are Delicious and Flickr. Delicious allows users to store and share bookmarks while Flickr does the same thing for photos. Because the users can add any tags they like this is a very flexible way for users to organize their information. But things don't stop here because the real power of folksonomies comes in when the supporting community grows large enough. Not only the categorization is usually comparable to that made by experts but the resulting system is much flexible and the advanced search capabilities are almost limitless. Although folksonomies are just beginning to become popular at this time, the idea behind them is very simple and interesting. They surely deserve further investigation.

For a more in-depth introduction to Folksonomies Adam Mathes has a very interesting article entitled "Folksonomies - Cooperative Classification and Communication Through Shared Metadata".

Upcoming EJB3 persistence could replace JDO

JDO is a fairly good solution for standard object persistence that offers portability across data storage paradigms and products. JDO has the ability to transparently persist graphs of objects including inheritance and implementation hierarchies, in a way similar to an ODBMS but with the advantages of a standard API and a pluggable (potentially non-object oriented) data store. Despite this JDO is not flawless and it failed to achieve widespread support from the large database companies. The final blow came from SUN itself under the pretext that the existence of two different data persistence models in EJB and JDO caused confusion and debates among Java developers, and is not in the best interest of the Java community. A letter from SUN states that maintenance improvements of JDO are still possible but the future standardization efforts will be towards a single POJO (Plain Old Java Object) persistence model under the tailoring of the JSR-220 Expert Group (EJB 3.0).

So if you are already using a JDO product you can safely continue using it, at least until the new EJB3 is adopted and you could make a migration. On the other hand if you are developing a new product you could have a look at the EJB3 persistence specification early drafts. Hibernate (http://www.hibernate.org) already provides support for EJB3 annotations in their 3.0 release. Either way Sun has a FAQ on persistence issues you might want to read.