\hyphenation{vi-sua-li-za-ción}
\chapter{Implementación de un Prototipo de \crowd{}}
%% \todo[inline]{Sacar lo referido a la implementación en código (HTTP, OWLlink, etc.).}
%% \todo[inline]{Mover diagramas UML en esta sección.}
%% \germanin{18-1-2017}{Podríamos hacer una sección nueva para implementación.} %% Listo, hecho capítulo. 24-02-2017
%% \subsection{Lenguajes de Programación a Utilizar}

% Ambos lados interactúan via peticiones HTTP asíncronas de forma tal que permite a los usuarios ver sus ontologías a medida que son modeladas y editadas.

%% \germanin{18-1-2017}{Lo general lo pondria como intro del capitulo.} %% Sinceramente, suena mejor como intro sin modificar nada. jajaja. 24-02-2017.

%% \chrisin{07-jun}{¿Mover todos los diagramas de flujo UML o algunos a la sección de diseño?} %% Ya está.

\label{sec:imp}
El prototipo de \emph{crowd} fue implementado basándonos en tecnología web. La elección de los lenguajes a utilizar corresponde a la funcionalidad de los módulos donde se utilizan, y son los siguientes:

\begin{itemize}
\item Del lado del cliente, utilizamos HTML, CSS, y Javascript. Estos lenguajes son los estándares para realizar páginas web con ciertos efectos y nos permiten aplicar la técnica AJAX, la que posibilita enviar al servidor el diagrama de forma asincrónica y de fondo, permitiendo al usuario seguir trabajando. JSON es el lenguaje utilizado para codificar el modelo y transmitirlo, como así también para recibir las respuestas del servidor; es de fácil lectura y altamente compatible con Javascript. % Además,  nos permite testear el servidor de forma ágil por las mismas ventajas y por ser fácil de escribir.

  Asimismo, decidimos utilizar el lenguaje CoffeeScript, ya que permite el desarrollo orientado a objetos utilizando clases en vez de objetos prototipados, sin perder la alta compatibilidad con Javascript, puesto que sus implementaciones proveen de un compilador que traduce los códigos desarrollados a éste último. La facilidad y agilidad que provee sumado a diversas soluciones ofrecidas por éste, permite trabajar en un código más limpio y entendible capaz de implementar los diseños UML que realizamos para nuestro cliente.
  
Además, se brindará al usuario de un subconjunto de primitivas de los diagramas de clases UML para que pueda elaborar su modelo conceptual gráfico. Para ello, es preciso utilizar una biblioteca gráfica implementada en los lenguajes de programación mencionados. En la sección \ref{sec:lib graf} se presenta una descripción de la biblioteca JointJS, como así también una comparación de varias bibliotecas gráficas estudiadas.

\item En el servidor, los diversos módulos se programan utilizando el lenguaje PHP usando los nombres de espacios (``\emph{namespaces}'') para distinguirlos. El \texttt{Razonador} se divide en dos partes: el razonador propiamente dicho el cual es un programa separado que puede comprender el protocolo OWLlink y la interfaz que permite ejecutar el programa, inicializarlo y entregarle la información. Actualmente, se utiliza el razonador RACER \cite{gbraun:racer:HaMo01a} aunque puede utilizarse cualquier otro si se modifica la interfaz adecuadamente.

\end{itemize}
%% \chrisin{13-07-2017}{Completar con la estructura del cap.}

En las secciones siguientes presentamos la biblioteca gráfica seleccionada para el cliente. Luego, se detallará el cliente para que mantenga una  representación interna del modelo conceptual del usuario. En la sección \ref{sec:protocolos}, se describe los protocolos usados, la API del servidor expuesta al cliente y los protocolos disponibles actualmente para la interacción con el razonador. En las secciones \ref{sec:mod_trad}, \ref{sec:gen_con} y \ref{sec:mod_raz} se explica cómo fueron implementados los módulos del servidor, sus entradas y salidas y las consideraciones que hemos tenido en cuenta. Finalmente, en la sección \ref{sec:ejemplos} se muestra un ejemplo con un modelo conceptual satisfacible y una modificación del mismo para hacerlo insatisfacible, mostrando así el funcionamiento del prototipo para ambos casos.

% razonadores relevados y los dos protocolo más conocidos que se deben utilizar para comunicarse con ellos. Luego, se explican estos últimos en más detalle, en especial OWL 2 y OWLlink que son los más actuales al momento de escribir este trabajo.



%% \chrisin{01-01-2017}{Detallar que se usa el desarrollo test-driven} %% No lo detallaremos aún.

%% --------------------------------------------------
%% Pegado desde el diseño


%\section{Tecnologías Existentes}
% \germanin{18-01-2017}{Estructura:
% 3.1 Sistemas de Razonamiento o Razonadores
% 3.2 Protocolos de Comunicación
% 3.2.1 DIG
% 3.2.2 OWLlink.
% 3.3 Comparación con otras herramientas.} %% La estructura ya está implementada 16/02/2017.
%% \germanin{18-1-2017}{En el transcurso de este trabajo hemos relevado y probado bibliotecas y herramientas existentes. Por un lado, bibliotecas, protocolos y herramientas necesarias para la implementación de crowd. Por otro, herramientas relacionadas, tanto gráficas como con interacción con los sistemas de razonamineto. Para dicha comparación se consideraron las ...} %% Ya modifiqué la intro.
% Se han relevado y probado una serie de bibliotecas y herramientas existentes que consideramos necesarias para la implementación del prototipo.
%% No sé que hacer con esta parte... hay que cambiarla...
% Éstas mayormente cumplen funciones relacionadas con las gráficas del modelo, la interacción con los sistemas de razonamiento, la creación web y el desarrollo de la ontología en DL.

% Una serie de herramientas y tecnologías fueron investigadas para proponer una arquitectura que reuse lo mayormente posible y adquirible en la actualidad.
% Un programa razonador es necesario para poder alimentarlo con el modelo conceptual y realizar consultas de consistencia, pero es preciso comprender sus limitaciones y los lenguajes computacionales existentes para representar el modelo conceptual de manera formal.


%\chrisin{16-02-2017}{¿Será necesario hablar de las bibliotecas gráficas relevadas en este capítulo o en el siguiente?}


%% \chrisin{16-02-2017}{Agregar algunas figuras, capturas de pantalla, ejemplos de uso o algún dato de algún razonador (Racer en especial).} %% DONE una captura de RacerPorter.

%% \todo[inline]{Posiblemente enviar la Figura \ref{fig:racerporter-example} y \ref{fig:racer-example} a un apéndice, a menos que haya una sección por cada razonador más importante relevado.} 
  

%% \chrisin{20-02-2017}{El uso de Racer en la Figura \ref{fig:racer-example} no me convence, es largo y no lo puedo acomodar mejor, ¿apéndice o fuera?}


\section{Biblioteca Gráfica}
\label{sec:lib graf}
% Fue preciso tomar ciertos criterios de comparación, estos se consideraron con especial atención en la biblioteca gráfica, su funcionamiento y agilidad, la facilidad que aporta al programar, sus capacidades para manipular las primitivas de los modelos, etc.


%% \chrisin{01-01-2017}{Chequear esta sección}
%% \germanin{18-1-2017}{Esta podría ser la primer sección del cap.} %% Listo, quedó. 24-02-2017.
Las características del cliente de \crowd{} son soportadas por una biblioteca gráfica realizada en Javascript denominada JointJS\footnote{\url{http://www.jointjs.com/}}, cuyo principal objetivo es el de proveer instrucciones sencillas para dibujar las primitivas y, actualmente, es utilizada en herramientas relacionadas para visualización de datos como \cite{gbraun:Mouromtsev15:ontodia}. Una revisión preliminar acerca de las diferentes bibliotecas gráficas y sus características demostró que este tipo de bibliotecas utilizan una de las dos principales tecnologías de dibujo denominadas Canvas y SVG, y por medio del uso de estos comandos básicos puede realizar diagramas como los de UML. También, pueden gestionar los eventos del usuario tales como el \emph{drag-and-drop}, entre otros.

En particular, JointJS presenta algunas ventajas claves: se enfoca en el dibujo de primitivas gráficas, provee \emph{plug-ins} para UML, EER, etc. y brinda la posibilidad de crear nuevos de forma simple. Asimismo, usa la biblioteca Backbone.js para dar estructura a la aplicación Web. Backbone.js es una biblioteca Javascript que asiste en el desarrollo de aplicaciones Web proveyendo una arquitectura Modelo-Vista-Controlador del lado del cliente.

Otras bibliotecas como Raphael\footnote{\url{http://raphaeljs.com/}}, Processing\footnote{\url{http://processingjs.org}}, p5js\footnote{\url{http://p5js.org}} proveen una interfaz más simple para dibujar primitivas como curvas y figuras geométricas, pero no otorga al desarrollador una API dedicada al dibujo de primitivas de forma directa desde el punto de vista que nosotros consideramos para dar soporte al lenguaje de modelado conceptual. Finalmente, jsPlumb\footnote{\url{https://jsplumbtoolkit.com/}} posee otro enfoque asistiendo al dibujo desde distintos tipos de conexiones entre elementos pero no provee primitivas para la creación de diagramas.


\section{Vista y Modelo del Cliente}
Basándonos en la arquitectura propuesta por Backbone.js y utilizando Coffeescript hemos desarrollado dos módulos del lado del cliente, la \texttt{Vista} que posee la representación visual del diagrama y el \texttt{Modelo} que contiene una representación abstracta de las primitivas aceptadas por la interfaz.

Dentro del aspecto visual, se consideran retazos de interfaces como el botón del semáforo, los paneles y demás elementos que utilizan la API de Backbone.js para poder funcionar.

Para el modelo, se ha realizado un diseño, mezclando los patrones ``Abstract Factory'' y ``Observer'' \cite{Gamma:Design_Patterns, Grand:Patterns_in_java}, que permite detallar las distintas primitivas gráficas que el usuario puede manipular considerando la posibilidad de utilizar otros lenguajes gráficos, como ORM ó EER, e incluso se pueden mezclar las de varios lenguajes en un mismo diagrama. La Figura \ref{fig:front-end UML} muestra el diagrama de clases que fue implementado utilizando Coffeescript, mostrando la posibilidad de utilizar varias primitivas de varios lenguajes proveídas por JointJS, por ejemplo las clases poseen un comportamiento similar para las de UML (\texttt{UMLClass} o \texttt{joint.shapes.uml.Class} en JointJS) con respecto a las Entidades EER. En el lado derecho de la figura, se observa las subclases de \texttt{Factory} que permiten la creación de estas primitivas. 

\begin{figure}
  \centering
  
  \includegraphics[width=\linewidth]{dia/GUIPatternMix.png}

  % \caption{This mix of patterns give support for more than one graphical language on the Front-End.}
  \caption{Diseño UML que podrá brindar soporte a más de un lenguaje gráfico en el Front-End.}
  \label{fig:front-end UML}
\end{figure}

\section{Protocolos de Comunicación}
\label{sec:protocolos}
El servidor expone al cliente una sencilla API basada en el el protocolo HTTP accesible por medio de direcciones URLs. Éstas pueden ser utilizadas con fines de desarrollo y debuging por medio de bibliotecas o de programas que pueden realizar solicitudes GET y PUT (por ejemplo: \texttt{wget} y \texttt{curl}).

La Figura \ref{fig:php-back-end-design} muestra dos sufijos de URL de dicha API: \verb+/query.php+ para realizar una consulta de satisfacibilidad y \verb+/translators/TRANSLATOR.php+ para solicitar una codificación del modelo a un lenguaje formal.
Las consultas, requieren como parámetro el modelo en formato JSON. Luego, un script en PHP, determinado por el sufijo, se activa para trasladar la información necesaria al módulo del servidor necesario.

Los razonadores que hemos relevado aceptan como entrada textos por medio de un archivo, una tubería o un socket escritos bajo protocolos estándares. Actualmente, los dos protocolos más importantes son DIG y OWLlink. Ambos, están basados en HTTP y XML y pueden usarse tanto para brindar la ontología como para realizar consultas acerca de ella. A continuación, se describirán estos protocolos. %% Estos razonadores, aceptan como entrada un archivo, una tubería o un socket bajo un formato bien definido.

\begin{figure}
  \centering
  
  \begin{tikzpicture}  
    \tikzstyle{every node}=[draw]
    %% \draw (0,0) rectangle (4,4);
    % \node (2,4) {Server};
    \node (Query) {Generador de Consultas};
    \node (Trans) [below=3.0 of Query] {Módulo Traductor};    
    \node (Owl) [below left=of Query] {\parbox{1.3cm}{\tiny Documento\\OWLlink}};
    \node (Raz) [left=0.5 of Owl, scale=1.5] {Razonador};
    
    %% URLs
    \node (URLQuery) [above=of Query, ellipse] {\tiny \url{/query.php}};
    \node (URLTrans) [below=of Trans, ellipse] {\tiny \url{/translators/TRANSLATOR.php}};

    \node[coordinate] (Up) [above=of URLQuery] {};
    \node[coordinate] (Down) [below=of URLTrans] {};
    
    \tikzstyle{every path}=[arrows=->, thick]
    \tikzstyle{every node}=[]
    \draw (Query) -- (Owl.north east)
    node[midway, below, sloped]{\tiny ASKs};
    \draw (Trans) -- (Owl.south east)
    node[midway, above, sloped]{\tiny OWL 2 + TELLs};
    \draw[arrows=<->] (Query) -- (Trans);
    \draw (Owl) -- (Raz);

    \draw (URLQuery) -- (Query); 
    \draw (URLTrans) -- (Trans);
    
    %% Internet side...
    \node[coordinate] (ClientUp) [right=3.0 of Up] {};
    \node[coordinate] (ClientDown) [right=3.0 of Down] {};
    \draw [dashed,arrows=-] (ClientUp) -- (ClientDown);

    %% Arrows from Internet side
    \tikzstyle{every node}=[]
    \node[coordinate] (ClientA) [right=4.0 of URLQuery] {};
    \node[coordinate] (ClientB) [right=3.0 of URLTrans] {};
    \draw (ClientA) -- node[above] {Petición HTTP} (URLQuery.east);
    \draw (ClientB) -- node[above] {Petición HTTP} (URLTrans.east);

    %% Top Labels
    \node at (Up) {Servidor};
    \node[right=of ClientUp] {Internet};    
  \end{tikzpicture}

  \caption{Diseño general del \emph{back-end} realizado en PHP.}
  \label{fig:php-back-end-design}
\end{figure}

%% \chrisin{07-jun}{¿Dejar DIG, resumirlo o sacarlo completamente?}
%% \chrisin{07-jun}{¿Está bien acá o pertenece a la sección introductoria como parte del estado del arte?}
\subsection{Protocolo DIG}
\index{DIG}
La interfaz DIG provee un acceso uniforme a los razonadores de lógica descriptiva definiendo un protocolo simple basado en HTTP PUT/GET, en conjunto con esquemas XML, que describen un lenguaje conceptual y las operaciones que lo acompañan.

La especificación de DIG 1.1, publicada en el año 2003 en \cite{gbraun:dig}, ofrece una expresividad que no es suficiente para capturar las ontologías OWL-DL en general. El lenguaje conceptual está basado en $\mathcal{SHOIQD}^-_n$, el cual consiste en operadores booleanos estándares ($\sqcap, \sqcup, \lnot$), restricciones cuantificadas universales y existenciales, limitadores de cardinalidad, jerarquía de roles, roles inversos, el constructor ``uno-de'' (``one-of'') y dominios concretos.

Herramientas, como por ejemplo ICOM \cite{DBLP:conf/dlog/FillottraniFT11}, utilizan únicamente este protocolo para comunicarse con el razonador. DIG se encuentra discontinuado al día de la fecha haciendo que estas herramientas queden sin soporte para los nuevos razonadores.

En la Figura \ref{fig:dig-example} donde se muestra, a modo de comparación, su representación en OWL. Más detalles se presentan en un caso de uso en \cite{dickinson04:_implem_exper_dig}.

\begin{figure}[h]
  \centering
  \begin{tabular}{|c|c|}
    \hline
    RDF/XML & DIG \\
    \hline
    \begin{minipage}{4.5cm}\scriptsize
\begin{verbatim}
<owl:Class rdf:ID=”A”>
  <owl:complementOf>
    <owl:Class rdf:ID=”B” />
  </owl:complementOf>
  <rdfs:subClassOf>
    <owl:Class rdf:ID=”C” />
  </rdfs:subClassOf>
</owl:Class>
\end{verbatim}
    \end{minipage}
            &
              \begin{minipage}{8cm}\scriptsize
                \vspace*{2mm}
\begin{verbatim}
<?xml version="1.0"?>
<tells
  xmlns=http://dl.kr.org/dig/lang
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
  xsi:schemaLocation="http://dl.kr.org/dig/lang
    http://potato.cs.man.ac.uk/dig/level0/dig.xsd">
  <defconcept name="http://example.org/foo#A" />
  <defconcept name="http://example.org/foo#B" />
  <defconcept name="http://example.org/foo#C" />
  <impliesc>
    <catom name="http://example.org/foo#A" />
    <catom name="http://example.org/foo#C" />
  </impliesc>
  <equalc>
    <catom name="http://example.org/foo#A" />
    <not>
      <catom name="http://example.org/foo#B"/>
    </not>
  </equalc>
</tells>
\end{verbatim}
                \vspace*{0.5mm}
              \end{minipage}
    \\
    \hline
  \end{tabular}
  \caption{Ejemplo de DIG y su representación en OWL.}
  \label{fig:dig-example}
\end{figure}

\subsubsection{Formato de los Mensajes}
La comunicación con el razonador se realiza por medio de mensajes codificados como funciones \TELL{} y \ASK{}.

La sintaxis para la petición \TELL{} contiene varios elementos \verb+tells+ que en sí mismos consisten en un número de enunciados ``tell'', los cuales son monotónicos (información que una vez proveída a la base de conocimiento no puede ser retractada ni removida). Deben ser realizadas en el contexto de una base de conocimiento particular y el orden de estos enunciados no es importante. 

En el caso de las peticiones \ASK{}, éstas contienen varios elementos \verb+asks+, los cuales se conforman de un número de enunciados ``ask'', donde cada uno posee un atributo identificatorio para una colección de preguntas, permitiendo la presentación de múltiples consultas en una sola solicitud.

El esquema XML que detalla a DIG, incluye una descripción de las respuestas esperadas por cada petición \ASK{}. Éstas, contienen un elemento \verb+response+, que a su vez posee un número de respuestas (una por cada consulta en la petición \ASK{} realizada). Cada respuesta particular posee un identificador que coincide con el de la consulta realizada.

% \begin{table}
%   \centering
%   \footnotesize
%   \begin{tabular}{|>{\tt}p{5cm}|p{10cm}|}
%     \hline
%     Elemento XML & Descripción \\
%     \hline
%     \hline
%     getIdentifier & Obtener desde el razonador una descripción de sí mismo, incluido el nombre, versión y un listado de elementos conceptuales del lenguaje DIG soportados. \\
%     newKB & Solicitar al razonador que reserver una nueva base de conocimiento y retorne un identificador único para la misma. Este identificador será utilizado para subsecuentes operaciones para inducar cuáles de las multiples bases de conocimientos serán referenciadas o consultadas. \\
%     releaseKB & Solicitar al razonador que libere la base de conocimiento referenciada junto con los recursos asociados a esta. Subsecuentes operaciones ``asks'' y ``tells'' sobre esta terminarán en error. \\
%     \hline
%     \multicolumn{2}{|c|}{Términos para los Conceptos}  \\
%     \hline
%     top & El concepto de universo \\
%     bottom & El concepto de vacío \\
%     catom & Introduce un concepto\\
%     and, or, not & Operadores booleanos para combinar expresiones conceptuales correspondiente a intersección, unión y complemento en \DL{} \\
%     some R E, all R E & Restricciones de propiedad existencial y universal \\
%     atmost n R E, atleast n R E & Restricciones de cardinalidad máxima y mínima \\
%     iset & Una expresión de clase que es exactamente la misma cantidad de individuos dados \\
%     stringmin, stringmax, stringequals,
%     stringrange, intmin, intmax, intequals, intrange & Conjunto limitado de expresiones de valor para dominios completos \\
%     ratom & Un nombre de rol \\
%     feature & Un nombre de rol funcional \\
%     inverse & Una expresión de rol indicando el inverso del rol dado\\
%     attribute & Un nombre de atributo \\
%     chain & Una composición lineal de nombres funcionales (``features'') \\
%     individual & Un nombre de individuo \\
%     \hline
%     \multicolumn{2}{|c|}{Verbos \TELL{}} \\
%     \hline
%     defconcept, defrole, deffeature,
%     defattribute, defindividual & Verbos de introducción de concepto \\
%     impliesc C1 C2 & Implicación de conceptos, cada C1 es también un C2 \\
%     equalc C1 C2 & Igualdad de conceptos \\
%     disjoint C1 C2 $\ldots$ Cn & Disjunción mutua entre las expresiones de conceptos dadas \\
%     impliesr R1 R2, equalr R1 R2 & Implicación e igualdad de roles; análogo a la implicación e igualdad de clases\\
%     domain R E, range R E & El rol R tiene como dominio o rango el concepto de la expresión E \\
%     rangeint A, rangestring A & Atributo A tiene como rango el tipo de dato concreto int o string \\
%     transitive R & El rol R es transitivo \\
%     functional R & El rol R es funcional \\
%     instaceof I C & El individuo I e una instancia de la expresión conceptual C\\
%     related I R I2 & El individuo I está relacionado con el individuo I2 por el rol R\\
%     value I A V & El individuo I tiene un valor concreto V para el atributo A \\
%     \hline
%     \multicolumn{2}{|c|}{Verbos \ASK{}} \\
%     \hline
%     allConceptNames, allRoleNames,
%     allIndividuals & Consultar por una lista de todos los nombres de conceptos, roles e individuos \\
%     satisfiable C & Consultar si el concepto C es satisfacible (si puede tener alguna instancia) \\
%     subsumes C1 C2, disjoint C1 C2 & Consultar si C1 subsume o es disjunto de C2 \\
%     parents, children, ancestors, descendants & Consultar por los sub o super conceptos para uno dado (padres/hijos) o por el cierre de todos los super o sub conceptos (ancestro/descendientes) \\
%     equivalents & Consultar por todos los conceptos equivalentes a uno dado\\
%     rparents, rchildren, rancestors, rdescendants & Consultar por los sub y super conceptos en la jerarquía de roles, de forma analoga que la jerarquía de clases. \\
%     instances C & Consultar todas las instancias del concepto C \\
%     types I & Consultar por todos los conceptos que pertencen a I \\
%     instance I C & Determinar si I es una instancia del concepto C \\
%     roleFillers I R & Consultar por todos los individuos que están en relación a I por medio del rol R \\
%     relatedIndividuals R & Consultar por todos los pares de individuos que son miembros del rol R \\
%     toldValues I A & Consultar por los valores del atributo A para el individuo I \\
%     \hline
%   \end{tabular}
%   \caption{Elementos XML disponibles para el protocolo DIG \cite{dickinson04:_implem_exper_dig}.}
%   \label{tab:DIG-XML}
% \end{table}

\subsection{Protocolo OWLlink}
\index{OWLlink}
OWLlink provee de una interfaz declarativa para razonadores basados en OWL. Se propone en \cite{conicet:Liebig_owllink:dig} como una evolución de la interfaz DIG 1.1, que en su borrador \cite{DBLP:conf/owled/BechhoferLLNPSTW06} fue originalmente presentado como DIG 2.0 pero posteriormente renombrado como OWLlink, para reflejar la importancia del cambio. Su intención es la de proveer a las aplicaciones clientes con un mecanismo liviano para acceder a las funciones de razonamiento proveídas por un servidor. Por estas razones, se utiliza este protocolo para la comunicación entre el razonador y el código PHP del servidor de \crowd{}, enviando y recibiendo documentos OWLlink con la representación del modelo en DL y las consultas necesarias para determinar su consistencia y obteniendo las respuestas en el mismo formato. De hecho, los módulos \texttt{Traductor a DL} y \texttt{Generador de Consultas} recrean la sintaxis del protocolo para generar una representación formal y computable.

Aunque la sintaxis y semántica de las primitivas de OWLlink están basadas en OWL 2 \cite{gbraun:owl2:overview}, los esfuerzos para dar soporte al núcleo del protocolo con respecto al parseo es reducido. Consecuentemente, OWLlink hereda todos los conceptos del lenguaje subyacente y las nociones de equivalencias estructurales de OWL 2. Sin embargo, no soporta ninguna de las partes de OWL 2 más allá de los niveles de axiomas.

Además, la especificación de OWLlink no resuelve los inconvenientes referidos a la conexión, transacción, autenticación, cifrado, compresión, concurrencia y múltiples clientes, entre otros. Pero, algunas de estas características pueden ser proveídas transparentemente por protocolos de accesos \cite{conicet:Liebig_owllink:dig}.

La estructura sintáctica de OWLlink se basa en un documento XML que debe cumplir con el esquema disponible en la URL \url{https://www.w3.org/Submission/owllink-httpxml-binding/owllink.xsd}. Básicamente, este esquema detalla algunos elementos de la Figura \ref{fig:owllink-objs}, dónde deben estar y qué otras etiquetas y propiedades pueden o deben incluir. Existen dos tipos de etiquetas raíz: \texttt{RequestMessage} para enviar información y para realizar consultas a un razonador y \texttt{ResponseMessage} que se utiliza en la salida del razonador para contener las respuestas de las operaciones solicitadas. Es necesario incluir a éstas etiquetas la propiedad \texttt{xsi:schemaLocation} con la URL donde se encuentra el esquema de OWLlink. En el caso del documento dado al razonador, típicamente se le solicita crear una o varias bases de conocimientos por medio de la etiqueta \texttt{CreateKb} asignándoles una URL como identificador, luego se le envía una ontología incorporándola dentro de una etiqueta \texttt{Tell}, se realizan consultas y, si la KB ya no es necesaria, se solicita que se la libere con la etiqueta \texttt{ReleaseKB}. En el Apéndice \ref{sec:apendice secuencias}, en la Figura \ref{fig:ej_mod_owllink_final} y en la Figura \ref{fig:ej_mod_resp}, se muestra un template de la estructura de la consulta descripta y un documento de respuesta respectivamente.

%% \chrisin{21-07-2017}{\textbf{TODO:} Explicar estructura, redactar nuevamente.} % Done
% En la sección \ref{sec:UML-a-DL} se presenta un método de traducción de los diagramas UML a lógica descriptiva. Luego, en la sección \ref{sec:mod_trad} se explica el diseño del módulo para la arquitectura propuesta que la llevará a cabo y utilizará OWL 2 y OWLlink como lenguaje para expresar la lógica descriptiva basado en una reescritura directa OWL 2-\DL{} mostrada en la Tabla \ref{tab:OWL-ref}. Finalmente, en la sección \ref{sec:ejemplos} se puede observar el proceso completo en conjunto con los códigos OWLlink que produce los ejemplos descriptos.

\begin{figure}
  \centering

  \includegraphics[width=13.5cm]{OWLlink-basic-objs.png}

  \caption{Objetos Básicos del Protoloco OWLlink \cite{conicet:Liebig_owllink:dig}}
  \label{fig:owllink-objs}
\end{figure}

\begin{figure}[h]
  \centering
  \begin{minipage}{11cm}
    \scriptsize
\begin{verbatim}
<?xml version="1.0" encoding="UTF-8"?>
<RequestMessage xmlns="http://www.owllink.org/owllink#"
  xmlns:owl="http://www.w3.org/2002/07/owl#" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.owllink.org/owllink# 
    http://www.owllink.org/owllink-20091116.xsd">
  <CreateKB kb="http://www.owllink.org/examples/KB_1"/>
  <Tell kb="http://www.owllink.org/examples/KB_1">
    <owl:SubClassOf>
      <owl:Class IRI="http://www.owllink.org/examples/myOntology#A"/>
      <owl:Class IRI="http://www.owllink.org/examples/myOntology#B"/>
    </owl:SubClassOf>
    <owl:SubClassOf>
      <owl:Class IRI="http://www.owllink.org/examples/myOntology#B"/>
      <owl:Class IRI="http://www.owllink.org/examples/myOntology#C"/>
    </owl:SubClassOf>
  </Tell>
  <IsClassSatisfiable kb="http://www.owllink.org/examples/KB_1">
    <owl:Class IRI="http://www.owllink.org/examples/myOntology#A"/>
  </IsClassSatisfiable>
  <ReleaseKB kb="http://www.owllink.org/examples/KB_1"/>
</RequestMessage>
\end{verbatim}
  \end{minipage}
  \caption{Ejemplo de código OWLlink.}
  \label{fig:owllink-example}
\end{figure}

\subsubsection{Tell y Aks}
OWLlink se basa en primitivas del lenguaje OWL 2 en lo que respecta a la representación de la ontología dentro de las peticiones \TELL{}. En la Figura \ref{fig:owllink-objs}, se presenta un diagrama de clases UML con los objetos básicos soportados por el protocolo, donde los nombres de todas las clases correspondientes a OWL 2 poseen el prefijo \texttt{ox.} para indicar que no están definidos en la especificación OWLlink. La composición ``axioms'' que observamos en el diagrama de clase indica que uno o más axiomas OWL 2 (\texttt{ox.Axiom}) deben estar contenidos en las etiquetas \texttt{Tell}.
Esto significa que el protocolo permite usar varios axiomas acerca de clases, propiedades y hechos de la especificación de OWL 2 \cite{w3c:owl2:structural_spec_20080411}, para representar la ontología en \DL{} sobre la que el razonador debe trabajar.

OWLlink posee un conjunto de consultas generales para obtener información de las entidades de la base de conocimiento, como así también de los hechos deducibles. Las llamadas preguntas básicas (``basic ask'' en inglés) sólo cubren las consultas más comunes con respecto a los axiomas dados e inferidos de la KB. OWLlink extiende considerablemente la interfaz de consulta proveída por DIG 1.1, además de estar más alineados con OWL 2. La Tabla \ref{tab:owllink-asks} muestra la interfaz definida en OWLlink para consultas \ASK{}s y el tipo de respuesta esperada. En la Tabla, la abreviatura ``\texttt{[O|D]}'' indica que existen dos instrucciones en vez de una, reemplazando con \texttt{Object} ó con \texttt{DataProperty} según corresponda.

En la Figura \ref{fig:owllink-example}, puede observarse un código OWLlink donde se le solicita al razonador la creación de una KB, se le incorpora mediante una petición \TELL{} una ontología simple de tres clases donde se cumple $A \sqsubset B$ y $B \sqsubset C$, usando una petición de tipo \ASK{} se consulta si la clase $A$ es satisfacible y finalmente se libera la KB. 

%% \germanin{18-1-2017}{Tendriamos que chequear si esto está OK acá o va en un apéndice o directamente no va. Se pone un ejemplo y listo.} %% Hablar con Laura.
%% \germanin{18-1-2017}{Mismo que DIG, quizás podríamos hacer un ejemplo genérico y el resto del estandar que vaya a apendice o directamente se saca.} %% ya se dió un ejemplo de OWLlink

\begin{table}
  \centering
  \footnotesize
  \begin{tabular}{|c|>{\tt}l|>{\tt}r|}
    \hline
    & Ask & KBResponse \\
    \hline
    \hline
    \multirow{7}{2cm}{Entidades de la KB}
    & GetAllClasses & SetOfClasses \\
    & GetAllClasses & SetOfClasses \\
    & GetAllObjectProperties & SetOfObjectProperties \\
    & GetAllDataProperties & SetOfDataProperties \\
    & GetAllAnnotationProperties & SetOfAnnotationProperties \\
    & GetAllIndividuals & SetOfIndividuals \\
    & GetAllDatatypes & SetOfDatatypes \\
    \hline
    \multirow{3}{2cm}{Estado}
    & IsKBSatisfiable & BooleanResponse \\
    & IsKBStructurallyConsistent & BooleanResponse \\
    & GetKBLanguage & StringResponse \\
    \hline
    \multirow{17}{2cm}{Esquema}
    & IsClassSatisfiable & BooleanResponse \\
    & IsClassSubsumedBy & BooleanResponse \\
    & AreClassesDisjoint & BooleanResponse \\
    & AreClassesEquivalent & BooleanResponse \\
    & GetSubClasses & SetOfClassSynsets \\
    & GetSuperClasses & SetOfClassSynsets \\
    & GetEquivalentClasses & SetOfClasses \\
    & GetClassHierarchy & ClassHierarchy \\
    & Are[O|D]PropertiesEquivalent & BooleanResponse \\
    & Is[O|D]PropertySatisfiable & BooleanResponse \\
    & Are[O|D]PropertiesDisjoint & BooleanResponse \\
    & Is[O|D]PropertySubsumedBy & BooleanResponse \\
    & Is[O|D]PropertyXXX & BooleanResponse \\
    & GetSub[O|D]Properties & SetOf[O|D]PropertySynsets \\
    & GetSuper[O|D]Properties & SetOf[O|D]PropertySynsets \\
    & GetEquivalent[O|D]Properties & SetOf[O|D]Properties \\
    & Get[O|D]PropertyHierarchy & [O|D]PropertyHierarchy \\
    \hline
    \multirow{15}{2cm}{Hechos}
    & AreIndividualsEqual & BooleanResponse \\
    & AreIndividualsDifferent & BooleanResponse \\
    & IsInstanceOf & BooleanResponse \\
    & GetTypes & SetOfClassSynsets \\
    & GetEquivalentIndividuals & SetOfIndividuals \\
    & Get[O|D]PropertyOfSource & SetOf[O|D]PropertySynsets \\
    & GetObjectPropertyOfFiller & SetOfObjectPropertySynsets \\
    & GetDataPropertyOfConstant & SetOfDataPropertySynsets \\
    & Get[O|D]PropertiesBetween & SetOf[O|D]PropertySynsets \\
    & GetInstances & SetOfIndividualSynsets \\
    & GetObjectPropertyFillers & SetOfIndividualSynsets \\
    & GetDataPropertyFillers & SetOfConstants \\
    & Get[O|D]PropertySources & SetOfIndividualSynsets \\
    & GetFlattenInstances & SetOfIndividuals \\
    & GetFlattenObjectPropertyFillers & SetOfIndividuals \\
    & GetFlattenObjectPropertySources & SetOfIndividuals \\
    \hline
  \end{tabular}
  \caption{Consultas \ASK{}s posibles para OWLlink. Tabla extraída de \cite{conicet:Liebig_owllink:dig}.}
  \label{tab:owllink-asks}
\end{table}


\section{Módulo Traductor}
\label{sec:mod_trad}
El módulo traductor se encarga de procesar un modelo realizado por el usuario y transformado a JSON por el cliente, para posteriormente obtener un  documento traducido a OWLlink, que será utilizado como entrada para el razonador. Esta transformación debe ser consistente con alguna codificación existente que transforme un modelo realizado bajo el lenguaje gráfico UML a una \DL{}, como el propuesto por \cite{DBLP:journals/ai/BerardiCG05}, y que es representada por JSON y OWL 2 \cite{gbraun:owl2:primer} respectivamente. El archivo OWLlink producido contendrá los comandos para inicializar una KB y los enunciados OWL 2 que representan la ontología. Luego se anexarán una serie de consultas creadas por el módulo \texttt{Generador de Consultas}. La Figura \ref{fig:php-back-end-design}
%% \chris{02-10-2017}{\textbf{Laura:} La figura \ref{fig:php-back-end-design} es la que quise decir, no la del diagrama de flujo.}
muestra que, por medio de una solicitud HTTP del cliente, el módulo \texttt{Traductor} y el módulo \texttt{Generador de Consultas} crean el documento OWLlink para que el módulo \texttt{Razonador} lo utilice.

Asimismo, se le brinda la posibilidad al usuario de incluir más restricciones de mayor expresividad que las del lenguaje gráfico utilizando la sintaxis OWLlink.  Dichas restricciones son anexadas al final de la representación formal generada por este módulo.

El módulo fue diseñado de modo tal que puedan implementarse a futuro diferentes codificaciones de UML a \DL{}, e incluso desde otros lenguajes de modelado conceptual gráfico a \DL{}. Asimismo, es posible expandir la implementación para producir otro formato de salida diferente al de OWLlink basado en XML, como por ejemplo un formato HTML con la representación textual y \emph{human-readable} (legible para los humanos) de la \DL{} resultante de la traducción. Estas ideas se reflejan en el diseño del diagrama de clases UML, presentado en la Figura \ref{fig:trans mod}, donde se muestra que del lado izquierdo están los métodos de transformación como subclases de \texttt{AbstractStrategy} y del lado derecho los diferentes formatos resultantes como subclases de \texttt{Document}.

La traducción que se realizó en \crowd{} desde UML a \DL{} se puede observar en la Tabla \ref{tab:resumen-UML-ALCQI} y se explicó en la sección \ref{sec:UML-a-DL}. Nótese que traducir \ALCQI{} a OWL 2 consiste en representar una primitiva en una notación inmediata (ver Tabla \ref{tab:OWL-ref}). Así, podemos traducir cada primitiva de UML a \ALCQI{} y finalmente representarla en un archivo XML en OWL 2.

La selección del tipo de estrategia a utilizar y el formato de salida se realiza creando instancias de la clase \class{BerardiStrategy} y \class{OWLlinkBuilder} respectivamente. Luego, la instancia del primero se comunica con la del segundo para darle instrucciones de qué debe incorporar en el documento XML, a su vez, éste último va generando el string OWLlink incorporando las etiquetas XML según las peticiones del constructor. En la Figura \ref{fig:diag_flujo_traducir} se puede observar de forma detallada el diagrama de secuencia del proceso de traducción.

% \begin{figure}
%   \centering \scriptsize
% \begin{verbatim}
% {"classes": [
%     {"attrs":[], "methods":[], "name": "Person"},
%     {"attrs":[], "methods":[], "name": "Employee"},
%     {"attrs":[], "methods":[], "name": "Employer"},
%     {"attrs":[], "methods":[], "name": "Director"},
%     {"attrs":[], "methods":[], "name": "Cellphone"}],
%  "links": [
%      {"classes": ["Employee", "Employer", "Director"],
%       "multiplicity": null,
%       "name": "r1",
%       "type": "generalization",
%       "parent": "Person",
%       "constraint": ["covering"]},
%     {"classes": ["Person", "Cellphone"],
%       "multiplicity": ["0..*", "0..*"],
%       "name": "hasCellphone",
%       "type": "association"}
% 	]
% }
% \end{verbatim}
%   \caption{Entrada en formato JSON para el módulo \texttt{Traductor}.}
%   \label{fig:ent-json}
% \end{figure}

\begin{landscape}
\begin{figure}[h]
  \centering

  \includegraphics[width=\linewidth]{dia/diag_flujo_traducir.png}
  
  \caption{Diagrama de secuencia detallando el proceso de traducción.}
  \label{fig:diag_flujo_traducir}
\end{figure}
\end{landscape}

\section{Módulo Generador de Consultas y Analizador de Respuestas}
\label{sec:gen_con}
El módulo \texttt{Generador de Consultas} se encarga de crear consultas que se envían al razonador para chequear la satisfacibilidad de la KB en general y de cada clase del modelo del usuario. Luego, estas se anexarán a la salida del \texttt{Módulo Traductor} para que el archivo final sea dado al razonador para su procesamiento. Para poder realizar su función, el módulo requiere del modelo creado por el usuario para crear una consulta OWLlink ``\texttt{IsClassSatisfiable}'' por cada clase del mismo, siguiendo la estructura de la Tabla \ref{tab:consultas} y reemplazando el texto ``NombreClase'' por el valor correspondiente.

En cuanto al módulo \texttt{Analizador de Respuestas}, su función es la de obtener los resultados generados por el razonador de las consultas enviadas, procesarlas y generar un texto en formato JSON para ser enviado a la interfaz del cliente.

El orden de las consultas es importante al momento de generarlas, puesto que el razonador basado en OWLlink emitirá una respuesta por cada consulta y en el mismo orden que se realizan. Por consecuencia, el analizador requiere de la consulta realizada para determinar cuál respuesta corresponde con cuál consulta y así generar un JSON apropiado indicando cuáles clases son inconsistentes. 

Un ejemplo de estas consultas con sus respectivas respuestas pueden verse en el Apéndice \ref{sec:apendice secuencias}, en las Figuras \ref{fig:ej_mod_queries} y \ref{fig:ej_mod_resp}. En el caso del \texttt{Analizador de Respuestas}, un ejemplo de  entrada y de salida se encuentra en el mismo apéndice, en la Figura \ref{fig:ej_mod_resp} y en la Figura \ref{fig:ej_mod_json_resp} respectivamente.

\begin{table}[h]
  \centering
  \begin{tabular}{|ccc|}
    \hline
    Consulta
    & OWLlink
    & Cantidad \\
    \hline
    KB Satisfacible
    & \begin{minipage}{7cm}\scriptsize
      \verb+<IsKBSatisfiable kb="http://localhost/kb1" />+ 
    \end{minipage}
    & 1 \\
    Clase satisfacible
    & \begin{minipage}{7cm}\scriptsize
\begin{verbatim}

<IsClassSatisfiable kb="http://localhost/kb1">
  <owl:Class IRI="NombreClase" />
</IsClassSatisfiable>

\end{verbatim}
    \end{minipage}
    & Uno por cada clase \\
    \hline
  \end{tabular}
  \caption{Consultas generadas por el módulo \texttt{Generador de Consultas}.}
  \label{tab:consultas}
\end{table}

\section{Módulo Razonador}
\label{sec:mod_raz}
Es preciso utilizar un razonador al que se le provee de la formalización del modelo conceptual y de sus consultas para determinar la satisfacibilidad del mismo. Por consiguiente, la implementación poseerá un razonador en funcionamiento de fondo. %  (véase la sección \ref{sec:mod_raz} para detalles de la conexión al razonador en la implementación en el prototipo).

Con respecto al \texttt{Módulo Razonador}, su objetivo es el de proveer de una interfaz para comunicarse con un programa razonador. Es decir, inicializarlo, proveerle de la información de entrada, ejecutarlo y recuperar su salida. En el diseño propuesto (Figura \ref{fig:uml_razonador}), la herencia definida sobre la clase \texttt{Conector} permite la selección de un razonador u otro.
% Como se puede observar, incorporar un nuevo razonador a la implementación consiste en la creación de una clase nueva que permita la ejecución del programa y/o la conexión al mismo.%% \chris{01-01-2017}{Explicar esto más detalladamente: HTTP, Parámetros, etc.} %% No hace falta.

Cabe aclarar que es posible utilizar otro programa razonador creando una subclase de \texttt{Co\-nec\-tor}. Ésta debe reimplementar los métodos heredados para que el programa razonador se ejecute y se configure, además de alimentarlo con la salida de los módulos anteriores por algún método IPC (Inter-Process Communication) existente.

En el prototipo de \emph{crowd} implementado se decidió utilizar únicamente el razonador RACER \cite{gbraun:racer:HaMo01a}, el cual puede trabajar con entradas en formato DIG \cite{gbraun:dig} y OWLlink \cite{conicet:Liebig_owllink:dig}. Para ejecutar el programa RACER el módulo utiliza la operación de PHP \verb+exec()+ ejecutando el proceso. Previo a esto, se prepara un archivo temporal con el texto OWLlink que ha sido generado por el \texttt{Traductor} y que será utilizado como entrada indicándole esto al razonador por medio de un parámetro de ejecución. Al finalizar, sus resultados serán capturados de la salida estándar del programa en una variable para que el siguiente módulo la procese. La Figura \ref{fig:racer-example} muestra cómo es el formato de un archivo de entrada, cómo se realiza el llamado al programa RACER
%% \chris{24-11}{Agus: Preguntar}
y su salida utilizando la línea de comandos y manteniendo la misma instrucción de ejecución dada a la operación de PHP.

El archivo ejecutable del razonador, proveído por la versión actual del prototipo, y el archivo temporal se encuentran designados en un directorio especial denominado ``run''. De esta forma, al momento de instalar el sistema, el administrador podrá proveerle los permisos necesarios para ejecutarse por el código PHP cada vez que éste último lo requiera.

\begin{figure}
  \centering
  \scriptsize
  \begin{minipage}{9cm}
\begin{verbatim}
> cat ../owllink-examples/complete.xml 
<?xml version="1.0" encoding="UTF-8"?>
<RequestMessage xmlns="http://www.owllink.org/owllink#"
		xmlns:owl="http://www.w3.org/2002/07/owl#" 
		xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
		xsi:schemaLocation="http://www.owllink.org/owllink# 
				    http://www.owllink.org/owllink-20091116.xsd">
  <CreateKB kb="http://localhost/kb1" />
  <Tell kb="http://localhost/kb1">
    <owl:SubClassOf>
      <owl:Class IRI="Person" />
      <owl:Class abbreviatedIRI="owl:Thing" />
    </owl:SubClassOf>
  </Tell>  <!-- Queries -->  
  <IsKBSatisfiable kb="http://localhost/kb1" />
  <IsClassSatisfiable kb="http://localhost/kb1">
    <owl:Class IRI="Person" />
  </IsClassSatisfiable>  
  <ReleaseKB kb="http://localhost/kb1" />
</RequestMessage>

> ./Racer -- -owllink ../owllink-examples/complete.xml 
<?xml version="1.0" encoding="UTF-8"?>
<ResponseMessage xmlns="http://www.owllink.org/owllink#"
                 xmlns:owl="http://www.w3.org/2002/07/owl#">
  <KB kb="http://localhost/kb1"/>
  <OK/>
  <BooleanResponse result="true"/>
  <BooleanResponse result="true"/>
  <OK/>
</ResponseMessage>
\end{verbatim}
\end{minipage}
\caption{Entrada y salida del razonador RACER usando el protocolo OWLlink.}
  \label{fig:racer-example}
\end{figure}

%% \chrisin{01-01-2017}{Chequear si se explica por qué se seleccionó Racer como razonador. Decir que es porque tiene compatibilidad con ICOM, usa ambos protocolos DIG y OWLlink y es Software Libre}
%% \todo[inline]{Explicar protocolo OWLlink y OWL 2 a usarse y cómo se envía a Racer.}

%% \todo[inline]{IMPORTANTE: ¡Falta el módulo analizador de respuestas!}

%% \germanin{18-1-2017}{Quizás podríamos hacer una sección sobre como está la tool ahora, describiendo la interface... mirar la sección de ICOM sobre el editor}

\subsection{Razonadores}
Para el caso del razonador a incorporar al prototipo, decidimos utilizar RACER debido a su disponibilidad en Internet, su licencia compatible con las Licencias Libres\chris{24-11}{Agus: preguntar. \bf Chequear},
% \chris{27-07-2017}{¿Es libre?}
la compatibilidad con ICOM \cite{conicet:journals/semweb/FillottraniFT12}, el soporte a protocolos de comunicación más actuales y la posibilidad de funcionamiento con ontologías lo suficientemente grandes para expresar modelos con muchas primitivas gráficas. Con respecto a los protocolos, optamos por la utilización de OWLlink y OWL 2 \cite{gbraun:owl2:overview} por ser los más actuales, por sus expresividades y por sus propiedades computacionales. %, sin embargo depende mucho de los razonadores que los implementen, 
En la Figura \ref{fig:racerporter-example} se muestra una consulta al razonador RACER, que está funcionando de fondo, por medio de un programa de interfaz gráfica denominado RacerPorter. % En la Figura \ref{fig:racer-example} se muestra la ejecución del mismo razonador en la línea de comandos, donde se muestra el archivo de entrada y luego se ejecuta el razonador para que lo procese sin quedar en funcionamiento como un servicio de fondo. 

Existen varios razonadores disponibles en la actualidad que, en su mayoría, se comunican por medio de uno o varios de los protocolos estandarizados existentes. 
% Dos de los más importantes son DIG \cite{gbraun:dig} y OWLlink \cite{conicet:Liebig_owllink:dig}.
Ejemplos de estos razonadores son Pellet \cite{gbraun:Sirin:2007:Pellet}, RACER y RacerPro \cite{DBLP:journals/semweb/HaarslevHMW12}, TopBraid \cite{gbraun:tool:TopQuadrant2011} (el cual también es un entorno de desarrollo completo) y aún más que se encuentran listados por la W3C en la siguiente URL: \url{https://www.w3.org/2001/sw/wiki/Category:Reasoner}. Si bien, la implementación del prototipo no cuenta con el soporte de estos razonadores, es posible utilizarlos en conjunto con RACER desarrollando un adaptador en PHP.

\begin{landscape}
\begin{figure}
  \centering
  \includegraphics[width=\linewidth]{Racer.png}
  \caption{RacerPorter, la interfaz de RACER mostrando una ontología y consultando la consistencia de la misma.}
  \label{fig:racerporter-example}
\end{figure}
\end{landscape}

%% \chrisin{13-07-2017}{Agregar konclude} 

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "../../tesis"
%%% TeX-PDF-mode: t
%%% coding: utf-8-unix 
%%% End: 
