Catágolo

Plan de Trabajo

1. Definición de Arquitectura de Alto Nivel del catálogo. (#47)
2. Diseño del catálogo.

1. Definición del modelo de datos. (#48)
2. Definición del modelo de clases.
3. Diseño inicial de la interfaz de usuario.
4. Diseño del API REST para el acceso al modelo del catálogo. (#50)

3. Implementación del modelo de datos con Dyango/Python. (#49)
4. Implementación del catálogo. (#51)

1. Contexto.
2. Agregar gadgets a la plataforma.
3. Agregar gadgets al catálogo.
   1. De forma manual.
   2. Con formulario.
   3. De forma automática.

5. Implementación de un entorno de etiquetado. (#52)
6. Añadir funcionalidad de búsqueda al catálogo.

1. Sencilla (#53).
2. Semántica.

7. Implementar sistema de aportación de conocimiento libre (wiki). (#54)

Arquitectura de Alto Nivel

A continuación se muestra la Arquitectura de Alto Nivel correspondiente a el catálogo:

De la arquitectura podemos distinguir 3 módulos:

• CatalogFeedback: es el módulo a través del cual se relaciona el catálogo con la plataforma. La información asociada a el gadget de la plataforma tiene que llegar a este módulo del catálogo, en el que se tendrán las distintas preferencias de los distintos gadgets de los usuarios. Este módulo se encarga, por tanto, de gestionar la información que se genera al utilizar los usuarios los recursos en la plataforma. Gestiona, eminentemente, las relaciones entre UserTag? y User (espacio de etiquetas de Usuario). La información de feedback que gestiona este módulo, es útil para mejorar la precisión del módulo de etiquetado (Tagger). Además, cada vez que el usuario etiqueta un recurso en módulo Tagger, produce información que debe gestionar el módulo de Feedback y actualizar en el SubmodelContextual, el contexto del usuario para que se tenga en cuenta para futuras búsquedas. Por tanto, este módulo tiene relación tanto con el SubmodelTagger como con el SubmodelContextual.

• Tagger: es el módulo encargado de etiquetar los distintos recursos, además de asociar el concepto/s correspondiente/s a un recurso (en base a sus etiquetas) y recomendar posibles etiquetas para un recurso. También exportará las etiquetas asociadas a un concepto. En general, será el modulo encargado de gestionar las relaciones entre Conceptos, UserTags? y Recursos (Espacio de Etiquetas de Recursos).

• ContextMatcher: realizará el encaje de los contextos de usuario y de recursos. En una primera versión inicial, los contextos se definirán por etiquetas ContextMatcher realizará la búsqueda comparando las etiquetas que introducimos en el buscador y las propias del contexto del usuario, con las etiquetas con las que están definidas en el contexto de los recursos. Por lo tanto, este módulo se relaciona con el submodelo que tiene en cuenta las entidades "Context", "Resource" y "User", es decir, comparará que coincidan las etiquetas referentes al contexto del recurso y las referentes al contexto del usuario.

Además de estos módulos, la plataforma se comunica con el módulo Feedback del catálogo para enviarle la información de su Feedback, habiendo por tanto, la información de los feedbacks de todos los usuarios referentes a todos los recursos dados de alta en el catálogo. También comentar que el módulo ContextMatcher, presenta al usuario los resultados de las búsquedas sensibles al contexto y el que finalmente, tras elegir el usuario un recurso en concreto, el que agrega dicho recurso a la plataforma.

Interfaces entre módulos funcionales

A continuación, se puede ver una primera versión de lo que sería la interacción entre los distintos módulos:

Hay 3 módulos: Tagger, ContextMatcher y CatalogFeedback. Estos módulos son los que interaccionan con el SubmodelTagger y el SubmodelContextual, también se puede ver la actuación de la plataforma y el usuario final sobre el catálogo.

Por un lado, la plataforma es la que le pide al módulo Tagger:

• que le devuelva las etiquetas relacionadas con la etiqueta que se le proporciona.
• que le devuelva el concepto relacionado con la etiqueta que le proporciona.
• que le devuelva las etiquetas relacionadas con la etiqueta que le proporciona, junto con un criterio y un valor asociado. Por ejemplo, etiquetas relacionadas con coche, criterio=idioma y valor=inglés. En este caso devolvería las etiquetas que hubiera almacenadas con esas características como car,...

Una vez que el usuario ha elegido la etiqueta, el concepto asociado a esa etiqueta,... le dice al módulo Tagger:

• que actualice las etiquetas pertenecientes a ese usuario, para ese recurso concreto, con la etiqueta/s elegida/s por el usuario.
• que actualice el concepto asociado a las etiquetas pertenecientes a ese usuario, para ese recurso concreto, con el concepto elegido por el usuario.
• que actualice el criterio asociado a las etiquetas pertenecientes a ese usuario, para ese recurso concreto, con el criterio/s y el valor/s elegido/s por el usuario.

En estos dos casos, tanto si la plataforma pide al módulo Tagger, como si le dice al módulo que se actualice, dicho módulo tendrá que buscar o actualizar en la base de datos los campos correspondientes del SubmodelTagger. Una vez, que se ha producido algún cambio en el SubmodelTagger, se tiene que actualizar el módulo CatalogFeedback, para que tenga reflejado los cambios para futuras búsquedas. Antes de que se actualice con los cambios, cuando se pide al módulo Tagger que le recomiende etiquetas o conceptos, también debería mirar en el módulo CatalogFeedback por si hay información que pueda interesar para hacer una mejor recomendación. En el caso de que actualicemos el módulo CatalogFeedback habría que añadir unas flechas entre el módulo Tagger y éste, para guardar las elecciones que se han hecho de etiqueta-recurso para un usuario concreto y poder consultar el módulo Tagger para recomendar, no sólo mirar en el SubmodelTagger.

Por otro lado, la plataforma le pide al módulo ContextMatcher que le seleccione un recurso de los disponibles. El módulo ContextMatcher consulta en el SubmodelContextual y en una primera versión. comparará las etiquetas del contexto de usuario y el contexto del recurso en busca de alguna que coincida. En versiones posteriores, se definirán contextos más complejos y se deberá seleccionar el recurso en función del contexto que mejor se adapte a la búsqueda realizada. En el módulo CatalogFeedback también consulta por si hay información relevante que le interese. En función del resultado ofrecido con la lista de recursos disponibles que más se adecúa a la búsqueda realizada, se añade el recurso deseado a la plataforma. Es decir, el módulo ContextMatcher muestra los resultados al usuario, que es el que elige que recurso añade a la plataforma y este mensaje se lo manda el módulo ContextMatcher a la plataforma.

Las modificaciones que se producen en el recurso, como que se actualice, se borre o se actualicen los contextos tanto del usuario como del recurso, son mensajes que manda la plataforma al módulo CatalogFeedback y este módulo se encarga de actualizar la base de datos correspondiente al SubmodelContextual.

Por último, si se acepta este modelo, habría que modificar la arquitectura para que tuviera las mismas entradas y salidas que se pueden ver en este modelo. También habría que añadir la entidad feedback en el modelo de datos.

Modelo de Datos

Como podemos ver, tenemos una entidad recurso, que tendrá una serie de atributos importantes que paso a describir a continuación:

• Name: será la clave primaria junto con vendor y version y contendrá el nombre del recurso, por tanto, no podrá haber 2 recursos con el mismo nombre de recurso para el mismo autor de dicho recurso y la misma versión.
• Vendor: será el creador o autor del recurso.
• Version: contendrá la versión del recurso.
• Description: tendrá la descripcion que el autor del recurso quiera asociarle. Información que pueda ser útil a futuros usuarios sobre la utilidad del recurso. La información que usuarios del recurso (no el vendor) quieran almacenar sobre la utilidad del recurso, posibles fallos o mejoras...esta información irá contenida en la wiki del recurso.
• UriImage?: tendrá la imagen asociada al recurso.
• UriWikiPage?: contiene la uri de la página de la wiki que tenga asociada el recurso. En esta página es donde habrá información del recurso que cualquier usuario que use el recurso puede escribir y actualizar. Información que le será útil a otros usuarios que puedan estar indecisos acerca de la utilidad, modo de utilización,... del recurso.
• UriTemplate?: contiene la uri del template.
• CreationDate?: contiene la fecha de creación del recurso. Las fechas de modificaciones realizadas por los distintos usuarios pueden estar en la página de la wiki asociada al recurso, ya que esta información se irá modificando con el tiempo.
• UriRSS: contiene la uri que hace referencia al RSS asociado a dicho recurso.

Hay 2 entidades ResourceContext? y UserContext? relacionadas con el recurso y el usuario respectivamente, porque tanto un usuario como un recurso tienen asociados un contexto. Como aspecto importante, cabe destacar que existirá un algoritmo de pattern-matching entre ambos contextos que mostrará unos recursos personalizados a cada usuario. El contexto inicialmente se modelará como una etiqueta y mediante el algoritmo citado anteriormente, el módulo ContextMatcher nos muestra aquellos recursos que estén relacionados con la búsqueda que hemos realizado, es decir, compara las etiquetas del contexto del usuario y las del contexto del recurso y devolverá aquellos recursos en los que se produzca acierto. Además, en el contexto del usuario, que en principio será único, se incluirá toda la posible información generada por el usuario en su interacción con los recursos (es decir, lo que llamábamos el submodelo Feedback).

Existen 2 entidades Tag-related: Concept y UserTag?. La entidad Concept se relaciona con la entidad UserTag? de la forma 1:N. Es decir, para cada conjunto de etiquetas que un usuario utiliza para definir un recurso, se le asocia un concepto. Por tanto, a un concepto le corresponden N etiquetas elegidas por el usuario. De esta forma se pueden recomendar otros recursos que estén categorizados con ese concepto, o ayudar a etiquetar un recurso mostrando etiquetas que ese usuario u otros han elegido para ese recurso o concepto,... En el modelo anterior, los atributos value y criteria estaban en la relación correspond no en las entidades. Para facilitar la comprensión del modelo, se ha decidido en esta versión guardar el valor y el criterio en la entidad UserTag?, ya que al ser una relación 1:N, podemos trasladar el atributo a la entidad sin que perdamos información.

• Un usuario crea tags "en bruto". Por ejemplo: coche, coches, COches, automovil, automóvil, carro, car, cars, etc
• Sin embargo, todas ellas corresponden el mismo concepto (Concept). Concept es el punto de unión entre Ontologías y Folksonomías.
• Un Concept y sus UserTags? asociados se relacionan por un criterio y un valor. Por ejemplo: criterio=idioma, valor=ingles define claramente la relación entre coche y car. Ahora mismo se me ocurre que pueden existir más de un criterio no? Por ejemplo la relación entre el concepto coche y el userTag cars sería: [(criterio: idioma, valor: ingles), (criterio: numero, valor: plural)].
• Al menos he identificado 3 criterios: idioma, género, número.

Por último, comentar la existencia de una relación ternaria entre el usuario, el recurso y las etiquetas, con las etiqueta de dicho usuario y dicho recurso. De esta forma, podemos saber con qué etiquetas ha etiquetado un usuario un determinado recurso.

• Imagino que las relaciones entre conceptos las querremos hacer con ontologías pero también se podrían definir relaciones entre Concepts: sinónimo, antónimo, dependeDe, etc.

Modelo de Datos Versión simplificada

Para esta primera versión hemos decidido usar un modelo muy simplificado que contiene solamente la información necesaria para las operaciones de añadir gadget a catálogo y a la plataforma. Para la autenticación hemos empleado la tabla User que crea Django automáticamente.

Clases Python para el modelo de datos:

from django.db import models
from django.contrib.auth.models import User

class Resource(models.Model):

short_name = models.CharField?(max_length=20)
author = models.CharField?(max_length=50)
size = models.CharField?(max_length=10)
license = models.CharField?(max_length=20)
version = models.CharField?(max_length=20)
description = models.CharField?(max_length=500)
gadget_uri = models.CharField?(max_length=500)
creation_date = models.DateTimeField?('creation_date')
last_modification_date = models.DateTimeField?('last_modification_date')
image_uri = models.CharField?(max_length=500)
wiki_page_uri = models.CharField?(max_length=500)
template_uri= models.CharField?(max_length=500)

class Admin:

pass

def unicode(self):

return self.gadget_uri

class UserTag?(models.Model):

id_gadget = models.ForeignKey?(Resource)
id_user = models.ForeignKey?(User)
uri= models.CharField?(max_length=500)
tag = models.CharField?(max_length=50)

class Admin:

pass

def unicode(self):

return self.id_gadget + " " + self.id_user + " " + self.tag