RECommendations Ontology

3. Ontology overview

This section provides a general description of the ontology, explaining the main concepts such as preference or demand. Moreover, this section introduces the most basic design patterns for using the vocabulary of the ontology: simple and composite preferences and datatype constraints. RECO ontology is specially designed to be used by matchmaking and recommendation applications that are fueled by user desires and preferences.

The diagram below graphically shows in a global way the concepts and properties comprising RECO:

3.1 Preferences

The central concept of the ontology is preference, which is defined as a desire of a rational agent about properties of objects. A preference might be interpreted as a set of matchmaking conditions in a particular set of resources or objects, where they should satisfy this conditions in order to be considered valid, suitable or even useful. Personalized recommendations must be generated using the proper preferences of users, matching their actual desires and interests.

• Liking preferences: A liking preference is, for instance, an expression as "A person likes [p1]", where the person has a positive attitude towards a particular object, commodity or service.
  

  In the diagram the resource ex:pref1 has two complementary roles. On the one hand, it represents the preference which the user is modally related to (e.g. the user desires ex:pref1). This is illustrated by the fact that ex:pref1 is an instance of the class Preference. On the other hand, ex:pref1 also holds the desired conditions that should be matched by resources of a particular marketplace in order to be considered useful (i.e., a resource to fulfill the preference must be a car). This mechanism, where the proper preference may be interpreted as both an instance of the class Preference and the resource related with the user desired conditions, allows to express preferences and modal attitudes inside the expressive limits of OWL-DL.

• Disliking preferences: in a disliking preference, for instance any expression similar to "A person doesn't like [p2]", a person or rational agent shows a negative attitude towards a particular object, commodity or service.
  

Preferences may be identified both as blank nodes or named resources. In this specification we alternate examples using both options. Notice that blank nodes are interpreted using standard RDF semantics, conditioning the reusability of preferences outside the RDF graph where they are defined.

3.2 Utility and recommendations

Preferences can be ranked depending on the interest of users. For instance, if you consider the expression "I like grapes, but I would rather select pineapples", this means that you like both fruits but if you have to decide you would choose the last one. In our approach, instead of using fuzzy operators that bring us the modal semantics of preference, we decided to use a numerical value to determine the salience of the preference. Therefore the ranking of preferences is easily calculated taking into account their saliency, called in the ontology reco:utilityValue:

In addition, the property reco:utilityValue is also used to represent the utility of a candidate, where we understand utility as a measurement of the user satisfaction about an object or resource. Basically, the utility is a function that maps resources from a set of candidates to real numbers considering the user preferences the candidates fulfill. The numerical value of the utility is represented using the property reco:utilityValue. Thefore, given two resources ex:A and ex:B, if the utility for a rational agent of ex:A is greater than the utility of ex:B: i.e., U(ex:A) > U(ex:B), then the agent prefers ex:A to ex:B.

ex:A   reco:utilityValue  "0.7"^^xsd:float .

ex:B   reco:utilityValue  "0.3"^^xsd:float .

This relation of "preference" is used to produce recommendations (i.e., to make decisions and selections over maketplaces of candidates) because it introduces a partial order between a set of candidates (i.e., a ranking of the marketplace resources). Therefore, this ordered list of candidates might be used by applications to generate personalized recommendations and suggestions to the user. In this sense, utilities (expressed with reco:utilityValue) may be used to rationalize the relators of the Preference Logic whether the following axioms of the Utility Principle hold:

• U(ex:A) > U(ex:B) iff ex:A ex:B
• U(ex:A) = U(ex:B) iff ex:A ex:B

In the Preference Logic, the relation of preference between two candidates of a marketplace is represented by means of the relator: , i.e., ex:A is preferred than ex:B. Moreover, the relator is used to represent the indifference of an agent between two candidates.

The scale to measure the utility is arbitraty. It depends on the requirements of particular applications of the vocabulary. Usually, utility values will be normalized within the range (0,1), although this is not mandatory nor normative.

3.3 Demands

A more complex case can be considered when preferences are grouped together. Combined in such a way, a group of preferences set up a demand. From the user's point of view, a demand is another kind of modal description representing the willingness of a user to "purchase" or acquire a commodity or a service. A demand is always evaluated in a particular marketplace of objects, where the set of preferences comprising a demand expresses a set of matchmaking conditions.

Furthermore, demands feature four different groups of preferences. Each type of preference plays a differente role in the interpretation of the demand on a particular marketplace of resources.

• Mandatory Preferences: If p is a mandatory preference in a demand d, then every resource of the marketplace that satisfies d must have p.
• Positive Preferences: If p is a positive preference in a demand d, then a resource of the marketplace that satisfies d might have p. If a resource has p, its utility increases in value.
• Negative Preferences: If p is a negative preference in a demand d, then a resource of the marketplace that satisfies d might have p. If a resource has p, its utility decreases in value.
• Excluding Preferences: If p is an excluding preference in a demand d, then every resource of the marketplace that satisfies d must not have p.

Following, there is an illustration of a demand using the ontology:

3.4 Design patterns

This subsection presents the basic guidelines for representing preferences using the RECO vocabulary.

3.4.1 Simple and complex Preferences

A desired condition of a commodity in a preference is expressed by a statement of the form (preference, P, O) where:

1. (preference, P, O) is an RDF triple.
2. P is any property (from rdf:type to any other property) and O is any resource of an external vocabulary or ontology.
3. P is any property of an external vocabulary or ontology and O is a reco:Pattern.
4. P is the reco:filter property and O is an instance of the class reco:Filter that expresses a condition on a datatype property of an external vocabulary or ontology.

Sometimes preferences are more complex than a simple triple (preference, P, O). Consider for instance a preference like the following: "Crime films starred by people born in Spain". This preference has two conditions. The first one is very simple: "Crime films". It declares the film genre desired by the user. However, the second one requires a more complex analysis: "starred by people being born in Spain". A film is starred by actors and these actors (as any individual) have their own semantic description. This time the condition is not asking about a property of films, but about a property of the actors starring in a film (i.e. the Spanish nationality). Therefore, a film that satisfies the conditions of the preference has to be not only a crime film but the starring actors must be Spanish. We will consider this kind of preference as a complex preference.

We use the class reco:Pattern to represent a set of conditions about an individual, where this individual is not the proper preference. In our example, the pattern represents the condition that actors of the film has to be Spanish people.

ex:pref1 rdf:type reco:Preference ; 
      rdf:type dbpedia-owl:Film ; 
      skos:subject dbpedia:Category:Crime_films ; 
      p:starring ex:pattern1 . 

ex:pattern1 rdf:type reco:Pattern ; 
            p:born dbpedia:Spain . 

In addition to this last example, patterns can be part of another pattern as well. Patterns are sets of conditions about an individual that can be (re)used by another pattern to build a more complex condition on a preference. Consider for instance the following preference "Films starred by actors whose wives are also actors". In this preference, two patterns can be identified. The first one asks about actors starring in the film. And the second one expresses a condition about the spouses of these actors. The representation in our ontology is the following:

ex:pref2 rdf:type reco:Preference ; 
      rdf:type dbpedia-owl:Film ; 
      p:starring ex:pattern1 . 

ex:pattern1 rdf:type reco:Pattern ; 
             p:spouse ex:pattern2 . 

ex:pattern2 rdf:type reco:Pattern ; 
            rdf:type dbpedia-owl:Actor . 

3.4.2 Composite preference (AND)

Sometimes it is also needed that an individual fulfills two or more different preferences. So we need to add a new class capable of describing this situation. A new class, called reco:CompositePreference, is created. This class allows us to group together a set of preferences aplied to a marketplace.

If we want to express an individual to fulfill all the preferences included in a composite preference, the property reco:andComposition must be used, as the following example shows: "Crime films directed by Quentin Tarantino shorter than 120 minutes"

ex:pref3 rdf:type reco:CompositePreference ; 
    reco:andComposition ex:pref1 ; 
    reco:andComposition ex:pref2 . 

ex:pref1 rdf:type reco:Preference ; 
    rdf:type dbpedia-owl:Film ; 
    p:director dbpedia:Quentin_Tarantino ; 
    skos:subject dbpedia:Category:Gangster_films . 

ex:pref2 rdf:type reco:Preference ; 
    dbpedia-owl:Film#runtime         "120"^^xsd:integer ; 
    reco:filter op:numeric-less-than . 

Notice that it is possible to represent these preferences without using the AND composite patterns. It would be simplified just considering all the matchmaking conditions as part of the same preference. The introduction of the AND composite pattern might seem redundant, although it is justified at least by two reasons:

• The usage of different utility values is possible when different preferences are considered in combinations of sets of matchmaking conditions. If all the conditions are grouped together in a single preference, just a single utility value can be applied.
• An RDF/OWL representation of preferences gives a boost to their reusability in the context of the Semantic Web. It is envisioned that frequently preferences will be aggregated from different datasets and applications. In this case, the AND composite pattern conveys the expressivity and flexibility to build complex preferences from them.

3.4.3 Composite preference (UNION)

Using the AND pattern, a candidate to achieve the composite preference must always fulfill the preferences it is comprised by. However, sometimes this is very restrictive and a candidate might fulfill just some of the simple preferences but still achieving the composite one. For these cases, a new pattern for composite preferences, featuring the property reco:unionComposition, is used to bring together all the preferences in a disjunction.

An example of that is showed here: "Crime films directed by Quentin Tarantino or by Brian de Palma".

ex:pref3 rdf:type reco:CompositePreference ; 
    reco:unionComposition ex:pref1 ; 
    reco:unionComposition ex:pref2 . 

ex:pref1 rdf:type reco:Preference ; 
    rdf:type dbpedia-owl:Film ; 
    p:director dbpedia:Quentin_Tarantino ; 
    skos:subject dbpedia:Category:Gangster_films . 

ex:pref2 rdf:type reco:Preference ; 
    rdf:type dbpedia-owl:Film ; 
    p:director dbpedia:Brian_De_Palma ; 
    skos:subject dbpedia:Category:Gangster_films . 

This preference might also be expressed by means of a combination of AND and UNION composite pattern. The following expression is equivalent to the last one but it demands a recursive interpretation of the composition of preferences:

ex:pref3 rdf:type reco:CompositePreference ; 
    reco:andComposition ex:pref1 
    reco:andComposition ex:pref2 

ex:pref1 rdf:type reco:Preference ; 
    rdf:type dbpedia-owl:Film ; 
    skos:subject dbpedia:Category:Gangster_films . 

ex:pref2 rdf:type reco:CompositePreference ; 
    reco:unionComposition ex:pref4 ; 
    reco:unionComposition ex:pref5 . 

ex:pref4 rdf:type reco:Preference ; 
    p:director dbpedia:Brian_De_Palma . 

ex:pref5 rdf:type reco:Preference ; 
    p:director dbpedia:Quentin_Tarantino . 

3.4.4 Datatype constraints on preferences

Conditions about datatype properties have a particular status in our approach. A statement of the form (s,p,l) in RDF, where l is a literal, only captures the fact that l is the fixed value for the property p when applied to s. But when we are talking about preferences, we need more expressivity. Constraints on literals need to be added to our ontology to be able to express conditions such as "Films shooted before 1970".

Therefore a mechanism to represent constraints on values of datatype properties has been defined, allowed to be used both in reco:Preference and in reco:Pattern assertions. The mechanism is comprised by:

• Filter: a filter is the condition that constrains the possible values of a datatype property in a particular preference or pattern.
• Operator: an operator is the function that is applied to literal values of individuals of the marketplaces to know if they satisfy the condition or not.

The aforementioned example is formalized as follows:

 ex:pref1 rdf:type reco:Preference ; 
       rdf:type dbpedia-owl:Film ; 
       reco:filter ex:filter1 . 

ex:filter1 rdf:type reco:Filter ; 
           dbpedia-owl:releaseDate "1970-01-01"^^xsd:date ; 
           reco:operator reco:lesserThan . 

3.4.5 "Who can exert a preference"

In the literature of preferences, many entities may exert modal attitudes such as preferences, but also desires, beliefs, inclinations, etc. This ontology is designed to be used in combination with the widely-adopted FOAF vocabulary. In particular, the following entities have been considered:

1. An individual agent, embodied by the class foaf:Agent, not restrited to a person but also to non-human beings, such as applications or software agents.
2. A collective, embodied by the class foaf:Group. This allows to express preferences and appealingnesses of a group of people like: "In Spain, sociological inquiries reflect that teenagers prefer videogames to sport activities".
3. A user profile, embodied by the class reco:Profile. Profiles contextualize sets of preferences of individual agents, allowing a user to hold several profiles. By means of profiles, users might exert contradictory preferences depending on the context of the user and the profile that applies to this context. For instance, "Joe prefers to watch TV entertainment shows at home, but Joe prefers to watch movies when he is at his girlfriend's".

However, it is envisioned that other kind of entities might as well exert preferences. In this case, we strongly recommend to not use the already defined property of the ontology: reco:desireTowards, as DL rules might lead into undesirable conclusions. An ad-hoc property can be created for this purpose.

4. Cross-reference for RECO classes and properties