D 2.1 Descripción semántica del contexto
De MorfeoWiki
PROFIT
Morfeo-EzWeb
Área Temática: 350405 Strategic Action on Open Source Software
TSI-020301-2009-13 EzWeb
Entregable:
D 2.1 Descripción semántica del contexto
| Versión: | 3.0 (1.0, 2.0) |
| Fecha de preparación: | Diciembre de 2009 |
| Editores: | Luis Polo, Iván Mínguez (Fundación CTIC) |
| Revisores: |
Contenido |
Introducción
Esta sección esta dedicada a la descripción de contexto en términos semánticos para la plataforma EzWeb. Esta definición dejará perfectamente delimitado qué se podrá representar como parte del contexto de EzWeb y cómo se expresaría utilizando los elementos creados para esto. Estos elementos serán definidos por medio de una ontología.
Esta definición del contexto tienen como fin último la generación de sugerencias personalizadas para el usuario a partir de sus preferencias. A este proceso lo llamaremos matchmaking como veremos a lo largo de esta sección.
Mecanismos de actualización el contexto
Los perfiles y las preferencias de los usuarios varían con el tiempo y las situaciones. La plataforma Ezweb debe proporcionar mecanismos que permitan la actualización y modificación de la información del contexto. En esta sección se describirá SPARUL (SPARQL/Update), un lenguaje que se utilizará en EzWeb como mecanismo para actualizar la información del contexto de los usuarios: preferencias, perfiles, tags, etc.
La representación semántica del contexto en EzWeb es un grafo RDF. SPARUL es una extensión del lenguaje SPARQL que permite expresar actualizaciones en un repositorio RDF. La gestión de la información mediante expresiones en SPARUL pueden ser realizada a través del endpoint del servicio web SPARQL. SPARUL proporciona las siguientes capacidades de interés para EzWeb
- Añadir nuevas tripletas a un grafo RDF: operación INSERT DATA.
INSERT DATA [ INTO <uri> ]*
{ triples }
Esta operación se utiliza cuando hay que introducir nueva información de contexto en el grafo RDF, ya sean nuevas preferencias, perfiles o demandas de los usuarios. Por ejemplo, para anadir una demanda (ex:demanda1) basada en dos preferencias obligatorias (var:p1, var:p2) a un perfil del repositorio de EzWeb, se haría la siguiente operación:
PREFIX ctxt: <http://ontologies.ezweb.morfeo-project.org/context/ns#> PREFIX var : <http://ontologies.ezweb.morfeo-project.org/context/variable/> PREFIX ex : <http://wwww.w3.org/example#> INSERT DATA INTO <http://resources.ezweb.morfeo-project.org> {ex:Juan_Profile ctxt:asksFor ex:demanda1 . ex:demanda1 rdf:type ctxt:Demand ; ctxt:mandatoryPreference var:p1 ; ctxt:mandatoryPreference var:p2 . var:p1 rdf:type ctxt:Preference . var:p2 rdf:type ctxt:Preference . }
- Borrar tripletas de un grafo RDF: operación DELETE DATA.
DELETE DATA [ FROM <uri> ]*
{ triples }
Esta operación se utiliza cuando es necesario eliminar información de contexto del grafo RDF. Esta operación de borrado de tripletas se puede utilizar, por ejemplo, para eliminar perfiles de usuario o preferencias y demandas obsoletas. A continuación se describe el proceso de borrado de propiedades de un perfil:
PREFIX ctxt: <http://ontologies.ezweb.morfeo-project.org/context/ns#> PREFIX var : <http://ontologies.ezweb.morfeo-project.org/context/variable/> PREFIX ex : <http://wwww.w3.org/example#> DELETE DATA INTO <http://resources.ezweb.morfeo-project.org> {ex:Juan_Profile ctxt:desireTowards var:p1 . var:p1 rdf:type ctxt:Preference ; rdf:type dbpedia:Film . }
- Modificar un grafo RDF: operación MODIFY
MODIFY [ <uri> ]*
DELETE { template }
INSERT { template }
[ WHERE { pattern } ]
La operación básica para actualizar un grafo RDF es la operación MODIFY, que se basa en las dos suboperaciones INSERT y DELETE. Una operación de modificación consiste en un grupo de tripletas que tienen que ser eliminadas y un grupo de tripletas que tienen que ser añadidas. La especificación de estas tripletas se puede realizar a través de un patrón de grafo (pattern). La diferencia entre las suboperaciones INSERT / DELETE, que especifican un prodecimiento de modificación de un grafo RDF, y las operaciones INSERT DATA / DELETE DATA es que estas últimas no utilizan plantillas (template) ni patrones (pattern). Estas operaciones especifican conjuntos de tripletas concretos. La sintaxis de las plantillas y patrones de una operación de modificación se realiza mediante el lenguaje SPARQL.
Dado el siguiente conjunto de tripletas RDF que expresan preferencias opcionales de una demanda de un usuario, queremos ser capaces de modificarlas para que pasen a ser preferencias obligatorias:
ex:demanda1 rdf:type ctxt:Demand ;
ctxt:positivePreference var:p1 ;
ctxt:positivePreference var:p2 ;
ctxt:mandatoryPreference var:p3 .
var:p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film .
var:p2 rdf:type ctxt:Preference ;
ctxt:filter var:pat1 .
var:pat1 rdf:type ctxt:Pattern ;
dbpedia-owl:releaseDate "1970-01-01"^^xsd:date ;
ctxt:operator ctxt:lesserThan .
Para modificar este grafo utilizamos la siguiente expresión SPARUL:
PREFIX ctxt: <http://ontologies.ezweb.morfeo-project.org/context/ns#> PREFIX var : <http://ontologies.ezweb.morfeo-project.org/context/variable/> PREFIX ex : <http://wwww.w3.org/example#> MODIFY GRAPH <http://resources.ezweb.morfeo-project.org> DELETE { ex:demanda1 ctxt:positivePreference ?preference . } INSERT INTO { ex:demanda1 ctxt:mandatoryPreference ?preference . } WHERE { ex:demanda1 ctxt:positivePreference ?preference . ?preference rdf:type ctxt:Preference . }
Teoría formal del matchmaking
En esta sección se proporcionarán las definiciones básicas de los elementos que intervienen en los procesos de matchmaking.
Definición de Demanda y Marketplace
Definimos una demanda como el conjunto de restricciones que tienen que cumplir las distintas sugerencias que devuelve el mecanismo de matchmaking. Estas restricciones pueden ser de varios tipo, según la importancia de estas:
- Restricciones obligatorias: Son restricciones que todos las sugerencias devueltas por el mecanismo tienen que cumplir. Si no tiene esta características no puede estar en el conjunto de resultados.
- Restricciones positivas: Son restricciones que no filtran los resultados sino que si se tienen esta característica aumenta la afinidad de elemento con el perfil.
- Restricciones negativas: Son restricciones que si un elemento las cumplir hace que disminuya la afinidad del elemento con el perfil.
- Restricciones excluyentes: Son restricciones que si un elemento las cumplen lo excluyen del conjunto de soluciones.
Por otro lado, llamamos Marketplace al conjunto de elementos sobre los que se va a realizar la generación de sugerencias. Dentro de la plataforma EzWeb, el Marketplace es el conjunto de gadget disponibles en el sistema.
El proceso de matchmaking devolverá una lista de elementos de entre los disponibles en el Marketplace que cumplan todas las restricciones obligatorias, no cumplan las restricciones excluyentes y tendrá una puntuación, que nos servirá para ordenarlos por afinidad, calculada a partir del cumplimiento de las restricciones positivas y negativas.
Definición de la función matching
La función de matching es la encargada de realizar la comprobación de si un elemento del marketplace cumple las restricciones que se incluyen en la demanda. De modo que la función matching(s), siendo s un elemento del marketplace, es el conjunto de restricciones de la demanda que cumple el elemento s.
Definición de la función score
A la hora de definir la restricciones positivas y negativas debemos asignarles una importancia dentro de la demanda. De este modo podemos disponer de restricciones que sean más importantes para el perfil que otras. Utilizando estas puntuaciones vamos a poder obtener una puntuación para cada una de los elementos de marketplace.
Definición de la función matchmaking
Por último la función de matchmaking englobará las funciones de matching y score de modo que para una demanda y un marketplace nos devolverá una lista de elementos puntuados, que ademas cumplen las restricciones obligatorias y no cumplen las restricciones prohibitivas.
RECommendations Ontology
This section presents the ontology for user profile and context formalization within the scope of EzWeb Project. This ontology introduces a set of properties and classes enabling the representation of preferences and demands. The documentation of the ontology has been generated with the SpecGen tool:
http://ontologies.ezweb.morfeo-project.org/reco/spec
This ontology is complemented with TERRAS, a dedicated recommendation reasoning system aware of RDF/OWL descriptions of single resources and set of them (marketplaces).
Ontology Design Patterns (how to use it)
This section explains the most common representational patterns of the Context Ontology and how they can be used in the EzWeb platform in order to represent user preferences and user demands.
User modal attitudes: preferences and demands
Firstly, a user preference is a desire (modal description) about properties of objects. A preference is interpreted in a particular marketplace (dataset) as a matchmaking condition that resources (offers) should satisfy in order to be considered valid, suitable or useful. In our ontology, we will consider preferences as first-order entities. Regarding preferences, they are internally represented by users in two different modes:
- Liking preferences: "César likes [p1]"
ex:Cesar rdf:type user:EzUser ;
ctxt:desireTowards ex:p1 .
ex:p1 rdf:type ctxt:Preference .
- Disliking preferences: "César doesn't like [p2]"
ex:Cesar rdf:type user:EzUser ;
ctxt:notDesireTowards ex:p2 .
ex:p2 rdf:type ctxt:Preference .
Secondly, preferences can be grouped together to form a demand. Regarding users, a demand is another kind of modal description representing the willingness of a user to purchase a commodity or a service, where the set of preferences that comprised a demand express a set of matchmaking conditions. A demand has to be always evaluated in a particular marketplace:
ex:Cesar rdf:type user:EzUser ;
ctxt:asksFor ex:dem1 .
A demand distinguish between four different groups of preferences.
- 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.
Representation of preferences
As it was aforementioned, a preference is a modal description about some desired properties that an object may have in order to be considered interesting. In our approach, the internal structure of the preference is the semantic description of the entity that represents it. So consider the following preference: "Crime films starred by Tim Roth". This user condition is interpreted in our ontology as:
ex:p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
p:starring dbpedia:Tim_Roth ;
skos:subject dbpedia:Category:Crime_films .
The resource ex:p1 has two complementary roles. On one hand, it represents the preference which the user is modally related to (e.g. the user desires ex:p1). This is illustrated by the fact that ex:p1 is an instance of the class Preference. On the other hand, ex:p1 also holds the desired conditions that should be matched by resources of a particular marketplace in order to be considered useful. Every condition is expressed by a statement of the form (ex:p1, p, o) where:
- p is any property (from rdf:type to any other property) and o is any resource of an external vocabulary or ontology.
- p is any property of an external vocabulary or ontology and o is a ctxt:Pattern.
- p is the ctxt:filter property and o is an instance of the class ctxt:Filter that expresses a condition on a datatype property of an external vocabulary or ontology.
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. So the ranking of preferences is easily calculated taking into account their saliency, called in the ontology ctxt:utilityValue:
ex:p3 rdf:type ctxt:Preference ;
ctxt:utilityValue "0.4" .
ex:p4 rdf:type ctxt:Preference ;
ctxt:utilityValue "0.8" .
Complex preferences (PATTERN)
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 ctxt: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. Again, an instance of ctxt:Pattern is a first order entity.
ex:p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
skos:subject dbpedia:Category:Crime_films ;
p:starring ex:pattern1 .
ex:pattern1 rdf:type ctxt: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 wifes 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:p2 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
p:starring ex:#pattern1 .
ex:pattern1 rdf:type ctxt:Pattern ;
p:spouse ex:pattern2 .
ex:pattern2 rdf:type ctxt:Pattern ;
rdf:type dbpedia-owl:Actor .
Datatype conditions (FILTER)
Conditions about datatype properties have a particular status in our approach. A statement of the form (s,p,o), where o is a literal, only captures the fact that o 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 preferences such as "Films shooted before 1970".
So we have included a mechanism to represent constraints on values of datatype properties. This mechanism is allowed to be used by preferences as well as patterns. The mechanism is comprised in:
- 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:p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
ctxt:filter ex:filter1 .
ex:filter1 rdf:type ctxt:Filter ;
dbpedia-owl:releaseDate "1970-01-01"^^xsd:date ;
ctxt:operator ctxt:lesserThan .
Composite preference (AND)
In our proposal sometimes we can also need that an individual fulfills two or more different preferences. So we need to add a new class capable of describing this new situation. A new class, called CompositePreference, is created. This class allows us to include a set of preferences aplied to the individual. If we want the individual to fulfill all the preferences included in the composite preference we have to use the property andComposition, as the following example shows: "Crime films directed by Quentin Tarantino shorter than 120 minutes"
#p3 rdf:type ctxt:CompositePreference ;
ctxt:andComposition #p1 ;
ctxt:andComposition #p2 .
#p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
p:director dbpedia:Quentin_Tarantino ;
skos:subject dbpedia:Category:Gangster_films .
#p2 rdf:type ctxt:Preference ;
dbpedia-owl:Film#runtime "120"^^xsd:integer ;
ctxt:filter op:numeric-less-than .
Composite preference (UNION)
In the last example an individual needed to achieve all the preferences included in the composite preference, but another possibility is that only some of them need to be fulfilled. In order to achieve that, we include a new way to bring together all the preferences included in a one composite preference. A new property is therefore added: unionComposition. An example of that is showed here: "Crime films directed by Quentin Tarantino or by Brian de Palma".
#p3 rdf:type ctxt:CompositePreference ;
ctxt:unionComposition #p1 ;
ctxt:unionComposition #p2 .
#p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
p:director dbpedia:Quentin_Tarantino ;
skos:subject dbpedia:Category:Gangster_films .
#p2 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
p:director dbpedia:Brian_De_Palma ;
skos:subject dbpedia:Category:Gangster_films .
This preference can be expressed also by means of a pattern combination with AND and UNION. The following expression is equivalent to the last one but it demands a recursive way the preferences composition:
#p3 rdf:type ctxt:CompositePreference ;
ctxt:andComposition #p1
ctxt:andComposition #p2
#p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
skos:subject dbpedia:Category:Gangster_films .
#p2 rdf:type ctxt:CompositePreference ;
ctxt:unionComposition #p4 ;
ctxt:unionComposition #p5 .
#p4 rdf:type ctxt:Preference ;
p:director dbpedia:Brian_De_Palma .
#p5 rdf:type ctxt:Preference ;
p:director dbpedia:Quentin_Tarantino .
Método de transformación de preferencias en recomendaciones para el usuario
La representación del perfil y las preferencias en RDF debe ser transformada para utilizarse en procesos de matchmaking, tal y como se han definido en la sección #Teor.C3.ADa_formal_del_matchmaking. Nuestra implementación utiliza el lenguaje de consultas SPARQL para evaluar qué condiciones (preferencias) cumplen cada uno de los individuos del marketplace, es decir, para la función matching. Por tanto, el primer paso es transformar una demanda expresada según la ontología del contexto en una consulta SPARQL con una estructura determinada.
El input de nuestro módulo de matchmaking consiste en los siguientes parámetros:
- El marketplace. Es necesario identificar el conjunto de individuos sobre los que se quieren aplicar las preferencias de los usuarios. Las mismas preferencias pueden ser aplicadas a diferentes conjuntos de individuos. En nuestra aproximación un marketplace es un repositorio RDF de recursos el cual dispone de un endpoint SPARQL que nos permite acceder a la descripción de los mismos.
- La demanda. La demanda es un conjunto de preferencias de usuario que se evalúa en el marketplace de recursos y que está expresada de acuerdo a los patrones de representación de la ontología del contexto.
- Transformaciones. Un conjunto de mapeos entre las preferencias definidas en RDF y su correspondiente representación en el lenguaje de consulta SPARQL.
Transformación de demandas en consultas SPARQL
En esta sección, se explicará el método para transformar una demanda en una consulta SPARQL con una estructura determinada. Para esta versión del entregable sólo tendremos en cuenta preferencias de obligado cumplimiento y preferencias opcionales de valoración positiva.
Cada una de las preferencias expresadas en la demanda se transforma en un patrón de grafo el cuál será incluido en la cláusula WHERE de la consulta SPARQL. Básicamente este proceso transforma la sintaxis de grafo RDF en la sintaxis de patrones de grafo del lenguaje SPARQL, en el que además las instancias de las clases ctxt:Preference y ctxt:Pattern se interpretan como variables en este lenguaje de consulta.
Consideremos la siguiente preferencia: "Películas de gángsters interpretadas por Tim Roth":
ex:p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
p:starring dbpedia:Tim_Roth ;
skos:subject dbpedia:Category:Crime_films .
Tras la aplicación de la correspondiente transformación, el patrón de grafo resultante sería:
?x rdf:type dbpedia-owl:Film#Class . ?x p:starring dbpedia:Tim_Roth . ?x skos:subject dbpedia:Category:Crime_films .
Las transformaciones que implican preferencias compuestas (ctxt:andComposite, ctxt:unionComposite) y el uso de patrones (ctxt:Pattern) y filtros (ctxt:Filter) son más complejas ya que necesitan generar un mayor número de variables y condiciones sobre los tipos de dato.
Consideremos la siguiente preferencia: "Películas de gángsters interpretadas por algún español y que sean anteriores a 1970":
ex:p1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
skos:subject dbpedia:Category:Crime_films ;
p:starring ex:pattern1 ;
ctxt:filter ex:filter1 .
ex:pattern1 rdf:type ctxt:Pattern ;
p:born dbpedia:Spain .
ex:filter1 rdf:type ctxt:Filter ;
dbpedia-owl:releaseDate "1970-01-01"^^xsd:date ;
ctxt:operator ctxt:lesserThan .
La transformación de esta preferencia sería la siguiente:
?film rdf:type dbpedia-owl:Film . ?film skos:subject dbpedia:Category:Crime_films . ?film p:starring ?actor . ?film dbpedia-owl:releaseDate ?date . ?actor p:born dbpedia:Spain . FILTER (?date < "1970-01-01"^^xsd:date)
Una demanda consiste en un conjunto de preferencias, las cuales pueden ser obligatorias u opcionales. En el caso de las preferencias obligatorias, la transformación opera con el método anteriormente explicado. Sin embargo, para el tratamiento de las opcionales se genera un bloque OPTIONAL en la claúsula WHERE por cada preferencia opcional. Si consideramos la demanda: "quiero películas pero mejor si son de gángsters".
ex:demand1 rdf:type ctxt:Demand ;
ctxt:requiredPreference ex:pref1 ;
ctxt:positivePreference ex:pref2 .
ex:pref1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film .
ex:pref2 rdf:type ctxt:Preference ;
skos:subject dbpedia:Category:Crime_films .
La transformación de esta demanda en un patrón de grafos da como resultado:
?film rdf:type dbpedia-owl:Film .
OPTIONAL{
?film skos:subject dbpedia:Category:Crime_films .
} (pat, p, o)
A continuación presentamos el conjunto de transformaciones (tr) entre las demandas y preferencias en RDF y los patrones de grafo correspondientes. Asumimos que,
dem rdf:type ctxt:Demand . pref rdf:type ctxt:Preference . pat rdf:type ctxt:Pattern . filt rdf:type ctxt:Filter .
y lit es un rdf:Literal.
Las transformaciones se definen en la siguiente tabla:
| Transformación | Tripleta RDF | Patrón de grafo |
| tr(Preference) | (pref, p, o) | ?var p o . |
| tr(Pattern) | (pat, p, o) | ?var p o . |
| tr(Filter) | (filt, p , lit) ; (filt, ctxt:operator, operator) | ?var p ?data . FILTER (?data operator lit) . |
| tr(Preference) | (pref, p, [pat / filt]) | ?var p [tr(pat) / tr(filt)] . |
| tr(Pattern) | (pat, p, [pat / filt]) | ?var p [tr(pat) / tr(filt)] . |
| tr(And) | (dem andComposite pref1) ; dem andComposite pref2) | tr(pref1) . tr(pref2) . |
| tr(Union) | (dem unionComposite pref1) ; (dem unionComposite pref2) | {tr(pref1)} UNION {tr(pref2)} . |
Implementación de la función match
Esta función match se encarga de comprobar qué preferencias de la demanda cumplen los individuos del marketplace. Nuestra implementación de la función match es una única consulta SELECT que engloba tanto las preferencias obligatorias, que filtran el conjunto de individuos, como aquellas opcionales, que permiten valorar la utilidad y relevancia de cada individuo con la demanda del usuario.
En la sección anterior, hemos visto qué transformaciones se aplican a la demanda expresada en RDF para construir el WHERE de la consulta. Cada preferencia se transforma en un patrón de grafo con una estructura particular. Sin embargo, se ha omitido deliberadamente el tratamiento de las variables ya que requiere una explicación en profundidad.
Una preferencia (P), expresada a través de una o varias tripletas RDF como se vio en la sección #Preference_definition, genera un patrón de grafo con una o más variables (dependiendo de si se utilizan patrones (ctxt:Pattern) y filtros (ctxt:Filter). La variable generada a partir de la transformación tr(pref) es la que utiliza en la consulta SELECT. Las soluciones que se obtengan de evaluar esta SPARQL en el marketplace son los individuos que cumplen la preferencia (P):
Consideremos el ejemplo anterior, "Películas interpretadas por españoles":
ex:pref1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film ;
p:starring ex:pattern1 .
ex:pat1 rdf:type ctxt:Pattern ;
p:born dbpedia:Spain .
Si ahora aplicamos el conjunto de transformaciones (tr) se generan dos variables, una correspondiente a la transformación tr(ex:pref1) -> ?var1 y otra correspondiente a tr(ex:pat1) -> ?var2. La variable cuya soluciones representan a los individuos: películas interpretadas por españoles, es la variable correspondiente a la preferencia, i.e. la variable resultante de tr(ex:pref1). En cambio, la variable generada por la transformación del patrón (ctxt:Pattern) es una variable interna a la condición expresada en la preferencia y cuyas soluciones no son relevantes para la función match.
De esta forma, la función match de una demanda constituida por la preferencia anterior (ex:pref1) se expresa en nuestra aproximación de la siguiente forma:
SELECT ?var1
WHERE {
?var1 rdf:type dbpedia-owl:Film .
?var1 p:starring ?var2 .
?var2 p:born dbpedia:Spain .
}
Una demanda tiene preferencias opcionales y obligatorias, que como vimos en la sección, se corresponden con bloques de patrones de grafos diferentes dentro de la misma consulta y hay que tener en cuenta a la hora de generar las variables:
- Preferencias obligatorias: todas estas preferencias comparten la misma variable, ya que las soluciones de esta variable son los indiviudos del marketplace que cumplen las condiciones de interés del usuario.
- Preferencias opcionales: cada una de estas preferencias es un bloque opcional dentro de la consulta con su propia variable. Para relacionar las soluciones de una preferencia opcional con las obligatorias, la variable de cada bloque opcional se iguala con la variable de las obligatorias utilizando un FILTER, como se verá más adelante.
Consideremos una demanda formada por dos preferencias obligatorias y una opcional:
ex:dem1 rdf:type ctxt:Demand ;
ctxt:requiredPreference ex:pref1 ;
ctxt:requiredPreference ex:pref2 ;
ctxt:positivePreference ex:pref3 .
y que exprese las siguientes preferencias "Películas (ex:pref1) interpretadas por Tim Roth (ex:pref2) y mejor si son de gángsters (ex:pref3)":
ex:pref1 rdf:type ctxt:Preference ;
rdf:type dbpedia-owl:Film .
ex:pref2 rdf:type ctxt:Preference ;
p:starring dbpedia:Tim_Roth .
ex:pref3 rdf:type ctxt:Preference ;
skos:subject dbpedia:Category:Crime_films .
La aplicación de las reglas de transformación genera el siguiente resultado:
SELECT ?var1 ?var2
WHERE {
?var1 rdf:type dbpedia-owl:Film .
?var1 p:starring dbpedia:Tim_Roth .
OPTIONAL{
?var2 skos:subject dbpedia:Category:Crime_films .
FILTER (?var2 = ?var1) }
}
Como se aprecia en el resultado, las transformaciones de las preferencias obligatorias generan la misma variable, ?var1. En cambio, para las opcionales se utilizan nuevas variables que se igualan con la variable principal dentro del alcance del bloque OPTIONAL. Esto es necesario porque si utilizásemos la misma variable, ?var1, para representar tanto las preferencias obligatorias como las opcionales, no podríamos saber cuántas preferencias opcionales se cumplen.
Imaginemos que el marketplace formado por el siguiente catálogo de películas:
ex:Rob_Roy rdf:type dbpedia-owl:Film ;
p:starring dbpedia:Tim_Roth ;
skos:subject dbpedia:Category:Romantic_drama_films .
ex:Reservoir_Dogs rdf:type dbpedia-owl:Film ;
p:starring dbpedia:Tim_Roth ;
skos:subject dbpedia:Category:Crime_films .
Si evaluamos la consulta en este marketplace, obtenemos la siguiente tabla de resultados:
| ?var1 | ?var2 |
| ex:Rob_Roy | |
| ex:Reservoir_Dogs | ex:Reservoir_Dogs |
Con esta tabla podemos ver, por un lado, que la primera variable abarca todos los individuos del marketplace relevantes para el matchmaking (ya que cumplen las preferencias obligatorias). Por otro lado, la segunda variable ?var2 permite saber qué individuos de los que cumplen las obligatorias también cumplen las preferencias opcionales. Esto es importante porque la valoración final de la utilidad de un individuo se calcula a partir del número de preferencias opcionales que cumplen. Sin esta información, todas los individuos tendrían la misma puntuación.
Implementación de la función score
La función de utilidad, que hemos denominado score valora los individuos de un marketplace estableciendo relaciones de preferencias entre todos ellos. Esta función de utilidad es una función que, dada una demanda, asocia cada individuo del marketplace con un valor numérico en el intervalo [0,1], siendo 1 el valor máximo de utilidad y 0 la ausencia de utilidad de un recurso para una demanda particular.
En nuestro caso, el cálculo de la utilidad de un recurso se realiza en base a dos parámetros:
- La puntuación base de un recurso (μB(σ)), i.e., es la valoración a priori que tiene un recurso y que puede obtenerse por diferentes vías: valoración de los propios usuarios (esto es el caso de portales de comercio electrónico como eBay o Amazon, y de portales sociales como Youtube o LastFm) o valoración realizada por un grupo de expertos (como catálogos de monumentos realizados por patronatos de turismo, asociaciones culturales y artísticas, etc.).
- Las preferencias opcionales (Pi), i.e., qué preferencias opcionales cumple un individuo teniendo en cuenta la relevancia o importancia de éstas para el usuario. Hay preferencias que pueden influir más o menos en la valoración final de los recursos, ya que también las preferencias tienen asociado un valor de relevancia de acuerdo con los intereses del usuario (μ(Pi)). Este valor se expresa mediante la propiedad ctxt:utilityValue (véase la sección #Preference_definition). Nótese de nuevo que para que un usuario cumpla una preferencia opcional antes tiene que cumplir todas las preferencias obligatorias.
Finalmente, la función score utilizada para el cálculo de la utilidad de un recurso la definimos de la siguiente forma:
Matchmaking en EzWeb
El marketplace de EzWeb está constituido por gadgets que ofrecen diferentes capacidades a los usuarios. Las preferencias y las demandas de los usuarios en EzWeb se definen aplicando los patrones anteriormente explicados. El módulo de matchmaking utiliza las demandas de los usuarios para sugerirles gadgets. Este módulo accede a las demandas (instancias de ctxt:Demand) mediante el módulo de gestión del contexto y perfil del usuario.
Los gadgets se sugieren utilizando dos tipos de información. En primer lugar, información de las preferencias de los usuarios que expresan requisitos sobre las propiedades de los gadgets: si es un gadget de TV, lector RSS, si el gadget tiene un determinado tipo de input, quién lo ha desarrollado, etc.
En segundo lugar, existe información sobre el uso y valoración de los gadgets en el espacio social de EzWeb que puede ser utilizado de forma complementaria para las sugerencias de la plataforma:
- Gadgets recomendados por otros usuarios
- Gadgets que utilizan las personas de la red social de cada usuario
- Valoración de los usuarios de los gadgets
- Gadgets más utilizados por los usuarios
El uso de las demandas consigue que las sugerencias sean personalizadas para cada usuario, ya que cada usuario controla sus propias demandas y los conjuntos de preferencias que las definen.
Recomendación de gadgets
El uso de las técnicas de recomendación en el contexto de la plataforma EzWeb está principalmente enfocado a la sugerencia personalizada de gadgets. Estas recomendaciones se basan en dos aspectos. En primer lugar, en la descripción semántica de los propios gadgets y, en segundo lugar, en el perfil del usuario y sus preferencias. A continuación se describen los diferentes escenarios en los que las técnicas de recomendación pueden ser usada:
- Búsqueda de gadgets con una funcionalidad particular
La descripción de este escenario requiere del uso de la ontología que modela los gadgets en EzWeb y que se corresponde con el entregable 2.2 de este proyecto. Como esta ontología no está actualmente estable (en el momento en que se escribe este informe), las propiedades y clases que se van a utilizar son meramente informativas y deberían ser sustituidas posteriormente por sus homólogas normativas.
En esta categoría se realiza una comprobación de la funcionalidad deseada por el usuario y la funcionalidad propia de cada gadget. Para nuestro ejemplo hemos considerado una jerarquía de gadgets para estructurar la funcionalidad de estos, cada clase de esta jerarquía define un conjunto de gadgets con una funcionalidad determinada:
ezweb:VisualizatorGadget rdfs:subClassOf ezweb:Gadget . ezweb:TVGadget rdfs:subClassOf ezweb:Gadget . ezweb:MapGadget rdfs:subClassOf ezweb:VisualizatorGadget . ex:GoogleMapsGadget rdf:type ezweb:MapGadget .
Con esta jerarquía podríamos buscar los gadgets dentro del catálog que nos permitan visualizar mapas. En este caso concreto, el resultado de la búsqueda sería ex:GoogleMapsGadget.
- Búsqueda de gadgets más populares (más valorados y más utilizados)
En este escenario de búsqueda, el usuario está interesado en conocer los gadgets más significativos dentro del marketplace. La significatividad de estos recursos la proporciona el alcance de éstos en la comunidad de EzWeb. De esta forma, hemos identificado dos aspectos de los gadgets relevantes para medir su popularidad: 1) el número de usuarios que lo utilizan; 2) la valoración colectiva que se obtiene a partir de todas las puntuaciones de los usuarios. Esta valoración de la comunidad podemos considerarla la puntuación base de los gadgets: μB(gadget).
- Búsqueda de gadgets que utilicen conocidos de mi red social
En este escenario de búsqueda, de nuevo hay que tener en cuenta la información que se pueda extraer de la comunidad EzWeb. En este caso, los usuarios objetivo no es toda la comunidad, sino el subconjunto de usuarios que forman los conocidos del usuario. La información que podemos extraer de la red social de un usuario es el conjunto de gadgets que utilizan, cómo los valoran e incluso los diferentes pipings entre ellos.
- Búsqueda de gadgets por tags
Véase el entregable 2.3
Nuestra aproximación no considera todos estos escenarios de manera aislada, sino que permite integrarlos para obtener recomendaciones más ricas y más cercanas a las preferencias de búsqueda de los usuarios. Para más información acerca de la sugerencias personalizadas que el razonador del contexto es capaz de hacer, véase la sección 2.4
Sugerencias de gadgets para el wiring
Este escenario de aplicación del módulo de matchmaking es parcialmente diferente del anterior. En este caso, no estamos centrados en el usuario y en qúe gadgets se pueden recomendar utilizando su información de perfil y contexto, sino que estamos interesados en conocer la compatibilidad entre los gadgets. El objetivo es detectar de forma automática posibles pipings entre gadgets para ayudar y guíar a los usuarios a conectar los gadgets de su entorno de trabajo.
Se puede utilizar la funcionalidad que ofrece el razonador del contexto para descubrir la compatibilidad que hay entre las entradas (slots definidos en el template) y salidas (events definidos en el temaplate) de un conjunto determinado de gadgets. Para descubrir los gadgets compatibles hay que realizar una serie de transformaciones a partir de la descripción semántica del gadget para generar una demanda interpretable por el razonador del contexto.
Típicamente, dado un gadget cualquiera, la demanda se construye a partir de los events definidos en su template, es decir, de las condiciones de salida que tiene el gadget. A partir de aquí y con esta información representada adecuadamente, se buscan dentro del marketplace gadgets cuyos slots sean compatibles con dichos events. Por ejemplo, dado un entorno de trabajo con los siguientes gadgets:
ex:gadget1 rdf:type ezweb:AgendaGadget ;
ezweb:event ex:var1 ;
ezweb:event ex:var2 ;
ezweb:slot ex:var3 .
ex:var3 rdf:type ezweb:Variable ;
rdf:type foaf:Person .
ex:var2 rdf:type ezweb:Variable ;
rdf:type dbpedia:Address .
ex:var1 rdf:type ezweb:Variable ;
rdf:type dbpedia:Phone .
ex:gadget2 rdf:type ezweb:MapGadget ;
ezweb:slot ex:var4 .
ex:var4 rdf:type ezweb:Variable ;
rdf:type dbpedia:Address .
Si ahora queremos buscar gadgets compatibles con el ex:gadget1, un gadget de tipo agenda que permite obtener teléfonos y direcciones de personas, se aplicaría una transformación sobre su descripción semántica para obtener la siguiente demanda:
ex:deman_gadget1 rdf:type ctxt:Demand ;
ctxt:requiredPreference ex:pref1 ;
ctxt:positivePreference ex:pref2 ;
ctxt:positivePreference ex:pref3 .
ex:pref1 rdf:type ctxt:Preference ;
rdf:type ezweb:Gadget .
ex:pref2 rdf:type ctxt:Preference ;
ezweb:slot ex:pattern1 .
ex:pref3 rdf:type ctxt:Preference ;
ezweb:slot ex:pattern2 .
ex:pattern1 rdf:type ctxt:Pattern ;
rdf:type dbpedia:Address .
ex:pattern2 rdf:type ctxt:Pattern ;
ezweb:slot dbpedia:Phone .
A partir de esta demanda se genera la consulta SPARQL, tal y como se explicó en la sección #M.C3.A9todo_de_transformaci.C3.B3n_de_preferencias_en_recomendaciones_para_el_usuario, y se evalúa en el marketplace (que en este se corresponde con el conjunto: {ex:gadget1, ex:gadget2}). Como resultado de esta evalución obtenemos todos los gadgets ordenados por grado de compatibilidad y, además, cuáles son las conexiones entre ellos. Por ejemplo, dado el ex:gadget1 obtenemos la siguiente tabla de compatibilidades, generada a partir de los resultados de evaluación de la demanda:
| ezweb:Gadget | dbpedia:Address | dbpedia:Phone |
| ex:gadget1 | X | X |
| ex:gadget2 | V | X |