Ubuntu karmic, Thunderbird 3.0 beta/Shredder and Enigmail

I’m using Shredder aka. Thunderbird 3.0 beta now for a while and think it’s the best mail client I used so far. I sign all my mails with gpg and sometimes use gpg encryption. However, after my update to karmic (the beta, yes I know, quite a lot of betas), however, Enigmail failed to sign my mails. Interestingly, verifying signatures worked, but signing/encryption did not. The error message was long, telling me that gpg-agent was not able to query the passphrase:

gpg command line and output:
/usr/bin/gpg --charset utf8  --batch --no-tty --status-fd 2
--keyserver-options auto-key-retrieve --keyserver pgp.mit.edu -d
gpg: problem with the agent - disabling agent use
gpg: can't query passphrase in batch mode
gpg: Invalid passphrase; please try again ...
gpg: can't query passphrase in batch mode
gpg: Invalid passphrase; please try again ...
gpg: can't query passphrase in batch mode

After some googling I found a rather radical solution, that, however, solved the problem. I deinstalled gpg-agent, seahorse, and gpgv together which a large amount of packages that are probably quite important for a working system. Then I reinstalled just ubuntu-desktop. And voila, it worked. So, should you experience any problems in karmic with Thunderbird 3.0/Shredder and signing/encrypting mails, maybe try the same trick.

How many axioms would you like?

I’m currently working on the formalization of our new Multimedia Metadata Ontology M3O. It used Descriptions and Situations as one core pattern, along with information realization and the data value pattern (at least we termed the representation of plain data values in DOLCE Ultralight like that). While it is pretty simple to come up with many axioms that I could add, I question myself how many I want to add.

As an example: Currently we have D&S based patterns where the description defines a number of concepts that determine the roles of the participating entities within a certain context. Each concept might only classify exactly one entity. We need this property of the patterns in order to assure that no ambiguities arise in the real data. My idea was to add super concepts like M3OConcept, among others, in order to formalize these basic properties. For instance, I would formalize that M3OConcept = classifies exactly 1 Entity and classifies only (Entity and hasSetting some M3OSituation). What does this give me? Well, it formalizes that a concept within M3O might classify only one entity, and that this entity must have as setting a M3O Situation. This could be continued, e.g., by requiring that M3OSituations only satisfy M3ODescriptions, that M3ODescriptions define only M3OConcepts, and so on. But that would also imply that specializing our patterns would require sub-concepts of our M3O concepts, which would need to satisfy the same axioms.

But is that really desired? Obviously it would provide very clear semantics, but it might hinder adoption. Maybe we can not foresee particular cases where our axioms do not hold. So the question is: How strong should an ontology design pattern be formalized? Is their main advantage the formalization? Or is it rather their template-like character that provides an idea of how to model certain things? I am personally not yet sure which way I will go, so I’m open for comments ;).

Information Realization in Dolce Ultra Light

Yesterday I discussed with Ansgar about some Ontology Design Patterns, and we encountered an issue with the Information Realization pattern from ontologydesignpatterns.org and Dolce Ultra Light (DUL).

The original Information Realization pattern.

The original Information Realization Pattern.

In the original pattern InformationRealization is a subclass of

realizes some InformationObject.

In DUL, however, InformationRealization is also defined as being equivalent to

PhysicalObject or (Event and hasParticipant some PhysicalObject) and realizes some InformationObject.

In other words, it is either a PhysicalObject that realizes some InformationObject, or it is an event in which some PhysicalObject participates that realizes the InformationObject. This definition makes sense, since some performance on a specific date and at a specific place indeed realizes some InformationObject, e.g., Goehte’s Faust.

Anyway, this definition also seemed to us, at least, problematic, since it is not clear anymore whether an information realization is an object or an event. We tried to model what the underlying patter should be, and came up with the following.

The extendend Information Realization Pattern.

The extendend Information Realization Pattern.

We came to the conclusion that information realization always consists of both an event and at least one object, which is depicted in the lower part. Both are involved in realizing the information. For example, in the case of the Mona Lisa, it is not only the painting that realizes the Mona Lisa, but it is the painting participating in the event of its existence that realizes the Mona Lisa. Obvioulsy, this particular view is still debatable, since it would also be a possible interpretation  that both Da Vinci and the painting participating in the event of the creation of the painting are the realization. In both cases there are, however, both an object and an event involved. In other words, even when intuitively the object realizes some information, it is actually the participation of some object in an event that realizes the information. This view is even supported by one of the most fundamental axioms of DUL, namely that there is no object without an event, and vice versa. Therefore we know that this event must exist.

However, using only the event as the InformationRealization does also not suffice, since not all participating objects necessarily realize the information. Take the performance of Goethe’s Faust as an example. There is clearly the actors that realize the act, although both the actors and the audience participate in the event of the play. In other acts, such as the Rocky Horror Picture Show the audience might, however, play a role, and some interaction between audience and actors takes place. In such cases at least some audience members actualy contribute to the realization.

In the final pattern, we decided to keep the class InformationRealization for convenience reasons.

The full information realization pattern.

The full Information Realization Pattern.

Our pattern, while more complete, is also more complex and less intuitive. Therefore, we concluded that it might not always be reasonable to instantiate the full pattern and chose the middle way. We include both, making the full pattern, and also the full semantics, of information realization explicit, but also providing the possibility to use it in a more conveneint way through the simple pattern. Whether that is a good choice will need further discussion, though.

New Blog

So, after having two blogs for the last year, one in German and a work-related one in English, I decided to set up a single blog, in which I will only blog about professional stuff, i.e., everything related to Semantic Web, Semantic Multimedia, Software Development, or IT in general. This will become my primary homepage from now on. Now I only have to find time to create content :).