Sampling Technique, Access and Data Collection

En este apartado se presentan un grupo de trabajos que utilizan las ontologías como método de representación de distintos aspectos de los workflows y los procesos de negocio que no están asociados a ninguna notación y lenguaje de representación, ni se centran en ningún dominio concreto.

En primer lugar hay que mencionar el trabajo de Eder y Missikoff [EdMi01] que es posiblemente uno de los primeros trabajos en aplicar ontologías a la representación de procesos. Concretamente, proponen una ontología que aporta el significado de los elementos, componentes y atributos de una serie de formularios utilizados en distintos procesos de una administración pública.

Con su propuesta pretenden ayudar en el desarrollo de formularios y la documentación de los datos de los procesos de la administración publica, gestionar el conocimiento para ofrecer sistemas automatizados de ayuda que den soporte a los usuarios en la comprensión del lenguaje utilizado en los formularios administrativos y dar soporte a la definición de mapeos entre formularios cuando los procesos administrativos involucran a diferentes organizaciones.

La ontología que proponen está organizada en torno a tres conjuntos agrupados en torno a un concepto principal de manera que el resto de elementos pertenecen a alguno de estos tres conjuntos. Estos tres conceptos principales son actores, objetos y procesos. Un actor es cualquier entidad relevante de dominio que es capaz de activar o realizar procesos. Por ejemplo, un ciudadano que solicita algo. Un objeto es una entidad pasiva sobre la que opera el proceso. Por ejemplo, un permiso de conducir. Por último, un proceso es una actividad orientada a la satisfación de un objetivo. Por ejemplo, renovar un permiso de conducir.

En segundo lugar se puede mencionar el trabajo de Jenz [Jenz03] que propone a nivel teórico un modelo de ontología en tres niveles como núcleo de una base de conocimiento que ayude a los analistas de negocio a definir procesos de negocio. Con esta base de conocimiento, su objetivo es que los analistas no tengan que utilizar un lenguaje de especificación de workflow tradicional puesto que los considera demasiado cercanos a los lenguajes de programación tradicionales. De este modo, será la base de conocimiento la que que sirva como fuente común para la generación de especificaciones de procesos de negocio en los distintos lenguajes específicos de workflow.

La primera capa de su ontología es la capa del núcleo y su objetivo es que sea aplicable a todas las industrias y organizaciones. Define los conceptos básicos que pueden encontrarse y necesitarse en cada organización, como por ejemplo recurso, rol, proceso de negocio, etc. La segunda capa es la de la industria y debe contener los conceptos que complementan a los del núcleo. Por ejemplo los documentos de negocio son típicamente específicos de la industria. Una factura en la industria del metal es bastante diferente de una factura en la industria de la alimentación. Por último, la tercera capa, la de la organización, será utilizada por una organización en particular para especificar conceptos propios de ella y que no tienen otras organizaciones de su ramo. Aunque la ontología del núcleo y la ontología de la industria no dejen mucho por definir, una organización es libre de definir cualquier cosa que ella considere necesario.

Otro trabajo destacable dentro de este grupo es el trabajo de Greco y colegas [GGPS04]. Utilizan ontologías para complementar la representación de los procesos complejos que estén sujetos a cambios de forma continuada. Su objetivo es facilitar a los analistas y diseñadores de estos procesos la reutilización, adaptación a los requisitos del cliente y la generalización de componentes de proceso existente. De este trabajo destacan varias ideas. En primer lugar, proponen separar la representación de los procesos en una ontología del dominio y otra de actividades. Con esta separación, pretenden hacer más fácil la explotación y reutilización del conocimiento del diseño. En segundo lugar, es interesante cómo, para asegurar que ninguna actividad intenta manipular datos que no se han producido en actividades previas, asignan a cada actividad unos parámetros de entrada y de salida a las actividades de manera que debe cumplirse que los parámetros de entrada de la actividad posterior son comunes a los parámetros de salida de la actividad inmediatamente anterior.

La tercera idea a reseñar es que afrontan la especialización de procesos desde una perspectiva que tampoco encaja en ninguna de las propuestas más conocidas de especialización y herencia de workflows y procesos mostradas anteriormente. La propuesta de Greco da más libertad al diseñador del proceso acerca del significado de esta. De este modo las posibles formas de especializar un esquema de proceso que ofrecen son las siguientes:

• especializar una actividad involucrada en el esquema original,

• _{borrar una actividad involucrada en el esquema original. Esta operación únicamente será legal}

• añadir una actividad al esquema original,

• _{especializar la ejecución añadiendo más enlaces entre las actividades o removiendo enlaces,}

• especializando la interfaz de la actividad asociada con el esquema original.

Dentro de este grupo, también destaca el trabajo de Vieira y colegas [ViCF04] [ViCF06] como uno de los más conocidos. Proponen utilizar ontologías de workflow para ayudar a flexibilizar la ejecución de los workflows cuando haya carencia de la suficiente información para realizarlo o no se disponga de todos los recursos requeridos. Concretamente, presentan una arquitectura de sistema de gestión de workflows que es dirigida por ontologías, las cuales definen las relaciones semánticas entre workflow, recursos, y usuarios.

En su propuesta, las ontologías juegan un papel esencial de dos formas interrelacionadas. En primer lugar, permitiendo trabajar con presuposiciones si la información requerida para continuar con el workflow no está disponible y, en segundo lugar, ayudando a encontrar subworkflows, recursos y usuarios cuando alguno de ellos no esta disponible o incluso cuando la definición de workflow es abstracta. La ontología que proponen define las subclases Workflow, Recurso y Usuario y, dentro de ellas tres, las subclases Abstracto y Concreto para representar objetos abstractos y concretos de cada tipo junto con las propiedades necesarias para relacionarlas.

Por su parte, Haller y colegas [HaOK06a] [HaOK06b] presentan la ontología m3po, Multi Meta

Model Process Ontology. Esta ontología permitía relacionar los servicios de los procesos de negocio

de las organizaciones que serían visibles externamente, y que serían ofrecidos por medio de interfaces de coreografía, con los workflows que realmente gestionan los procesos de forma interna en dichas organizaciones. Según ellos, el mayor obstáculo para conectar los workflows internos con las coreografías externas es la variedad de lenguajes de workflow, metamodelos de workflow y lenguajes de coreografía existentes. Para construir su ontología realizan un análisis de los modelos de coreografía y workflow existentes con la idea de que todos los modelos de workflow puedan ser representados en términos de esta ontología y todos los interfaces de coreografía extraídos de ella. Básicamente, en su ontología permiten definir dentro de un proceso actividades, datos y recursos conjuntamente. Definen m3po como esencialmente un meta modelo extenso para definir procesos de negocio, es decir, no ha sido diseñada para modelar procesos por sí misma. En resumen, m3po proporciona un esquema global que relaciona procesos internos y externos y que puede ser usado para extraer un modelo de coreografía de un modelo de workflow interno.

Por otro lado, Hepp y Roman [HeRo07] presentan una propuesta completamente teórica para representar distintos aspectos de BPM con ontologías con el objetivo de ser capaces de aplicar razonamiento para el descubrimiento y la composición de procesos. Lo más destacable de su propuesta es la creación de un conjunto de ontologías para representar lo que ellos denominan distintos ámbitos de un proceso de negocio: los procesos, sus especificaciones, la estructura

organizativa, la estrategia corporativa, las restricciones de los procesos, las funciones del negocio y los datos manejados por la empresa. Además, a todos estos ámbitos habría que añadir el ámbito específico del dominio de la empresa.

En la misma línea que el trabajo anterior se situaría el trabajo de Yao y colegas [YLHR07] [YaHa08] que presentan un sistema de workflow que utiliza ontologías para representar los distintos elementos en los workflows y así caracterizar el sistema de conocimiento del workflow de una manera uniforme. Su sistema está centrado en workflows para procesos de negocio colaborativos y la manipulación de sus datos. Su objetivo es que su sistema sea utilizado en aplicaciones orientadas al acceso a bases de datos. Con este fin dividen la representación en ontologías de su sistema en cinco grupos: ontologías de organización, ontologías de recursos, ontologías de proceso, ontologías de contexto y ontologías de interfaz.

Lo más destacables de esta propuesta con respecto a propuestas similares es que dentro de cada grupo de ontologías establecen tres niveles: el nivel abstracto estático, el nivel concreto estático y el nivel concreto dinámico. El nivel abstracto estático contiene las ontologías que principalmente describen atributos comunes básicos y las relaciones esenciales entre ellas. El nivel concreto estático contiene ontologías que representan los modelos y clases relacionadas del dominio concreto, de manera que pueden definir diferentes conjuntos de ontologías para extender el sistema a diferentes dominios de uso. Por último, el nivel concreto dinámico contiene las instancias de las ontologías de los niveles superiores.

Siguiendo en la línea de la representación separada de los distintos ámbitos de un proceso también estarían Filipowska y colegas [FHKM09]. Presentan un conjunto de ontologías organizacionales que proporcionan el vocabulario y las restricciones para describir en entorno en que los procesos son llevados a cabo desde la perspectiva de la organización.

Este sería uno de los tres conjuntos de ontologías que, según ellos, necesita la representación semántica de los procesos de negocios. A este conjunto habría que unir el conjunto de las ontologías de proceso y el del las ontologías específicas de dominio. De este modo, las ontologías de proceso son creadas para describir la estructura de un proceso mientras que las ontologías del dominio proporcionan la información adicional específica a una organización de un dominio dado.

Por último, Cabral y colegas [CaND09] presentan la ontología Business Process Modelling

Ontology (BPMO) que permite la anotación semántica de modelos de procesos de negocio de alto

nivel. Esta ontología forma parte de una propuesta para modelar procesos de negocio en el nivel semántico, integrando conocimiento acerca del contexto organizacional, las actividades del workflow y Servicios Web. De este modo, una descripción de un proceso en BPMO capturará el contexto del proceso modelado, el comportamiento del proceso (mediante constructores de flujo de control y de flujo de datos) y las actividades del proceso (mediante tareas).

2.6.2. Ontologías como complemento a notaciones y lenguajes de representación de workflows y