Rod Petrovic

I just posted this comment on Twitter annotations over at Marshall Kirkpatrick’s blog. Thought I’d share it here, as well:

As many have already mentioned, semantic web standards and Linked Data are the way to go for Twitter annotations and I can hardly hide my excitement.

Twitter’s annotation format (tweet – namespace + key – value) fits perfectly within an RDF triple (subject – predicate – object). By embracing semantic web standards, Twitter wouldn’t lose anything, while it could definitely gain a lot.

Two major points, IMHO, why Twitter would benefit greatly from the Linked Data approach:

1. It is standardization out-of-the-box. Standard vocabularies can be used, so annotations can be easily reused by other parties, even outside the Twitter context. For example, if a Twitter application annotates tweets with foaf:homepage, other applications can be 100% sure what that means and how they can reuse that piece of information, as FOAF is an open, documented vocabulary. On the other hand, if everyone invents their own undocumented annotation formats (abc:xzy), reuse will be difficult at best.

2. It is already supported by a large community and the W3C. This could cause a huge influx of fresh ideas into the Twitter API community. There are already many smart people in the Linked Data community that have been testing different ideas for almost a decade now, but have lacked a real-world platform where their ideas could be applied. Twitter could become this platform.

The standardization of metadata on the web is a problem already solved by W3C and Twitter shouldn’t bother themselves trying to solve it all over again. I think they have an opportunity here to push Linked Data into the mainstream and become its first “killer app”, which is something that many of us have been waiting for.

• Rodoljub: What's the secret to life?
• Aardvark: Oops -- I'm not able to find an answer to a question that short!

An interesting debate was sparked over at Hacker News about my beloved jQuery.Behavior library. Some people are asking perfectly legitimate questions about why they should use behaviors when they can use X or Y. The main competition seem to be custom events in jQuery and extending jQuery. Let me try to tackle those.

Joel Sutherland posted a link to this good writeup about custom events in jQuery. This is an example of encapsulation from that blog:

$('.lightbulb').bind('changeState', function(e) {
  var $light = $(this);
  if ($light.hasClass('on')) {
    $light.removeClass('on').addClass('off');
  } else {
    $light.removeClass('off').addClass('on');
  }
});

For starters, I’m sorry but this makes more sense to me (and it’s plain old JavaScript):

function LightBulb(element, config) {
  var self = this;

  self.state = false;

  self.changeState = function () {
    if (self.state = !self.state) {
      $(element).removeClass('on').addClass('off');
    } else {
      $(element).removeClass('off').addClass('on');			
    }
  }
}

$('.lightbulb').behavior(LightBulb);

Unlike with custom events, you can access properties from anywhere because LightBulb here is actually a class and this behavior is an instance of that class:

$('.lightbulb').behavior().state;

My point is: Custom event handlers are functions, not objects, which is why they suck at helping me organize my code into logical parts. Then again, I don’t think they were ever meant to do that.

As for extending jQuery with “behaviors”:

$.fn.mybehavior = function () { ... }

You can try to implement each behavior as a jQuery plugin and then somehow try to get them to interact with each other… but you’ll probably end up right where I am: asking yourself why you should not invent a standard way of doing that and then stick to it.

The client will always want to pay as little as possible and get as much as possible. If they so much as smell an opportunity to fit more features into their budget - don’t worry - they’ll invent some more.

The vendor will always try to sell as little as possible for as much as possible. They’re no fools. They might lower the price but they know there is a minimum that the client can live with, so they’re going to try to cut their development costs by compromising quality.

The developer will hate his job because he will always have to waste his talent developing crappy products with stupid features. Because of that, his productivity eventually hits the floor and the result of his work ends up being more expensive for the vendor and less satisfying for the client.

So how to avoid this? Persuade the client to be realistic about the budget and features. Persuade the vendor to value the quality of their products more than money. Buy developers better coffee.

Things definitely do change. This is a 100-year-old picture of the street I was born in (the one on the left). It’s very amazing if you know what this looks like today. Credits go to http://unkool.wordpress.com.

An acquaintance of mine, Andrej Nabergoj, started a Facebook group today called “Slovenia 2020” (as well as a Twitter account and a Noovo group). His goal is to gather ideas from young people from Slovenia about what they wish their country to be like in the year 2020. This inspired me.

I believe my view of Slovenia is somewhat original. I am a foreigner who lives in Slovenia. However, unlike the vast majority of foreigners who live here, I feel positive about Slovenia in the long run. I don’t feel I’m here temporarily but I’m also not under pressure to stay due to financial, career, family or similar reasons. I speak the language because I wanted to learn it and not because I needed it. I listen to some of the local music because I think it’s good. On the other hand, I’m nothing like the Slovenes. Firstly, as I just explained, I chose Slovenia, whereas they had no choice - they were born here. Secondly, I have experience living in a different environment, which makes it easier for me to see more clearly both the good and the bad in Slovenia. Especially the good.

But the idea of “Slovenia 2020” is to suggest solutions for the bad, so here are my words of wisdom to the future Slovenian government:

Open doors for educated, talented, young people from abroad. Loosen the immigration laws for them. Don’t make them wait for 10 years to become citizens. Let them bring their families with them. If someone is a talented professional in a field that has potential for growth, make clear, legal distinction between that individual and a guy who wants to pave local roads for a few years. Throw a red carpet in front of those people and make them feel more welcome in Slovenia than any other country in Europe. If you want to know what happens when you do this, take a look at the United States or Ireland. Slovenia is small but it should never be too small for smart, ambitious people.

Fanatically invest into higher education. It wouldn’t be a sin to raise taxes on student salaries and cut subventions for student meals, if it means investing more into quality of education. What Slovenia needs is more graduates and less students. It needs better schools that will produce better experts and attract more foreign students. Most older professors have inadequate teaching experience from an obsolete educational system. They should be retired and replaced by younger ones, as well as professors from abroad. English should become an optional language of instruction in a majority of University courses. Reforms in higher education should be much faster than they are now and they should go beyond EU conventions. Slovenian higher education shouldn’t just match that of other European countries - it should top them.

Make it OK to be rich in Slovenia. Slovenia is the most taxed nation in the world. It’s a small country so high taxes are somewhat expected but that’s still not a good enough reason to choke areas of the economy that have potential to grow. I’ll shamelessly take IT as an example: How can you expect the next Skype or Last.fm to come from Slovenia if a senior web developer is cheaper to hire in Western Europe than in Ljubljana? Lower the taxes for such professions. Letting people in branches such as IT, pharmacy or green tech become rich more quickly will only lead to influx of more capital and a faster growth. Make those exceptions. The market is not fair and neither should be you. Don’t be socialist about it.

An extra advice: Get over the complex of “a small country under the Alps”. Ditch this image. Work on a new, more ambitious one. Who ever said Slovenia can’t be one of the leading countries of the old continent? Why shouldn’t it be? Our per capita GDP already surpassed that of Portugal and Greece and we’re not even trying. It’s bound to surpass Italy’s in a few years and maybe even Spain’s. Why shouldn’t Slovenia become the most developed country in Europe by 2020? Does this sound too pretentious to an average Slovene? Yes, and that’s exactly what needs to change. Slovenia needs an ego-boost on a national level.

• rodpetrovic: Adding a developer to a late project makes it later, right? How about adding 2 developers?
• lexandera: Add new developers to other people's projects. Make them late instead.
• rodpetrovic: And help our project by taking an early vacation?
• lexandera: I wonder if that law does indeed also work in reverse. Try removing all the devs. The project should be finished immediately.

An average car can have as many as 3000 parts. It is a complex machine. Metaphorically speaking, if each line of code in a computer program consists of several “parts”, designing a modern software application could be considered much more complex than designing a car. Sure, parts are less expensive, but the knowledge of how to put them all together is not. Furthermore, a car’s “user interface” is usually much simpler than an average software application’s user interface, disregarding, of course, that its usage might be considered more dangerous.

In my career so far, I’ve worked with many developers. As every industry needs the right mixture of people in order to function, I’ve identified several different types of developers. I believe that every software company should employ each of these types. Just for the fun of it, I will describe them in the context of car industry:

Constructor. This is the guy with the big picture. The architect. He will design the car according to requirements and take pride in drivers’ satisfaction, as well as satisfaction of all the mechanics who will have to maintain and fix the car for years to come. The constructor might not be a good driver and he might not even enjoy fixing cars. Nevertheless, he is the visionary behind the product.

Mechanic. This is the guy who can fix but also improve the car. He takes the constructors’ design and tweaks it beyond sanity, making it even better for the driver. He takes pride in performance.

Race driver. This is the power user. He may not know how to design or even fix the car but nobody can drive it better than he does. This is the guy who will show the car’s real worth by taking it to the finish line. He takes pride in the result.

Taxi driver. This is the guy who can drive, but only does it for the money. He doesn’t care about the car’s design or its maintenance. He may hate his job or he may enjoy it but, at the end of the day, it’s just a job he knows how to do, so he does it, waits for his shift to end, collects his paycheck and then goes home to his real interests.

Some developers are architects who design state-of-the-art sowtware. Others are hackers who can improve that software making it perform even better. Some developers achieve unimaginable goals using the software, while others will just do their little chores and go home.

I don’t know if you got my crazy metaphor but, if you did and if you are an IT manager, try to identify these 4 types of developers within your team and it will be much easier for you to organize them.

Whatever it is, it’s good to be home.

After my previous post, Jamie Taylor of Metaweb was kind enough to e-mail me with more details about the Common Tag vocabulary, as well as their point of view (thanks, Jamie).

He pointed out the property ctag:isAbout, which is currently not advertised in the specification but is present in the vocabulary. This property supports exactly the kind of minimal, rel-tag-like tagging that I was talking about in my previous post (but used an imaginary property instead). The property’s domain is another class defined in the vocabulary: ctag:TaggedContent. While I argued that the domain of this property could very well by any resource (rdfs:Resource), Jamie explained that ctag:TaggedContent was not a restriction on the property, but rather an inferred type for systems that might care. Good point.

This certainly was a refreshing discovery. However, one major worry still remains.

It became obvious that the Common Tag vocabulary actually contains two separate standards. One of them, obviously preferred, is putting a mediating object between a document and a concept. The other one, currently hidden at the bottom of the vocabulary, is offering direct, “shallow” tagging through a single property. These two are not logically compatible out-of-the-box, as they result in different RDF graphs. Systems will have to be aware of their compatibility and enforce a rule that would automatically generate ctag:isAbout statements for each ctag:Tag resource and vice versa.

As Jamie explained, during the process of designing the initial Common Tag standard, they have been in touch with many publishers and clearly identified the need for a mediating object. I’ll take his word for it.

However, if direct tagging wasn’t enough, I think it shouldn’t have been added to the standard in such a way that it represents an alternative. It sounds more reasonable to let direct tagging be a minimal option and a mediating object an optional extension. This means that we could easily ditch the ctag:tagged property and its range restriction and just use the more flexible ctag:isAbout. This way, we can reference a concept directly or, optionally, reference a ctag:Tag resource, which serves as a representative of a concept.

Nevertheless, I still think that the main purpose of this standard can be achieved with direct tagging only. If I try to imagine how I would like to process the resulting RDF graph, I don’t see much use for ctag:Tag and the two properties in its domain. Quite the oposite - I think they unnecessarily complicate the graph and bring very little added value for the price of greater complexity.

Metaweb and other supporters of the standard were right to focus on the publishers. They are the ones who need to adopt the standard first. However, another important target audience are the developers, who will want to build innovative services based on Common Tag. While publishers appreciate expressiveness of the standard, developers appreciate simplicity. I guess I am a developer.

As you might have read yesterday, the Common Tag format is out. It is an RDFS vocabulary that supports semantic tagging of documents using concepts from DBPedia, Freebase and other publicly available vocabularies. Common Tag is initially being backed up by several companies, including Yahoo.

The standard will definitely find its usage inside the Linked Open Data cloud. While I prefer the vision of Semantic Web, where we expose structured data in databases as SPARQL endpoints, I must admit that the ever-growing textual web, represented mostly by the blogosphere, definitely needs an elegant way to organize itself and semantically enrich its content. An approach to have a simple, common standard for semantic tagging seems like an ideal way to do so.

But to be successful, this standard has to be well accepted within web publishing and web development communities. These communities, however, have been known to label Semantic Web efforts as too complex for end users. Unfortunately, the Common Tag specification doesn’t look too promising in this department either.

Benjamin Nowack was quick to notice this today. I must say I agree with him. As a big fan of semantic tagging, I’m afraid this standard might miss a great opportunity to push semantics into the mainstream, again, due to complexity issues.

Besides the obvious naming convention problem, the main thing I disagree with in the Common Tag vocabulary is the logic. To me, a tag is a relation between two web resources: a document on one side and a concept on the other. Nothing more. The Common Tag specification defines a tag as a separate resource, so you don’t tag a document by some concept directly but by a new resource of type ctag:Tag, which references that concept. As Benjamin points out, this complicates the resulting RDF graph for no good reason.

Judging by the specification, the only reason to introduce the ctag:Tag class is to attach two additional properties to a tag: ctag:label and ctag:taggingDate. Unless I’m missing something really bad, I don’t see why these two properties are necessary at all. The concept being used for tagging can already have a label through rdfs:label. Even if publishers or readers want to label the concept differently, they are free to do so using rdfs:label. The document being tagged can already have creation date information through dc:created. I really see no benefit in having creation date information for each individual tag, as well. Applications that might need this kind of information can keep it internally or introduce additional vocabularies, so there’s hardly a reason to complicate the standard, especially in its earliest version.

In short, I think the Common Tag vocabulary would be better off with only one property: ctag:tag, for example. The RDFa markup could be as simple as this:

<a rel="ctag:tag" href="http://dbpedia.org/page/Semantic_Web">Semantic Web</a>

Such simplicity in an early draft of this standard would surely be a powerful message to web publishing and web development communities.

Besides tagging, the Common Tag specification implements a simple trust mechanism. It extends the main ctag:Tag class with three subclasses: ctag:AuthorTag, ctag:ReaderTag and ctag:AutoTag, for tags that were created by document authors, readers and automatic algorithms, respectively. I like the idea but I still think the same could be achieved with a single property for tagging (e.g. ctag:tag) and three subproperties (e.g. ctag:authorTag, ctag:readerTag and ctag:autoTag).

iPhone has only one button. One. How many other mobile phones have one button? How about Google search? It’s pretty much a single text box. Its homepage isn’t cluttered with news, banners and category links. Are you impressed with 37signals’ success story? A company of less than 10 people builds the world’s most popular project management tool. How do you figure they made it? Certainly not by putting a Gantt chart in it.

Throughout my career, I’ve been working with clients that are as impressed as I am by products such as iPhone, Google or Basecamp. However, when it comes to achieving simplicity in their own products, the vast majority of them falls short. Some of them miss the point by miles, usually thinking that a glossy design is all they need to have a great product. Some of them, however, understand that truly great products are the ones that lack features, rather than have them. Nevertheless, they, too, eventually tend to clutter their products with every feature imaginable.

I don’t blame them, though. Adding a feature is only a question of time and money. Removing a feature takes courage. Excuse my Serbian, but deciding what feature your users can live without takes balls of steel.

I’ve seen this so many times. At the start of a project we’re looking at Apple or Google or 37signals for inspiration. However, down the road, when we’re put in front of a choice of having or not having a certain feature - we get scared. Suddenly, keeping that feature feels more comfortable than letting it go.

Is a small, boring, textual link enough or do we need a big, colorful, teaser image? Should we hide it by default or do we show it just in case our users overlook it? There are people who get scared and chicken out once presented with questions like this. And then there are Steve Jobs, Larry Page, Sergey Brin, Jason Fried, …

As you might have noticed, most of the successful people in the world don’t have an IQ of 200. Then you’ve read tons of blogs, articles and books on the subject of succeeding, all of them preaching that dedication, rather than intellect, is what it takes to be successful. I don’t have a major problem with this theory, but I do know a lot of dedicated people who are not insanely successful.

The most important thing to consider, whilst figuring out why aren’t you successful already, is this: When you do use your brain cycles, how do you use them?

I don’t think most people aren’t dedicated. They are, but to the things that might not lead them to anything new or original. What are you thinking about most of the time? Sports? Boring old job? Partner? Some of these things are surely socially accepted ways of using your brain. However, if you’re not thinking about new ideas too much… well, don’t be surprised if you never get any.

We’re all cannons - it’s just that most of us are shooting flies all day long.

This post, of course, is a self-critique.

Both inspiring and freaky.

While my car was being serviced this morning, I had no better things to do than to write a lightweight JQuery plugin for creating slideshows - something that a colleague of mine needed yesterday. The ZIP file contains the JS file and an example. Tested with JQuery 1.3.1 but should work with 1.2.*, as well.

For years I’ve been reading about and listening to misconceptions and wrong ideas that people have about Semantic Web. Times have changed and the concept of “the web of meaning” is starting to come alive. However, it still seems to me that many people keep missing the point. So here is the list of my favorite misconceptions about Semantic Web that I somehow keep coming across.

Semantic Web is just another buzzword
Of course it is. So? I fail to understand people that seem to lose their hair every time they hear “marketing terms” like “Web 2.0”, “Web 3.0”, etc. So what if markets have a need to label clearly identifiable trends? Call it “Susan” if it makes you happy but it still is the same technological trend and it wouldn’t be any different even if it didn’t have a label.

Semantic Web takes a lot of work
People somehow seem to think that, in order for Semantic Web to work, we all have to spend days and nights semantically annotating existing web pages. In reality, Semantic Web doesn’t require much physical effort at all. Physically, all it is is just another way to output the data that we already have stored somewhere, usually in databases. Besides HTML, which we feed to humans, we’ll just show RDF and feed it to machines, making it easier for them to understand what the heck it is that we’re talking about in our content. The effort is not physical, it’s economical. The companies that own the most of the data that’s worth processing are doing fine as it is (read: Amazon, Ebay, Facebook, etc.). They need incentive to agree on a mutual standard and open up their data to the world. They need a reason that ends with a $ in order to replace their current APIs with SPARQL endpoints. At the moment, they don’t seem to have one. You think they never will? The same used to be predicted for RSS and look where it is now.

Semantic Web is AI
Well, not the AI you’d most likely imagine. It might become that AI one day but it certainly isn’t going to be too intelligent soon. And it doesn’t have to be. All it should do, for starters, is give machines something better to process than just text. Let me search the whole web for a new car by giving you a make, a price range and my location and I’ll be as happy as a kid in a candy store. No need for NLP. No intelligent software agents required for now.

Semantic Web requires huge, complex ontologies
This is usually related to the previous misconception. First of all, Semantic Web doesn’t require ontologies at all, although it would be nice to have some. Second, ontologies don’t have to be either huge or complex in order to be useful. It’s enough to have simple standards - ontologies that define a couple of simple properties that can be used to search data. That’s all we need to start with. We don’t even need OWL. RDFS will do just fine for now. Actually, even the word “ontology” sounds too scientific. I’d rather go with “vocabulary”. It’s easier on the ears.

SQL is better than SPARQL
It might sound strange but I actually heard this one a couple times. Here’s a quick metaphor: Comparing SQL to SPARQL is like comparing live speech to e-mail. They both serve the same purpose (communication) but although one might argue that speaking directly to someone is more effective than having to type them an e-mail, the context changes a little bit when two people are 3000km apart. It’s the same with SQL and SPARQL. I may love SQL if I have tables in a relational database but it doesn’t do me much good if I want to query web services for RDF.

Why do we need Semantic Web when we have Google?
Google does a great job in a field called text mining. Not so much in another field called knowledge representation. While it’s great for finding web pages it sucks at finding data. Type in “rod petrovic” in Google and you’ll find my homepage in a fraction of a second. But try to find out how old I am and you’ll have to spend some time reading web pages yourself in order to find that piece of information. That’s because Google doesn’t seem to have a clue what birthdate is. Just because it’s the best tool we have (and thank God we do), don’t assume things can’t be done much better.

Semantic Web won’t happen
I hear this less and less but there are still some people, web professionals even, that believe this. Yes, it will happen. It’s already happening. It’s only a question of how fast and in which forms will it keep happening. What other direction should the web move in, anyway? I do notice, though, that some people tend to cling to statements like this out of fear of having to learn something new. Have no fear - Semantic Web is as simple as it is necessary.