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.

2 thoughts on “Information Realization in Dolce Ultra Light

  1. Ghislain

    Congratulations for the M30 ontology!! Well, concerning the issue you discussed here, about informationRealization, I think one of a good practice of doing ODPs is to have simple patterns that could be intuitive and easy to specialize. Is this final proposal used in you paper about M3O?
    Thanks!!

  2. Carsten Saathoff Post author

    Thanks!

    In the M3O we finally used the simple Information Realization Pattern for sake of simplicity. In that respect I agree with you. Patterns should be as simple as possible and for the M3O it was sufficient to use the simple version.

    However, the last proposal could also be used, since it fully contains the simple pattern. In the end it’s even more complicated, since in some scenarios it might even be necessary to view information realization in a context. In that case we would also need the Descriptions and Situations Pattern arounf the IR pattern. This is even foreseen in the Ontology of Information Objects. The drawback, however, is that less people will understand the pattern, although it represents (from a multimedia perspective) a rather simple concept.

    So, yes, I think as a rule of thumb one should not make patterns more complicated than required. If a simple pattern satisfies your requirements it’s fine.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax