Aplicación empresarial de Ontologías Informáticas SWWS. 3ra Parte - (El Diseño)
En esta parte de la serie de post acerca de ontologías informáticas y como aplicarlas a la empresa, trabajaremos en el diseño de las formas mas interesantes en relación a utilizar este tipo de tecnologías en el ámbito empresarial. En particular, trabajaremos en el diseño conceptual y de arquitectura básica de Web Services Semánticos. Y como poder utilizarlos, que herramientas necesitamos, cual es mi propuesta de aproximación y que consideraciones deberemos tener para la fase de construcción a desarrollar en futuros post del tema.
En el post anterior escribí acerca de OWL-S y sus componentes como ontología para poder describir un Web Service. Ahora veremos en la practica como se utiliza para el descubrimiento de Servicios Web de forma automática. Para ello necesitaremos, para no partir desde cero, de alguna api o framework que provea distintos componentes para ello. Desde el repositorio de ontologías hasta el razonamiento de lógica descriptiva que también vimos anteriormente.
Mi mejor candidato para ello es Jena. Un Framework en Java OpenSource que provee la mayoría de los elementos básicos que necesitamos, y OpenSource por supuesto. Jena es un muy buen candidato ya que incluye muchas APIs y utilidades a requerir en trabajos de aplicaciones semánticas en Java. Adicionalmente Jena, no se limita a sus propias soluciones, incluye componentes de tipo Plug-In e interfaces con otras soluciones externas, de manera de poder conectar a Jena con un razonador independiente si se requiere. Por si los que incluye Jena no le satisfacen.

Aquí esta el diagrama base del Estándar de interfase que define Jena para comunicarse con razonadores o motores de inferencia, el mismo es llamado DIG (Description logic reasoner interface).
Otras gracias de Jena es que provee soporte para RDF, OWL y otros estándares de semántica informática, incluyendo un motor de SPARQL para consultas de este tipo llamado ARQ. Además Jena Incluye una variedad de tipos de razonadores; Transitivo, en base a reglas RDFS, para OWL, para DAML y un Razonador genérico para reglas. Dada esta potencia y flexibilidad en Jena, llegado el momento de requerir de inferencias, se tendrá que manejar el modelo de uso según la elección que tengamos. Para ello Jena provee el siguiente modelo en cuanto al uso de sus motores de inferencia.

Acompaño aquí un ejemplo de código java llamando componentes de la Api de Jena, utilizando el modelo OWL y su razonador, muy básico el ejemplo.
-
<br />Model schema = ModelLoader.loadModel("file:data/owlSchema.owl"); <br />Model data = ModelLoader.loadModel("file:data/owlData.rdf"); <br />Reasoner reasoner = ReasonerRegistry.getOWLReasoner(); <br />reasoner = reasoner.bindSchema(schema); <br />InfModel infmodel = ModelFactory.createInfModel (reasoner, data); <br />Resource nForce = infmodel.getResource("urn:x-hp:eg/nForce "); <br />System.out.println("nForce *:"); <br />printStatements(infmodel, nForce , null, null); <br />
En este ejemplo se busca inferir todo sobre la instancia "nForce".
Quiero detenerme en este punto para hablar de SPARQL , su uso y las confusiones que se producen al hablar de consultas, inferencias o reglas. Y que entendemos por razonamiento mediante motores de inferencia o razonadores de lógica descriptiva. Aunque ya hablamos de esto en el post anterior, me parece muy pertinente aclarar estos temas:
SPARQL puede ser usado para consultar a documentos en RDF Schema o OWL, de forma de filtrar ciertos individuos que cumplen con ciertas características especificas. De esta forma SPARQL puede generar los siguientes tipos de consulta:
Consultas de Selección: 
Consultas de Reestructuración: 
Consultas de Inferencia: 
La confusión que normalmente se da, es pensar que SPARQL es solo un lenguaje de consultas, lo anterior ocurre básicamente por desconocimiento y confusión respecto a otras distinciones como los razonadores (Pellet por ejemplo, o los que incluye Jena) que no nacieron en base a un motor de consultas semánticas. Pero debido a que SPARQL incluye entre sus primitivas la sentencia CONSTRUCT, que es la que permite devolver información de las nuevas relaciones posibles dado un cierto numero de condiciones. Es que también se entiende a SPARQL como capas de inferir conocimiento, de forma tal vez indirecta, pero sin lugar a dudas capas de realizar deducciones.
Por otro lado la distinción de Razonadores o Motores de Inferencia se asocia mas a aquellas herramientas que no se limitan solamente a inferir sobre documentos RDF o OWL, sino además a herramientas capaces de ofrecer razonamiento genérico basado en reglas, razonamiento transitivo, etc. Como por ejemplo las capacidades de razonamiento que posee Jena (Que indistintamente también tiene un motor de SPARQL).
Dejando a Jena y SPARQL de lado por un momento, veremos ahora el modelo de solución planteado para utilizar todas las piezas que hemos discutido anteriormente desde el inicio de esta serie de post. Veamos por ello la siguiente figura del diseño de uso de semántica informática en WebService, para el descubrimiento y uso automático de ellos:

En el podemos observar el distintas componentes y sus flujos, a saber:
a) La aplicación consumidora del Web Service.
b) El Web Service que se consumira y acoplara de forma automática a la aplicaciones
c) Un procedimiento en ciertos pasos para consultar a una entidad denominada. MatchMaker externa a la aplicación.
d) Un resultado de esta consulta en la forma de OWL-S Profiles
e) Una selección del mejor candidato.
f) Una instancia de máquina Virtual para invocar y enlazar el servicio web seleccionado.
En el diseño superior, no esta presente el repositorio de ontologías de servicios. Viendo la siguiente figura podremos visualizar esta componente y su relación con el repositorio de ontologías y el MatchMaker, las opciones de subselección en el cuadro siguiente están fuera del contexto de la aplicación solo de manera visual de forma de explicar mejor los pasos intermedios.

Hoy en día existen distintas iniciativas de soluciones MatchMaker a utilizar.En el ejemplo de la figura anterior, el MatchMaker se apoya en un motor de SPARQL para hacer sus inferencias, pero esto no es necesariamente obligatorio, podrían ser cualquier de los razonadores provistos por Jena. Pero para ilustrar mejor el diseño conceptual he puesto a SPARQL como entidad de inferencia.
En los próximos post ahondaremos en este diseño inicial, y revisaremos en detalle como Jena proveerá de la interfaz hacia una base de datos relacional para generar un repositorio o servidor de ontologías, y como participara del Matchmaker en detalle.
Javier Urrutia
Enviar a un Amigo |
Version para Impresion

(6 votos, promedio: 4.17 de 5)
Traducir al Ingles
Traducir al Español
Aplicación empresarial de Ontologías Informáticas SWWS. 3ra Parte - (El Diseño)





Hola, buen día, escribo de la ciudad Sonora México, y me gustaría que me porporcionaran información sobre JENA.
1.- Qué es?
2.- Cómo se implementas razonadores en Jena?
3.- Cómo so y qué tipo es el razonador en Jena?
4.- Cómo se integra a OWL?
agradeceré me ayude con esta información