From Semantic Multimedia Wiki

Introduction

Winter^[1] is an annotation based Java POJO (Plain Old Java Object) to RDF^[1] persistence layer. Winter is inspired and based on by So(m)mer ^[1], a simple POJO to RDF mapper build by Henry Story. During our work on the developement of APIs to access and manipulate data from ontologies like the M3O ^[1] we came across a problem that arises with almost all available RDF persistence layers. All of them utilize similar mapping patterns, subsequently called the object-to-statement mapping. In such a layer each class includes an URI for the concept/type (subsequently called ConceptURI )represented by this class and each object includes some kind of identification URI (IndividualURI). With these two URIs the layer will map an object to an RDF statement in the form:

IndividualURI <rdf:type> ConceptURI

Furthermore predicates could be attached to class members to enable their mapping. Such a member variable would be mapped to a RDF statement using the attached predicate:

IndividualURI <attached_predicate> Member_Value

Object to Statement Mapping

Using such a mapping result in a object structure, there all the inter-individual relationships are encoded in the inter-object relationships. This is completely sufficient to express simple inter-individual relationships, like those used in Foaf. For more complex ontologies and thus more complex inter-concept relationships, it often makes sence to encapsulate parts of the inter-concept and thus the inter-class relationships in dedicated classes^[1].
Such an encapsulation class provides access to create, query and manipulate on a higher level of application. If we take a look at the M3O and especially at the different patterns, we observe that such a pattern represents a unit of concepts modeling a particular semantic in the context of the whole ontology. In a concrete API, we might want encapsulate such semantic unit in dedicated classes (pattern classes) that provide direct access methods. These access methods should enable the user to work on whole patterns instances at once. They enable the user to search for and to manipulate these units directly without referring to the single concept representation on the lower level. Additionally the pattern classes cloak concept representations not interesting from the API user.

As an example we refer to the Annotation pattern and the application of a specialization of this pattern, the EXIFAnnotation pattern, shown in Figure 1.

Figure 1:EXIF geo point annotated Image

This particular pattern as part of the whole M3O ontology has the purpose to model an annotation of a multimedia data object with another data object. This annotation could be enriched with provenance information. In the application, shown in Figure 1, an image of the timesquare is annotated with an exif geo-point declaring the geo location there this photo is taken. Additional provenance information about the annotation method is also provided.
For the use in an API allowing to access and manipulate the data, usually only the concepts providing real content (content concepts) and the pragmatic encoded by the semantic unit are of interest. Only such classes will get their particular class representations in Winter APIs. In a supposed application using the EXIFAnnotation pattern, a content concepts can be the image or the geo-location and the underlying pragmatic is to annotate.
All the other concepts (structure concepts) are only of use for the serialization, they encode the structure of the data model. Due to this structure concepts do not really need their own class representations on API side. It is completely suffcient to represent individuals of such concepts through two URIs, the unique identifier(IndividualURI) and the type (ConceptsURI)

Beside from the classic object-to-statement mapping Winter provides special functionality for classes encapsulating semantic units (pragmatic units). Instances of semantic units and thus its object-oriented counterparts have no own unique URI like individuals or concepts have. They are unique by their participating individuals. So the standard object-to-statement mapping is not applicable. Additional to that such a class encapsulates multiple relationsships and so it has to be mapped to multiple RDF statements. Serializing our example should produce these statements:

 The inter-individual relationsships

 ead-1                    <defines>            airr-1
 ead-1                    <defines>            geo-location-parameter-1
 ead-1                    <defines>            mr-1
 airr-1                   <classifies>         image-realization-2
 geo-location-parameter-1 <classifies>         geo-location-1
 mr-1                     <classifies>         m-1
 image-realization-1      <isObjectIncludedIn> eas-1
 geo-location-1           <isObjectIncludedIn> eas-1
 m-1                      <isObjectIncludedIn> eas-1
 eas-1                    <satisfies>          ead-1
 
Additional the type declaring statements for all single individuals

 ead-1                    <rdf:type>           EXIFAnnotationDescription
 airr-1                   <rdf:type>           AnnotatedInformationRealizationRole
 geo-location-parameter-1 <rdf:type>           EXIFGeoLocationParameter
 mr-1                     <rdf:type>           MethodRole
 image-realization-1      <rdf:type>           JPEGFile
 geo-location-1           <rdf:type>           GeoPoint
 m-1                      <rdf:type>           EXIFAnnotation
 eas-1                    <rdf:type>           EXIFAnnotationSituation

If we now assume that we have class representations for the JPEGFILE and GeoLocation content concepts our example should serialize image-realization-1 and the geo-location-1,as described in the object-to-statement mapping. This will result in these statements:

 image-realization-1      <rdf:type>           JPEGFile
 geo-location-1           <rdf:type>           GeoPoint

The class for the pragmatic unit, encapsulating the relationships and the structure concept representations. For our example it should serialize to the rest of the statements above. These are the statements encoding the inter individual relationship and the type declaration statements for all structure objects encapsulated by the concrete pragmatic unit object.

 ead-1                    <defines>            airr-1
 ead-1                    <defines>            geo-location-parameter-1
 ead-1                    <defines>            mr-1
 airr-1                   <classifies>         image-realization-2
 geo-location-parameter-1 <classifies>         geo-location-1
 mr-1                     <classifies>         m-1
 image-realization-1      <isObjectIncludedIn> eas-1
 geo-location-1           <isObjectIncludedIn> eas-1
 m-1                      <isObjectIncludedIn> eas-1
 eas-1                    <satisfies>          ead-1
 ead-1                    <rdf:type>           EXIFAnnotationDescription
 airr-1                   <rdf:type>           AnnotatedInformationRealizationRole
 geo-location-parameter-1 <rdf:type>           EXIFGeoLocationParameter
 mr-1                     <rdf:type>           MethodRole
 m-1                      <rdf:type>           EXIFAnnotation
 eas-1                    <rdf:type>           EXIFAnnotationSituation

The Winter annotations

As mentioned above Winter based on Java annotations. To enable winter to process arbitrary object the user has to add special Winter based annotations to the classes. For this purpose winter knows two different annotations, @object and @field. The @object annotations is used to annotate whole classes and the @field annotation is used to annotate fields. The @object annotation in winter is capable to trigger two differnt mapping behaviors. The standart object-to-statement mapping and the extended object-to-multiplestatements mapping. The @field annotation in winter is capable to trigger 4 different behaviors. Mapping behavior for, Content-Object, URIs, Literals and Pattern-Objects.

Annotation Fields

All winter annotations have different fields holding the metadata needed for the mapping procedure. These fields are the type', query,src and dst field. The two fields we could find in both annotations @object and @field are the type and query field. The other fields are more specialized and are only applicable to the @field annotation. Depending on the usecase of the concrete annotation, often not all fields are mandatory.

1. The type field

The type field could be occupied by the values defined in AnnotationTypes enumeration. There Winter defines 6 different annotation types CONTENT, PATTERN, URI, TYPEDURI, LITERAL and MAPPING. These types are used by Winter as triggers to initiate the intended behavior. For @object annotations the default type is CONTENT, for @field it is URI.

CONTENT: In an @object annotation a CONTENT type indicates that the annotated object, represent a content object and should be mapped in the old object-to-statement fashion. Such an annotation can declare a query field and a concept field. In an @field annotation it indicates that this concrete field points to an @object annotated object of the type CONTENT. Like a @object annotation, it can declare a query and a concept field, additional to this can also declare a var field.
PATTERN: This annotation type is exclusive for @object annotations. It indicates that the annotated object represent a pattern object. As described such pattern objects have no own individual URI and mostly are mapped to multiple patterns. The PATTERN typed annotation may only declare a query.
URI: This annotation type is exclusively for @field annotations. It indicates that this field contains URI(s) representing structure objects. URI typed @field annotations usually can declare query and var.
TYPEDURI: Like the URI type, TYPEDURI typed annotations are exclusively for fields and should be used if the structure individual type is fixed. TYPEDURI typed @field annotations usually can declare qconcept and var.
LITERAL: Annotations of this type are exclusively for @field annotations. They indicate this field to contain a literal. LITERAL typed @field annotations usually can declare query and var.
MAPPING: Annotations of this type are exclusively for @field annotations. This annotation type indicates that this field referrences one or multiple pattern objects. An annotation of this type can declare a query and has to declare src and dst field.

2. The query field

The query field is a String field, it holds a query statement pattern describing the concrete object in a SPARQL like syntax. For an content class with standart object-to-statement mapping, like the Image or Geo-Location from our example this query normaly only consists of an <rdf:type> statement. E.g. for the image class it will look like this:

 ?Image <rdf:type> ?ImageConcept

For the pattern class from our M3O example the pattern will look like this:

 1 ?EXIFAnnotationDescription      <defines>            ?AnnotatedInformationObjectRole, ?GeoLocationParameterRole, ?MethodRole;
                                   <rdf:type>           ?EXIFAnnotationDescriptionConcept.
 2 ?AnnotatedInformationObjectRole <classifies>         ?InformationObject;
                                   <rdf:type>           ?AnnotatedInformationObjectRoleConcept
 3 ?GeoLocationParameterRole       <classifies>         ?EXIFGeoLocation;
                                   <rdf:type>           ?GeoLocationParameterConcept
 4 ?MethodRole                     <classifies>         ?Method;
                                   <rdf:type>           ?MethodRoleConcept.
 5 ?InformationObject              <isObjectIncludedIn> ?EXIFAnnotationSituation;
                                   <rdf:type>           ?InformationObject. 
 6 ?EXIFGeoLocation                <isObjectIncludedIn> ?EXIFAnnotationSituation;
                                   <rdf:type>           <http://exif.org/GeoLocation>.
 7 ?Method                         <isObjectIncludedIn> ?EXIFAnnotationSituation;
                                   <rdf:type>           ?Method.
 8 ?EXIFAnnotationSituation        <satisfies>          ?EXIFAnnotationDescription;
                                   <rdf:type>           ?EXIFAnnotationSituationConcept.

Full SPARQL syntax is supported. You are able to use multiple object[1] or same subject syntax[1-8]. All the variables defined in such a SPARQL pattern are substituated with the values of the corresponding members of the annotated class. A class has to declare corresponding fields for all variables used in its @object annotation query. Fields corresponding to variables in the @object annotation query are mandatory to the object, if they are not declared the whole object will not be mapped. How the corresponding fields are matched and how to declare optional fields, we discribe in the section about @field annotations.

It is also possible to use values instead of variables in the SPARQL query pattern, e.g. this could make sense to define concepts (like in the type declararion in [6]). If you put a value instead of an variable in the query String this value will be fix for all objects instantiated from this particular class and could be changed during the application runtime.

4. The var field

The var field is only applicable to @field annotations. This field is used to indicate the variable in an SPARQL query pattern declared in the @object annotation of this class or in any @field annotation declared in this class. For example if the annotation of the IndividualURI field in the JPEGFILE class defines var as Image then the ?Image variable in all query patterns defined in annotations of this particular class will be substitued with this URI during mapping.

5. The src and dst field

These two fields are only applicable to @field annotations and both of them must be declared. They are used in @field annotations of type MAPPING to match variable names in the class declaring the MAPPING annotated field and the pragmatic unit class referenced by this field. The src field holds the names of the declaring class and in the same order the dst holds the names of the referenced class. Both fields are String Arrays and if defined both Arrays have to have the same length. By the means of this variable matching Winter is capable to substitute the fields of the referenced class with the corresponding values from the declaring class. In our example, this could be useful if we want to encapsulate the provenance information in a separate provenance class for example. In such a case we would create a new @object annotated class with the type PATTERN. The query of this class would be:

 ?EXIFAnnotationDescription      <defines>            ?MethodRole;
                                 <rdf:type>           ?EXIFAnnotationDescriptionConcept.
 ?MethodRole                     <classifies>         ?Method;
                                 <rdf:type>           ?MethodRoleConcept.
 ?Method                         <isObjectIncludedIn> ?EXIFAnnotationSituation;
                                 <rdf:type>           ?Method.
 ?EXIFAnnotationSituation        <satisfies>          ?EXIFAnnotationDescription;
                                 <rdf:type>           ?EXIFAnnotationSituationConcept

And the class should declare all necessary fields. But when mapping an annotation object and a referenced provenance object is mapped the EXIFAnnotationDescription, the EXIFAnnotationDescriptionConcept, the EXIFAnnotationSituation and the EXIFAnnotationSituationConcept sould match.

Common annotation field combinations and their use

Here we present some commonly used annotations, field combinations and their purpose.

@object annotations

In general there are 2 different types of @object annotations, annotations of simple objects that should be mapped in the old fashion object-to-statement way and pragmatic unit object mapped to multiple patterns.
The simple objects are usually annotated with an @object annotation with only a query field holding a type declaring statement. If the object is of fixed concept one can define the concept type in this statement. This is the common case, for special purpose it is possible to add much more complex statement patterns to the query field. The only thing is that all variables defined in the query must have their corresponding field.

@field annotations

Architecture

WINTER can be used in applications such as media management tools that leverage the core ontologies like the M3O or some (domain-specific) extensions of the M3O as they have been described in [Technical Report - Eissing, Scherp, Staab]. In order to do this, we recommend a layered architecture as shown below.

Application Layer

Extended M3O Layer

M3O Layer

WINTER

TripleStore

The extended M3O layer is only necessary if some possibly domain-specific extension of the M3O (or other ontology) should be used.

References

[1]

WINTER:Main