[Qualipso-a4] aperture y las ontologias

[Jose Gato Luis]

Alvaro del Castillo escribió:
> Hola!
> 
> El mar, 12-02-2008 a las 11:14 +0100, Jose Gato Luis escribió:
>> Buenas,
>>
>> he estado "trasteando" un poco con Aperture para ver como trata el tema 
>> de las ontologias para ver como adaptarlo a las nuestras, básicamente 
>> funciona de la siguiente manera:
>>
>>   * Contenedores RDF, con funciones para añadir y eliminar tripletas.
>>   * Cada ontología tiene un fichero .java con constantes de los 
>> predicados que definen esa ontología. Lo bueno de este punto, es que 
>> tienen una clase que pasándole un fichero RDF te genera el vocabulario 
>> que vas a necesitar, te genera constantes dentro de una clase: 
>> SIOC.java, NMO.java.
>>   * Cada crawler extrae información y añade tripletas RDF con los 
>> predicados extraídos anteriormente.
>>   * Cada extractor extrae información y añade tripeltas RDF con los 
>> predicados extraídos anteriormente.
>>
>>              copyAddress(getRecipients(message, RecipientType.TO), 
>> NMO.to, result);
>>              copyAddress(getRecipients(message, RecipientType.CC), 
>> NMO.cc, result);
>>              copyAddress(getRecipients(message, RecipientType.BCC), 
>> NMO.bcc, result);
>>
>> El problema es que todas estas etiquetas están fuertemente cableadas en 
>> muchas partes del código, y aperture es bastante modular, por lo que nos 
>> implicaría re-implementar cada implementación de los crawlers y los 
>> extractor.
>>
>> Lo suyo, es que estos predicados fueran abstractos  MIME.to y que el 
>> valor de esa constante dependiera según uses una ontologia u otra, 
>> aunque esto se complicaría en que predicados iguales en distintas 
>> ontologias tuvieran posteriormente valores distiontos. POr ejemplo, el 
>> predicado que define un TO, para una ontología tendrá un valor literal y 
>> para otra sera una URI. Aunque tal vez eso podría ser solucionado 
>> facilmente.
>>
>> Metiéndome en las tripas de Aperture, es fácil ver por que no soporta 
>> attachments, simplemente aún no analizan esta parte.
>>
>> Teniendo en cuenta que no existen unos predicados genéricos, los 
>> crawlers y extractor son dependientes de la ontología, con lo que para 
>> nuevas ontologías necesitas nuevos crawlers/extractors :( .
>>
>> O replicamos código, o hacemos un conversor de ontologías.
>>
> 
> Hmmm, el conversor de ontologías parece lo más limpio a estas alturas,
> sobretodo si queremos reutilizar Aperture y lo que vayan desarrollando
> nuevo. Si no, vamos a acabar con un "fork" que será difícil de mantener.
> El problema con esto es que tenemos un nuevo paso añadido que provocará
> problemas de rendimiento: la transformación de datos de unas ontologías
> a otras. Y lo que puede ser peor, que perdamos datos si sus ontologías
> no son suficientemente ricas.

no veo problema de perder información, modificar aperture para 
enriquecer sus extractors es bastante fácil, luego un parche y seguro 
que lo meten en sucesivas versiones, proponerles enriquecer el 
vocabulario de sus ontologias, imagino que será relativamente factible. 
Por ejemplo, para que soporte binarios en attachments.



> 
> Es un tema a analizar en Paris y presentar a las personas de la A3 para
> ver si nos pueden ayudar. Podríamos ir ya mirando parte de su trabajo,
> de la A3, pero me temo que no tenemos tiempo suficiente.
> 
> Hasta luego
> 
> 


-- 
José Gato Luis                   | Libre Software Engineering Lab (GSyC)
Tel: (+34)-914 888 105           | Universidad Rey Juan Carlos
jgato en gsyc.escet.urjc.es         | Edif. Departamental II - Despacho 116
http://libresoft.urjc.es/        | c/Tulipán s/n 28933 Móstoles (Madrid)