Semantic Web at Opera

"Things should be as simple as possible, but not simpler" -- Albert Einstein

I'm happy that quite a few people have mapped their tags, more than I expected! Now, many things are somewhat complex by their very nature, sometimes you have deal with complexities to make things that are useful. And even more often, the question is who or what should deal with the complexities. When I created the tag mapper, I realised that there would be conflicting goals, and now I'd like to discuss them with you:

For some terms, you will see that there is a dropdown under "Relation" that contains both "topic" and "depicts". The "depicts" is there when the term is a noun, and the idea is that when a tag is used for a picture, then you can say that the picture depicts a dog, for example. So, it is a way to very directly express that meaning.

Doing it this way would also create really simple SPARQL queries, to get all pictures that depicts a dog would amount to (ignoring the namespaces):

    SELECT ?pics WHERE { ?pics foaf:depicts <http://www.w3.org/2006/03/wn/wn20/instances/wordsense-dog-noun-1> . }

That's about as simple as these queries get.

Also, as I mentioned, the plan is to use tags for content labels, and since I'm Opera's representative on W3C's POWDER working group one of my main concerns is how people can easily tag their content with content labels on sites like Opera Community. Again, the easiest would be if a content label could be directly associated with a picture. For example, we have to live with a certain amount of nudity in the pictures our users upload since we don't want to exercise censorship, we just don't want to push it on random visitors, and we want to facilitate parental control, and that's one of the things content labels will be used for: A standard way to say that a picture contains nudity.


This is made possible by a slightly more complex user interface. Arguably, it would be easier to just map your tags, not also having to decide if it depicts something, or if it points to a content label. If we didn't do this, it would be harder to formulate the SPARQL queries, but more importantly, this would only be the beginning, since you're clearly using the same tag not just for pictures, but also for blog posts, and you wouldn't say that a blog post depicts something. So, for this to really work, we would need different relation types depending on the type of resource, whether it was a picture or a blog.

That's where it gets nasty.

So, I'm wondering if the course I've started out on is unworkable. Perhaps the relationship from a tag to a term like the Wordnet terms should be unchangeable? That would make the user interface simpler, but the queries and other uses would be harder. So, it isn't just a question what's the simplest, rather, it is a question of who should deal with the complexities.

Now, it is important that as many as possible to participate in tag mapping. Not everyone needs to write applications or queries that uses these data, so those wishing to do so are probably better suited to deal with the complexities than all those seeing the tag setup page. On the other hand, it is quite important to make the POWDER specification quite simple too, and this use could add complexity to the specification.

So, your opinions will matter here, please bring them forward!

Then, you might ask, dear guinea pigs , why I made a complex user interface to begin with, and then ask if I should make it simpler? Well, clearly, I couldn't start discussing this with you if I didn't show you a complex user interface that worked, it would be much harder to explain what I had in mind. So, I figured I might as well do a little research on you. The experiences gain from this is something that will be used to make the right decisions when designing important standards that will be with us from many years to come, and I feel it is important to get this experience now, before those standards are set.

There has been many urgent matters that we have attended to upgrading the Opera Community, and therefore, the SPARQL engine fell into neglect for a while, but that was only temporary! It is now back up, with 15 million triples. Be warned however, that not all data may be there, even though it has grown substantially. Also, it is now too big to build the way it has been built in the past, so it needs to be rewritten, which will take some time to do. Thus, it remains an experimental service for now.

Since the launch of the Opera Community in September 2005, all members of the community has had an URI identifying them. Having URIs for everything is important, and even though you can't be retrieved over the network the URI is useful to identify you as a person.

Furthermore, we know that Cool URIs don't change, but I'm afraid I just changed them... You see, the final, little part of the URI I gave you was very badly designed. It had a lot of unnecessary complexity, and with complexity comes bugs, and in fact, it turned out that some of them weren't even valid, since I hadn't taken into account that some usernames begin with a number.

It wasn't with a very light heart that I changed the URIs, but as I discussed this with other members of the FOAF community, it was clear that it was better to do it now, and deal with any problems that may occur with a process known as smushing, than dealing with the complexity that I had, especially as more people start using the URIs for real applications.

For most users, this change will not mean anything. The usual FOAF tools continue to work, it is only if someone has been indexing the URIs it will have any impact. I don't know if anyone has been doing that, but I would be interested in hearing about it!

UPDATE: I was a bit uneasy about this, so I found a way to at least attempt to unbreak most of the URIs, by using the sameAs property from OWL on those valid fragment identifiers from the previous version. That should give us the best of both worlds!

This is the opening post of the Semantic Web blog here at Opera. The Semantic Web tries to extend the Web by the development of new frameworks for sharing data between applications and there is a number of people at Opera interested in this development. In this blog, we'll share some of the ideas and keep you posted about the development we do.