GoodRelations

GoodRelations es una alternativa al modelo centralizado de agregación de datos para e-commerce, utilizando RDFa y un esquema OWL. Un ejemplo de la opción centralizada es google base, que expone su propio esquema y diferentes formatos para publicar los datos.

Mi primera impresión al ver el esquema de goodrelations fue que era muy grande (27 clases, 62 propiedades, 43 individuales). Con el pasar de los meses, el esquema aparece cada vez más, primero por los asistentes del meetup, luego un par de entradas en el sitio de rdfa: primero bestbuy luego oreilly.

Utilizando el RDFa Distiller sobre la página de oreilly se obtienen el siguiente diagrama, donde existe un amplio uso de nodos blancos.



Uno de los beneficios de publicar los datos usando goodrelations es que se pueden aprovechar herramientas como SearchMonkey de Yahoo!


Clases y Prototipos

No sólo le costaba comprender que
el símbolo genérico perro abarcara tantos individuos
dispares de diversos tamaños y diversa forma;
le molestaba que
el perro de las tres y catorce (visto de perfil)
tuviera el mismo nombre que
el perro de las tres y cuarto (visto de frente).

Funes el memorioso
Jorge Luis Borges - 1944

Al igual que en muchos lenguajes de programación orientados a objetos (OOP), los vocabularios y ontologías RDF se modelan basados en clases, donde se distingue entre clase e individual. Existe otra forma de modelar, basada en prototipos, donde no se hace tal distinción y sólo existen objetos.

Como se señala en la documentación de javascript, en OOP un lenguaje basado en prototipos tiene la noción de un objeto prototipo, un objeto utilizado como una plantilla de la cual se obtienen las propiedades iniciales de un nuevo objeto. Cualquier objeto puede especificar sus propias propiedades, ya sea cuando se crea o en tiempo de ejecución. Además, cualquier objeto puede ser asociado como el prototipo de otro objeto, permitiendo que el segundo objeto comparta las propiedades del primer objeto.

Las ventajas de usar clases en la descripción de ontología y vocabularios son muchas, entre ellas:
  • Definir cardinalidad, rango y dominio de propiedades.
  • Definir reglas lógicas, como son: transitividad, simetría y equivalencia de propiedades.
  • Definir operadores de conjuntos, como son: unión, intersección, complemento, disjunción de clases.
En la práctica, todo lo anterior se obtiene al utilizar RDFS y OWL.

También existen desventajas al momento de modelar usando clases, ya que como se describe en "Classes vs. Prototypes - Some Philosophical and Historical Observations (1996)" se tendrá:
  • No todos los conceptos se pueden modelar con clases.
  • No existe una jerarquía de clases óptima.
  • Los diseños son basados en consensos.
  • Los modelos son sólo lo suficientemente buenos.
  • El proceso de construcción de la jerarquía de clases es inherentemente iterativo.
En el mismo documento, junto con describir los hechos filosóficos que justifican modelar usando prototipos, se plantean ejemplos notables que recalcan estos puntos:
Un ejemplo de un concepto que es difícil de definir en términos de propiedades compartido es "obra de arte". Ya que nadie puede definir límites claros para lo que es arte y qué no lo es, no hay ninguna clase general "obra de arte", que comparta propiedades comunes. La definición es subjetiva y depende en gran medida de la situación o el punto de vista.
Algunas personas viviendo cerca del Ecuador no pueden distinguir entre hielo y nieve, mientras los esquimales tienen numerosas palabras para distinguir entre distintos tipos de nieve. Los Dani, de Nueva Guinea, tienen sólo dos términos de colores básicos: mili (oscuro / frió) y mola (luminoso / cálido) que cubre el espectro completo, y tienen una gran dificultad en diferenciar entre colores con mayor detalle.

Es debido a la última de las desventajas de usar clases (donde se deduce que ningún vocabulario es estático), que se tiene la necesidad de replantear la forma en que se diseñan los identificadores de los vocabularios. Se propone que todas las propiedades se identifiquen en un archivo separado, como es el caso de Dublin Core, donde por ejemplo, se tienen las siguientes propiedades:
  • http://purl.org/dc/elements/1.1/Title
  • http://purl.org/dc/elements/1.1/Creator
La idea de prototipos para las ontologías no es nada nuevo, Sowa define la existencia de dos tipos de ontologías, las axiomatizadas y las basadas en prototipos. Muchas veces la creación de ontologías basadas en prototipos son generadas mediante técnicas de Machine Learning y se asocian a la Identificación de Entidades.

Resulta paradojal que durante gran parte del desarrollo de la tesis, estuve preocupado de como modelar "basado en clases" las implementaciones en javascript (un lenguaje OOP basado en prototipos) sin preocuparme que justamente la forma de modelar basado en prototipos debía llevarse al desarrollo de vocabularios. RDF, en su esencia, permite la descripción de Recursos sin necesidad de contar con una jerarquía de clases, el mejor ejemplo es el mismo Dublin Core, donde sólo se tienen propiedades aplicables a cualquier Recurso. Lo único que le faltaría a RDF, para hacer la equivalencia con los lenguajes de programación basados en prototipos, es "la realización de la conducta" (behavior reuse, a.k.a. herencia), se propone el uso de prototype:behaviorReuse para especificar "herencia al estilo de los lenguajes OOP basados en prototipos", así por ejemplo se podría tener el siguiente triple, donde se dice que un ipod hereda las propiedades del RioPMP300.
equipment:ipod prototype:behaviorReuse equipment:RioPMP300 .
Igualmente se deben considerar los antecedentes respecto a "sobre-escribir" valores de las propiedades y su eventual efecto en los razonadores.

El descubrimiento de estos antecedentes, me permiten entender de mejor manera algunos issues enfrentados al momento de modelar vocabularios y sobre el uso de la tecnología asociada, entre ellos se destacan:
  • ¿Cuando se de debe usar una clase y cuando una instancia?
    existe otra opción, que es usando prototipos.

  • ¿Existen distintos tipos de relaciones semánticas para establecer jerarquías?
    la relación parte-todo (part-whole) es sólo un tipo de estas relaciones, pero no siempre aplica un tipo de relaciones.

  • ¿Por qué sparql no utiliza clases?
    no es necesario cuando no se modela con clases.

  • ¿Cuando "liberar" un vocabulario?
    Ahora, ya que nunca se tendrá una versión perfecta y debe iterarse sobre la misma para llegar a un consenso.

  • ¿Por qué el vocabulario/ontología no es importante en el movimiento linked data?
    La visión de linked data es una visión tabular de la información, lo importante son las propiedades no las clases. En cierta forma se trata cada esquema o planilla como un prototipo.