. UNIVERSIDAD DE CHILE FACULTAD DE CIENCIAS FíSICAS Y MATEMÁTICAS DEPARTAMENTO DE CIENCIAS DE LA COMPUTACiÓN CONTENIDOS PARA REPOSITORIO DE ESQUEMAS Y METADATOS- DOCUMENTOS ELECTRÓNICOS DE SERVICIOS PÚBLICOS MEMORIA PARA OPTÁR AL TíTULO DE INGENIERO CIVIL EN COMPUTACiÓN ESTEBAN MAURICIO ALMUNA HERRERA PROFESORA GuíA: MARíA CECILIA BASTARRICA PIÑEYRO MIEMBROS DE LA COMISiÓN: CLAUDIO GUTIERREZ GALLARDO MARISA GISELLE ERNST ELlZALDE l' SANTIAGO DE CHILE ENERO 2007
iv Índice.
1. Introducción. 1 1.1 Prefacio. 2 1.2 Motivación. 3 1.3 Objetivos. 4 1.4 Plan de trabajo. 4 2. Conceptos Básicos. 6 2.1 E-Government (Gobierno Electrónico). 7 2.2 Interoperabilidad. 8 2.3 XML. 8 2.4 Contenido. 8 2.5 Esquema (Schema). 9 2.6 Metadatos. 14 2.7 Ontología. 17 2.8 Repositorio. 22 3. Estado del Arte en gestión de esquemas y metadatos para e-government. 24 3.1 Análisis de casos reales. 25 3.2 Buenas prácticas. 33 4. Contenidos para Sistema Repositorio de esquemas y metadatos. 35 4.1 Buenas prácticas para el diseño de esquemas XML. 36 4.2 Estándar para metadatos. 41 4.3 Uso de ontologías. 45 4.4 Control de versiones de recursos. 50 4.5 Almacenamiento de datos del repositorio. 50 v
4.6 Validación de recursos. 53 4.7 Taxonomía de recursos. 55 4.8 Disponibilidad del sistema. 56 4.9 Control de usuarios. 57 5. Caso de Aplicación: Repositorio de esquemas y metadatos para el DCC. 59 5.1 Definición de esquemas. 60 5.2 Definición de metadatos. 62 5.3 Ontología. 63 5.4 Diseño de Repositorio para esquemas y metadatos en el DCC. 66 6. Conclusiones. 74 6.1 Conclusiones del trabajo realizado. 75 6.2 Propuestas de mejoras. 76 APÉNDICES. 78 APÉNDICE 1: ESQUEMA XML PARA SOLICITUD DE BECA DE PERMANENCIA. 79 APÉNDICE 2: ESQUEMA XML PARA SOLICITUD DE CONVENIO A HONORARIOS. 82 APÉNDICE 3: METADATOS PARA SOLICITUD DE BECA DE PERMANENCIA Y SOLICITUD DE CONVENIO A HONORARIOS. 85 APÉNDICE 4: ONTOLOGÍAS PARA DOCUMENTACIÓN EN EL DCC. 109 Bibliografía. 121 vi
Índice de Figuras. Figura 1: Árbol de clasificación de clases en el dominio de Vuelos. 19 Figura 2: Diccionario de clases en el dominio de Vuelos. 20 Figura 3: Arquitectura de e-gif. 27 Figura 4: Arquitectura del Framework de GovDex 29 Figura 5: Modelos de Referencia de FEA 31 Figura 6: Sintaxis en OWL para ontología. 46 Figura 7: Sintaxis en OWL para Clases. 46 Figura 8: Sintaxis en OWL para Propiedades. 47 Figura 9: Sintaxis en OWL para Relaciones Subclase-de. 48 Figura 10: Sintaxis en OWL para Relaciones Partición de subclase. 48 Figura 11: Sintaxis en OWL para Restricciones 49 Figura 12: Sintaxis en OWL para Instancias. 49 Figura 13: Sistema Repositorio de esquemas y metadatos - Administración de Datos. 51 Figura 14: Sistema Repositorio de esquemas y metadatos - Modelo relacional de Datos Administración de Sistema. 52 Figura 15: Sistema Repositorio de esquemas y metadatos - Modelo de Datos Administración de Repositorio. 53 Figura 16: Sistema Repositorio de esquemas y metadatos - Validación de recursos. 55 Figura 17: Sistema Repositorio de esquemas y metadatos - modelo de taxonomía 56 Figura 18: Estructura general Solicitud de Beca de Permanencia y Solicitud de Convenio a Honorarios. 61 Figura 19: Repositorio de esquemas y metadatos para el DCC Conceptos 64 Figura 20: Repositorio de esquemas y metadatos para el DCC Ontología. 65 Figura 21: Repositorio de esquemas y metadatos para el DCC Diseño interno. 67 Figura 22: Repositorio de esquemas y metadatos para el DCC Sistema interno. 68 Figura 23: Repositorio de esquemas y metadatos para el DCC Bases de Datos. 69 Figura 24: Repositorio de esquemas y metadatos para el DCC Taxonomía - Metadatos. 70 Figura 25: Repositorio de esquemas y metadatos para el DCC Administrador de Repositorio. 71 Figura 26: Repositorio de esquemas y metadatos para el DCC Administrador de Recursos. 72 Índice de Ejemplos. Ejemplo 1: Código XSD Documento de pedido de productos. 10 Ejemplo 2: Declaración de Namespace. 11 Ejemplo 3: Declaración de elementos del tipo Simple Type. 12 Ejemplo 4: Declaración de elemento del tipo Complex Type. 13 Ejemplo 5: Metadatos de fecha. 15 vii
Acrónimos. DCC: Departamento de Ciencias de la Computación Universidad de Chile. TICs: Tecnologías de Información y Comunicaciones. B2B: Business to Business; Comercio electrónico entre empresas. B2C: Business to Consumer; Interacción electrónica de Empresas a Consumidor. G2B: Governement to Business; Interacción electrónica de Gobierno a Empresas. G2G: Government to Government; Interacción entre organizaciones de Gobierno. W3C: World Wide Web Consortium. HTML: Hyper Text Markup Language; Lenguaje de Marcado de Hipertexto. DTD: Document Type Definition; Definición de Tipo de Datos. URI: Uniform Resource Identifier; Identificador Unificado de Recursos. XML: extensible Mark-up Languaje; Lenguaje Extensible de Marcado. XSD: XML Schema Definition; Definición de Esquemas en XML. RDF: Resource Description Framework; Plataforma de Descripción de Recursos. UTF: Universal Transformation Format; Formato Universal de Transformación. SHOE: Simple HTML Ontology Extensions. OIL: Ontology Inference Layer. DAML: DARPA Agent Markup Language. DARPA: Defense Advanced Research Projects Agency; Agencia de Investigación de Proyectos Avanzados de Defensa. OWL: Ontology Web Languaje; Lenguaje de Ontologías en Web. KIF: Knowledge Interchange Format. SQL: Structured Query Language; Lenguaje de Consulta Estructurado. CVS: Concurrent Versions System; Sistema Concurrente de Versiones. XLS: extensible Stylesheet Language; Lenguaje Extensible de Hojas de Estilo. viii
1 1. Introducción.
1.1 Prefacio. Dentro del desarrollo del Gobierno Electrónico, impulsado desde el mes de mayo del año 2001, el entonces Presidente de la República, Sr. Ricardo Lagos, emitió, el 3 de Junio del 2004, el Decreto Presidencial N 81, el cual establece al lenguaje XML como norma de representación de información en documentos electrónicos para el Gobierno de Chile. El mismo Decreto establece que "esta norma se aplica a los documentos electrónicos que se generen, intercambien, transporten o almacenen en o entre los diferentes organismos de la administración del Estado y en las relaciones de éstos con los particulares, cuando éstas tengan lugar utilizando técnicas y medios electrónicos [1]. Lo establecido en este Decreto tiene como propósito fundamental garantizar el funcionamiento integrado de los servicios públicos, tanto en los recursos como en los procedimientos que éstos utilizan. En particular se busca asegurar la interoperabilidad en la comunicación de datos; disponer de un marco semántico que asegure la interoperabilidad entre los diferentes organismos que utilicen documentos electrónicos y su entorno; proveer un mecanismo que permita a los diferentes organismos que utilicen documentos electrónicos, encontrarse, convenir en comunicarse, desarrollar servicios, contar con estándares de repositorios para registro y consulta de funcionalidades de intercambio, y facilitar la consulta por parte de los diferentes órganos de la administración del Estado, de la información que cada uno de ellos mantiene y maneja [1]. El Gobierno de Chile, a través de un conjunto de iniciativas relacionadas con el Gobierno Electrónico en las cuales participan distintos organismos tanto públicos como privados (por mencionar algunos ejemplo: Servicios Públicos en línea y Sistema de Información de Compras Públicas), busca mostrar experiencias paradigmáticas en desarrollos de documentación electrónica. En particular se pretende reunir a las personas interesadas en la adopción del Decreto 81 para sus organizaciones. Complementario a estas actividades, busca compartir motivaciones, intereses, experiencias y desafíos que permitan dar un aporte sustantivo al cumplimiento de los niveles definidos en la norma. Todo documento electrónico utilizado por cualquier servicio público consta de tres elementos fundamentales: estructura, contenido y forma de visualización; elementos que en el caso de los documentos en papel son indistinguibles, pero que en los documentos electrónicos pueden ir separados, lo cual permite trabajar con éstos de forma más eficiente. Para que dos o más servicios puedan comprender lo mismo acerca del contenido de un documento de uso común, es necesario que estos servicios tengan acceso a la descripción de la estructura del documento (lo que se conoce como esquema). Por otra parte, es de gran importancia establecer sólo una forma para que los distintos sistemas informáticos puedan procesar de manera automática documentos que incluyan elementos que utilizan abstracciones de tipos de datos (metadatos) para 2
su definición. En resumen, y conforme a lo establecido en el Decreto 81, un documento electrónico debe referenciar a un repositorio único de esquemas y metadatos. Por lo tanto, un repositorio de esquemas y metadatos debe cumplir con las siguientes dos tareas principales: 1- Centralizar los esquemas de documentos XML manejados por organismos gubernamentales, publicarlos, difundirlos y regular su unicidad. 2- Centralizar los metadatos, utilizarlos, difundirlos y regular su unicidad. Al contar con un repositorio de esquemas y metadatos, se puede acceder a utilización de definiciones de estructuras y de tipos de datos necesarios para la transferencia de documentos y para establecer criterios comunes de procedimientos de intercambio de los mismos. Un aspecto de gran relevancia en el desarrollo de un repositorio es la definición de sus contenidos. Esto involucra la definición de procesos, ontologías y buenas prácticas que permitan establecer el marco conceptual necesario para que las funcionalidades del repositorio respondan de forma efectiva y eficiente a los requerimientos de los servicios que lo utilicen. En esta Memoria se presenta el Proyecto de Título Contenidos para Repositorio de esquemas y metadatos Documentos Electrónicos de Servicios Públicos. Esta Memoria ha sido elaborada para obtener el Título Profesional de Ingeniero Civil en Computación. 1.2 Motivación. Existe un gran interés, por parte de organismos públicos y privados, de llevar a cabo distintas iniciativas que permitan, en conjunto, poner en práctica el plan de modernización del Estado relacionado con el Gobierno Electrónico, que fue impulsado desde el año 2001. Debido a este interés, se hace necesario contar con los elementos que gatillen estas iniciativas y tenga las capacidades de transformar estas iniciativas en sistemas concretos que sean de una real utilidad y aporte a la modernización del Estado. El propósito de desarrollar un repositorio surge de la necesidad de contar con un sistema de almacenamiento de esquemas y metadatos común y centralizado que pueda ser utilizado para la edición, transferencia y validación de documentos electrónicos correspondientes a los distintos servicios públicos, los cuales deben implementar su documentación electrónica bajo el estándar XML. Por otra parte, existe una motivación personal por formar parte de un proyecto que involucra el uso de tecnologías como XML, la cual en particular, brinda un conjunto de herramientas de gran utilidad para el desarrollo de sistemas que apoyen la gestión de documentos electrónicos. 3
Un punto a destacar en la realización de esta Memoria, y que puede generar un aporte real, es llevar a cabo un proyecto que puede tener un grado alto de impacto para otros proyectos de directa o indirecta relación, pero que tengan como fin último ser un real aporte al plan de Gobierno Electrónico llevado a cabo por el Gobierno de Chile. 1.3 Objetivos. El objetivo general de este Proyecto de Título es definir los contenidos necesarios para un sistema repositorio base de esquemas y metadatos, el cual será utilizado para almacenar descripciones de estructuras y tipos de datos para los documentos electrónicos utilizados por los servicios públicos del Gobierno de Chile. Los objetivos específicos para esta Memoria son los siguientes: Describir la estructura general y las características principales de los esquemas que deberán tener los documentos electrónicos utilizados por los servicios públicos, de acuerdo a la normativa existente. Describir la estructura general y las características principales de los metadatos que deberán respetar los datos contenidos en los documentos electrónicos utilizados por los servicios públicos. Definir las principales características y la estructura general de un repositorio base de esquemas y metadatos. Realizar un estudio de la situación actual en la gestión de esquemas y metadatos para documentación electrónica. En especial, estudiar las mejores prácticas ya existentes para el manejo de esquemas y metadatos, analizar casos exitosos relacionados con este tema. Definir los contenidos para el sistema repositorio base de esquemas y metadatos. En particular, definir la estructura tanto de los esquemas como de los metadatos que serán almacenados en este sistema, definir buenas prácticas para los procesos y componentes que se desean implementar para el funcionamiento deseado para el repositorio base, y establecer las ontologías necesarias para definir el esquema conceptual de la comunicación de los procesos internos del sistema y de la comunicación entre el repositorio y otros sistemas. Mostrar, a través de un caso de aplicación, cómo los contenidos propuestos en este Proyecto pueden ser aplicados para el diseño de un sistema repositorio de esquemas y metadatos específico para una repartición pública. 1.4 Plan de trabajo. El plan de trabajo definido para el desarrollo de la Memoria de Título consta de la siguiente secuencia de temas a abordar en el transcurso del Proyecto: Esquemas y metadatos: descripción y estructura. 4
Resultado: Descripción completa de esquemas y metadatos para e- Government. Ontologías: descripción y estructura. Resultado: Descripción completa de ontologías para e-government. Repositorio de esquemas y metadatos: características y estructura. Resultado: Descripción completa de Repositorio de esquemas y metadatos para e-goverment. Estudio de situación actual en gestión de esquemas y metadatos. Análisis de casos reales. Buenas prácticas. Resultado: Reporte de Estado del Arte en gestión de esquemas y metadatos para e-government. Definición de Contenidos de Sistema repositorio de esquemas y metadatos para los servicios públicos del Gobierno de Chile. Buenas prácticas para el diseño de esquemas. Propuesta de estándar para metadatos. Ontologías. Procesos. Resultado: Conjunto estructurado y formal de Contenidos para Sistema Repositorio de esquemas y metadatos para los servicios públicos del Gobierno de Chile. Desarrollo de Caso de Aplicación: Repositorio de esquemas y metadatos para el DCC. Conclusiones del trabajo realizado. 5
6 2. Conceptos Básicos.
2.1 E-Government (Gobierno Electrónico). E-Government se refiere al uso por parte de instituciones de gobierno de Tecnologías de Información (como redes, Internet o tecnología móvil) que tienen la capacidad de transformar las relaciones entre los ciudadanos, negocios, y otros organismos de gobierno [4]. Estas tecnologías pueden servir para una variedad de fines: mejor entrega de servicios de gobierno a los ciudadanos, relaciones mejoradas entre negocios e industria, mayor poder de acceso de información para la ciudadanía, o mejor administración pública. Los beneficios resultantes pueden ser: menos corrupción, mayor transparencia, y reducción de costos. Ejemplos de aplicaciones de e- Government son la declaración de impuestos a través de Internet, o los servicios de información y tramitación ofrecidos a través de los sitios web de las Administraciones Públicas. Tradicionalmente, la interacción entre un ciudadano o empresa y un organismo de gobierno toma lugar en una oficina de gobierno. Con la aplicación de tecnologías de información y comunicaciones es posible encontrar los centros de servicios más cercanos a los usuarios. Estos centros podrían ser representados en servicios que puedan ser accesibles mediante el uso de un computador personal en el hogar, en la oficina o en un cibercafé. Análogo al e-commerce, el cual permite a los negocios realizar sus transacciones entre sí de forma más eficiente (B2B) y acercar más clientes (B2C), e- Government permite la interacción entre gobierno y ciudadanos, gobierno y empresas (G2B) e inter-organizaciones de gobierno (G2G) de forma más amigable, conveniente, transparente y sin mayores costos. PRYME (Proyecto de Reforma y Modernización del Estado). El diseño de este proyecto se inspira en los principios de la transparencia, la eficiencia, la equidad y la participación, como base principal para el funcionamiento de un Estado democrático [5]. Consecuentemente, este proyecto es parte de un proceso que recoge y profundiza los esfuerzos realizados por los anteriores gobiernos en relación con el mejoramiento de la calidad de servicio a los usuarios del sector público. La principal preocupación del Proyecto de Reforma y Modernización del Estado, es la necesidad de contar con un Estado al Servicio de los Ciudadanos, de manera que él actúe y se perciba como cercano a las personas. El sentido de esta transformación apunta a construir un sector público que responda a una sociedad muy distinta a aquella en que las formas institucionales existentes se generaron. El nuevo contexto, requiere de un Estado con una relación previsora y proactiva en materia de desarrollo económico, de provisión de seguridad y de incorporación de la ciudadanía a los procesos públicos, y debe permitir optimizar las 7
posibilidades que ofrece la revolución tecnológica en cuanto a información y comunicaciones. 2.2 Interoperabilidad. Una definición básica de Interoperabilidad es "capacidad, conocimiento y acuerdo de dos o más partes de un todo para interoperar" [2].Aplicado a transferencia de datos, interoperabilidad es intercambiar información y comprender esa información de la misma forma en que el otro lo hace. Para conversar, son necesarias dos cosas: que haya un canal de comunicación, y que exista un lenguaje común de comunicación. Interoperabilidad es, la habilidad de transferir y utilizar informaciones de manera uniforme y eficiente entre varias organizaciones y sistemas de información [3], lo que significa, a fin de cuentas, "conversar". El concepto de interoperabilidad es clave para un gobierno electrónico integrado. Tiene que ver con interconectar a todos los servicios públicos para transformar al gobierno en un solo "ente", que sea capaz de brindar servicios al ciudadano de manera unificada, eficiente y transparente. 2.3 XML. XML es el acrónimo del inglés extensible Markup Language (Lenguaje de Marcado Extensible) desarrollado por el World Wide Web Consortium (W3C). Aunque una de las principales funciones con las que nace sería suceder al HTML, separando la estructura del contenido y permitiendo el desarrollo de vocabularios modulares, compatibles con cierta unidad y simplicidad del lenguaje, tiene otras aplicaciones entre las que destaca su uso como estándar para el intercambio de datos entre diversas aplicaciones o software con lenguajes privados. En cuanto a su estructura, XML se basa en documentos de texto plano en los que se utilizan etiquetas para delimitar los elementos de un documento. XML define estas etiquetas en función del tipo de datos que está describiendo 2.4 Contenido. Un contenido es una creación (de Ingeniería, de Arte, etc.) y sus componentes conceptuales. El contenido de un sistema es el conjunto de todos los elementos que forman el marco conceptual necesario para el desarrollo del sistema (de una aplicación, de una arquitectura, de una plataforma, etc.). 8
2.5 Esquema (Schema). XML Schema (XSD) es el sistema más usado en la actualidad en los sistemas de clasificación de datos en un soporte electrónico. Su principal funcionalidad es que permite definir la estructura de un documento XML y todo lo que ello implica, como por ejemplo, las restricciones y condiciones sobre los elementos del archivo. Los archivos XML Schema corresponden a tipos de documentos que son utilizados para especificar la estructura de cualquier documento XML que cumple con los estándares para XML establecidos por la W3C. Define, en otras palabras, la estructura lógica del documento. A continuación se muestra en el Ejemplo 1, un Archivo XSD que representa el esquema de un documento XML. El archivo que se muestra a continuación es la definición del esquema para un documento de pedido de productos. Declaración de Name Space <xsd:schema xmlns:xsd="http://www.w3.org/2001/xmlschema"> <xsd:annotation> <xsd:documentation xml:lang="es"> </xsd:documentation> </xsd:annotation> Elemento principal: hoja de pedido <xsd:element name="hojapedido" type="tipohojapedido"/> <xsd:element name="comentario" type="xsd:string"/> Elementos contenidos en la hoja: enviar, facturar A. <xsd:complextype name="tipohojapedido"> <xsd:sequence> <xsd:element name="enviara" type="direccioneeuu"/> <xsd:element name="facturara" type="direccioneeuu"/> <xsd:element ref="comentario" minoccurs="0"/> <xsd:element name="elementos" type="elementos"/> </xsd:sequence> <xsd:attribute name="fechapedido" type="xsd:date"/> </xsd:complextype> Elementos de ubicación geográfica. <xsd:complextype name="direccioneeuu"> <xsd:sequence> <xsd:element name="nombre" type="xsd:string"/> <xsd:element name="calle" type="xsd:string"/> <xsd:element name="ciudad" type="xsd:string"/> <xsd:element name="estado" type="xsd:string"/> <xsd:element name="zip" type="xsd:decimal"/> </xsd:sequence> <xsd:attribute name="pais" type="xsd:nmtoken" fixed="eeuu"/> </xsd:complextype> Elementos del producto a pedir. <xsd:complextype name="elementos"> <xsd:sequence> 9
<xsd:element name="elemento" minoccurs="0" maxoccurs="unbounded"> <xsd:complextype> <xsd:sequence> <xsd:element name="nombreproducto" type="xsd:string"/> <xsd:element name="cantidad"> <xsd:simpletype> <xsd:restriction base="xsd:positiveinteger"> <xsd:maxexclusive value="100"/> </xsd:restriction> </xsd:simpletype> </xsd:element> <xsd:element name="precioeeuu" type="xsd:decimal"/> <xsd:element ref="comentario" minoccurs="0"/> <xsd:element name="fechaenvio" type="xsd:date" minoccurs="0"/> </xsd:sequence> <xsd:attribute name="numproducto" type="sku" use="required"/> </xsd:complextype> </xsd:element> </xsd:sequence> </xsd:complextype> <!-- Stock Keeping Unit [Código de Almacenaje], --> <!-- un código para identificar productos --> <xsd:simpletype name="sku"> <xsd:restriction base="xsd:string"> <xsd:pattern value="\d{3}-[a-z]{2}"/> </xsd:restriction> </xsd:simpletype> </xsd:schema> Ejemplo 1: Código XSD Documento de pedido de productos. En un archivo XSD es posible establecer características de alto y bajo nivel sobre la estructura del documento XML y sus elementos, y combinar estas características. Como características de alto y bajo nivel se entiende lo siguiente: Alto nivel: Se encargan de ofrecer un significado semántico del contenido del documento. Analizan el contenido y extraen de él un significado. [6]. Bajo nivel: Son características más concretas del documento que están incluidas en los diferentes campos del Schema y se accede a ellas de manera directa [6]. A diferencia de otros estándares de definición de elementos para documentos XML, como DTD, XML Schema utiliza la sintaxis de XML. Además, permite la especificación de los tipos de datos. Otra ventaja de XML Schema sobre otras herramientas de esquemas para XML es su capacidad de abertura sobre su modelo de contenido; en otras palabras, es posible agregar elementos y atributos secundarios que hubieran sido anteriormente definidos en el esquema del documento. El modelo de contenido abierto brinda flexibilidad, porque posibilita la ampliación del vocabulario de los esquemas y seguir siendo capaz de crear documentos válidos. Esto ayuda a la reutilización de un 10
esquema, porque es posible usar un archivo XSD existente, al que le podría faltar algún elemento o atributo, para validar un nuevo documento XML. Estructura general de un archivo XSD. Todo archivo XSD cuenta con los siguientes objetos para que, en conjunto, entregue un esquema para documentos XML: Namespaces Simple Types Complex Types La sintaxis de un archivo XSD sigue el siguiente orden de declaraciones: Declaración de Namespace Elemento principal que representa el documento Elementos contenidos en el elemento principal Namespaces. De acuerdo a la definición de la W3C, un XML Namespace es una colección de nombres, identificados por una referencia URI, los cuales son usados en los documentos XML como elementos y atributos. [7] La codificación en XML Schema se basa en Namespaces. En cuanto a su funcionalidad, se puede hacer una analogía entre Namespaces para XSD con Packages para Java [6]. Cada Namespace contiene elementos y atributos que están estrechamente relacionados con el Namespace. Así, a la hora de definir un elemento o un atributo de un Namespace, siempre se creará una conexión entre los diferentes campos de éste. En el Ejemplo 2 es posible observar el código correspondiente a la declaración de un Namespace dentro de un documento XML Schema. <?xml version="1.0" encoding="iso-8859-1"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/xmlschema" version="0.1" xml:lang="es"> </xsd:schema> Ejemplo 2: Declaración de Namespace. Simple Types. Los elementos XML del tipo Simple Types pueden contener sólo texto. No pueden contener otros elementos o atributos. El hecho que contenga sólo texto puede ser algo engañoso. Sin embargo, el texto puede ser de diferentes tipos. Puede ser uno de los tipos incluidos en la definición para XML Schemas (boolean, string, date, etc.) o puede ser un tipo definido por el programador. Además, se puede agregar restricciones a un tipo de dato con el propósito de limitar su contenido.[8] 11
La sintaxis para definir un elemento de tipo Simple Type es: <xs:element name="xxx" type="yyy"/> donde xxx es el nombre del elemento e yyy es el tipo de dato del elemento. XML Schema tiene un conjunto de tipos definidos. Los más comunes son: xs:string xs:decimal xs:integer xs:boolean xs:date xs:time El Ejemplo 3 muestra el código correspondiente a la declaración de tres elementos de tipo Simple Type, que utilizan tipos de datos definidos por XML. <xs:element name="lastname" type="xs:string"/> <xs:element name="age" type="xs:integer"/> <xs:element name="dateborn" type="xs:date"/> Ejemplo 3: Declaración de elementos del tipo Simple Type. Complex Types. Un elemento del tipo Complex Type contiene otros elementos y/o atributos. Hay cuatro tipos de Complex Types[9]: Elementos vacíos Elementos que contiene sólo otros elementos Elementos que contienen sólo texto Elementos que contienen otros elementos y texto. La sintaxis para definir un elemento de tipo Complex Type es: <xs:element name="xxx"> <xs:complextype> <xs:sequence> <!--simple types contenidos-->... </xs:sequence> </xs:complextype> </xs:element> 12
,donde xxx es el nombre del elemento. El Ejemplo 4 muestra el código correspondiente a la declaración de un elemento de tipo Complex Type, que contiene dos elementos Simple Type. <xs:element name="employee"> <xs:complextype> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> Ejemplo 4: Declaración de elemento del tipo Complex Type. Esquemas en e-goverment. Al ser un lenguaje de definición de datos para documentos XML con sintaxis XML, XML Schema es el estándar establecido en la mayoría de los países del orbe para la definición de documentos electrónicos XML de servicios públicos. Un conjunto considerable de países que han implementado sistemas de e-government con XML como estándar para el desarrollo de documentos electrónicos, han seleccionado un estándar para la implementación de esquemas que siga con la sintaxis de XML, como es el caso de XML Schema. En el caso de Chile, el artículo 8 del Decreto Presidencial N 81 del año 2004, establece lo siguiente: El documento electrónico deberá ser codificado en formato XML v.1.1, y utilizar XML Schema para definir los esquemas de los distintos tipos de documentos. Cada esquema definido debe ser público y de libre acceso [1]. Esto establece el uso de XML Schema como estándar para documentación electrónica en los sistemas de e-government en Chile, y obliga a la difusión y libre acceso de los esquemas implementados, para así lograr el nivel de interoperabilidad definido en el Decreto N 81 mencionado. Esquemas e Interoperabilidad. Para alcanzar la interoperabilidad de servicios públicos en línea es imperativo que los servicios que participan en la transferencia de un documento electrónico cumplan con un conjunto de requisitos. Uno de esos requisitos, y quizás el más importante, es que los servicios puedan observar y comprender la estructura de los documentos a transferir. Para que esto sea factible, es necesario que los servicios puedan acceder de forma centralizada a estos esquemas. Guías para esquemas. Las guías consideran tanto experiencias de desarrollo como estándares de diseño, con lo cual se entrega como resultado, una lista exhaustiva de requerimientos y recomendaciones para diseñar esquemas bajo XML Schema. 13
En la actualidad existen distintas guías genéricas para diseño de esquemas, que abarcan los distintos aspectos involucrados en el desarrollo de archivos XSD (tipos de elementos, atributos, namespaces, etc.), y, en particular, algunos gobiernos han definido sus propias guías, adaptadas a sus sistemas de interoperabilidad de servicios para e-goverment (algunos ejemplos se mencionan en 3.1 Análisis de casos reales.). 2.6 Metadatos. Los metadatos son datos estructurados y codificados que describen características de instancias conteniendo informaciones para ayudar a identificar, descubrir, valorar y administrar las instancias descritas. En otras palabras, los metadatos son datos sobre los datos, esto es, información sobre la información misma [14]. Son datos descriptivos de otros datos. Sin bien no es tan distinguible, la diferencia entre metadatos y datos se marca principalmente en que los metadatos son datos con una estructura específica que permiten a éstos identificar instancias que representan datos u otros metadatos. Para disciplinas de las ciencias de la Computación como la recuperación de información o la web semántica, el concepto de metadatos entrega un enfoque importante para construir un puente sobre el intervalo semántico. Las investigaciones que se han centrado en análisis semántico de datos plantean el problema de comunicación entre humano y computador, cuando este último no comprende el significado completo de los datos que entrega el usuario. Una posible solución a este problema está en el uso de metadatos, los cuales describen cómo están relacionados los datos, además de categorizarlos. Es por esta razón que el uso más frecuente de metadatos está en la representación de conocimiento. En el Ejemplo 5 se muestran tipos de metadatos que son usados frecuentemente para la definición de formato de fecha, elemento muy utilizado en la elaboración de documentos electrónicos. 14
Fechas: Año: YYYY (ej: 1997) Año y Mes: YYYY-MM (ej: 1997-07) Fecha completa: YYYY-MM-DD (ej: 1997-07-16) Fecha completa con horas y minutos: YYYY-MM-DDThh:mmTZD (ej: 1997-07-16T19:20+01:00) Fecha completa con horas, minutos y segundos: YYYY-MM-DDThh:mm:ssTZD (ej: 1997-07-16T19:20:30+01:00) Fecha completa con horas, minutos, segundos y fracciones de segundo: YYYY-MM-DDThh:mm:ss.sTZD (ej: 1997-07-16T19:20:30.45+01:00) Donde: YYYY = año de cuatro dígitos MM = mes de dos dígitos(01-12) DD = dia de dos dígitos(01-31) hh = hora de dos dígitos(01-24) mm = minuto de dos dígitos(00-59) ss = dos dígitos de segundo(00-59) s = uno o más dígitos represando fracción de segundo TZD = designador de zona horaria(z o +hh:mm o -hh:mm) Ejemplo 5: Metadatos de fecha. Para clasificar metadatos, se consideran los tres siguientes aspectos [10]: Contenido: La subdivisión de metadatos por su contenido es lo más común. Se puede separar los metadatos que describen el recurso mismo de los que describen el contenido del recurso. Variabilidad: Según la variabilidad se puede distinguir metadatos mutables e inmutables. Los inmutables no cambian, no importa qué parte del recurso se vea. Los mutables difieren de los anteriores en que son modificables. Función: Los datos pueden ser parte de una de las tres capas de funciones: subsimbólicos, simbólicos o lógicos. Los datos subsimbólicos no contienen información sobre su significado. Los simbólicos describen datos subsimbólicos, es decir añaden sentido. Los datos lógicos describen cómo los datos simbólicos pueden ser usados para deducir conclusiones lógicas, es decir añaden comprensión. En cuanto al almacenamiento de metadatos existen dos opciones: depositarlos internamente en el mismo documento que los datos, o depositarlos externamente, en su propio recurso. En la actualidad es más frecuente la localización externa ya que hace posible la concentración de metadatos para optimizar operaciones de búsqueda. 15
Estructura de metadatos. Cada estándar de metadatos define la estructura de éstos, lo que implica que no haya una estructura única de metadatos. No obstante, los metadatos están estructurados por un mínimo de elementos tales como: título, autor, fecha de creación, etc. Para mostrar lo que puede ser la estructura de un metadato, se muestra la estructura para metadatos utilizada por UK GovTalk (detalles de UK GovTalk en 3.1 Análisis de casos reales.). La estructura de metadatos de UK GovTalk consta principalmente de los siguientes elementos [11] 1 : Accesibilidad: indica la disponibilidad y usabilidad del recurso a grupos específicos. Destinatario: la persona (o personas) para quien ha sido destinado el recurso. Agregación: el nivel de posición de jerarquía del recurso. Audiencia: categoría de usuario al cual se provee el recurso. Contribuidor: entidad responsable de hacer contribuciones al contenido del recurso. Cobertura: la extensión o alcance del contenido del recurso. Creador: entidad responsable de la creación del contenido del recurso. Fecha: fecha asociada con un evento en el ciclo de vida del recurso. Descripción: descripción textual del contenido de un recurso. Disposición: instrucciones de retensión y disposición para el recurso. Formato: la manifestación física o digital del recurso. Identificador: referencia no ambigua al recurso dentro de un contexto determinado. Lenguaje: lenguaje del contenido intelectual del recurso. Locación: ubicación física del recurso. Mandato: mandato legal u de otro tipo bajo el cual el recurso ha sido producido. Preservación: información para apoyar la preservación del recurso a largo plazo. Relación: referencias a recursos relacionados. Derechos: información acerca de los derechos sobre la producción del recurso. Fuente: referencia al recurso sobre el cual el recurso presente deriva. Estado: posición o estado del recurso. Asunto: tópico del contenido del recurso. Titulo: nombre asignado al recurso. Tipo: naturaleza o género del contenido del recurso. Además, cada elemento de un metadato cuenta con un nivel de obligación. Los cuatro niveles de obligación son: 1 El término recurso es el objeto representado por un metadato. 16
Obligatorio: el elemento debe tener un valor Obligatorio si es aplicable: el elemento debe tener un valor determinado si la información es aplicable. Recomendado: el elemento debería tener un valor si el dato esta disponible y si es apropiado para el metadato. Opcional: el elemento podría tener un valor si el dato esta disponible y si es apropiado para el metadato. Metadatos en e-government. Por qué se utilizan metadatos en e-government? La respuesta parece ser categórica: Los Servicios Públicos en Web son descritos y automatizados con el uso de metadatos, los cuales definen conceptos, restricciones, propiedades y relaciones, logrando establecer un área de conocimiento de los servicios [12]. Aplicaciones típicas de los metadatos de alto nivel son su uso para clasificaciones jerárquicas, definición de taxonomías, y búsqueda, entre otras. Metadatos e interoperabilidad. Los metadatos juegan un rol clave en la interoperabilidad de Servicios Públicos. Al contar con metadatos, cuando dos o más servicios se comunican entre sí, éstos utilizan descripciones de datos comunes. En otras palabras, la comprensión de tipos de datos entre servicios es efectiva. Los metadatos son una metodología para facilitar la compatibilidad de los datos y la integración de datos heterogéneos, así como mejorar la recuperación de la información pública [13]. Estándares para metadatos. Para la aplicación de metadatos se han desarrollado distintos estándares, que si bien comparten una sintaxis y estructura de la información XML, difieren atendiendo a los propósitos de la información que describen y a las necesidades de especificidad y gestión remota de los recursos que son representados. Las razones para desarrollar estándares para metadatos dentro de un sistema de e-goverment, se centran en una mejor calidad de atención a los usuarios, y en una mejor gestión de contenidos correspondientes a las plataformas de interoperabilidad de servicios. Diferentes administraciones públicas han adaptado metadatos genéricos para que cumplan los requerimientos esenciales de la información pública, adoptando de esta forma perfiles de aplicación, esquemas o normativas integrales de metadatos para su utilización en administración pública electrónica. 2.7 Ontología. La definición de ontología que entrega Tom Gruber [15] es la siguiente: Una ontología es una descripción formal de los conceptos y las relaciones entre conceptos. Una ontología es un modelo de conocimiento que contextualiza un determinado 17
dominio. Es una descripción que pone en contexto un determinado conocimiento o rango de conocimientos. El concepto de ontología en informática hace referencia al modelamiento conceptual que pretende formular un detallado y riguroso esquema conceptual dentro de un dominio de conocimiento dado, con el objetivo de facilitar la comunicación y la transferencia de la información entre diferentes sistemas. Un uso común tecnológico actual del concepto de ontología, en este sentido, se encuentra en la inteligencia artificial y la representación del conocimiento. Los sistemas informáticos utilizan ontologías para una diversidad de propósitos, entre los cuales se encuentran razonamiento inductivo y clasificación. En cuanto a aplicaciones de ontologías, éstas se relacionan con vocabularios fijos. Una ontología define las relaciones de los términos del vocabulario para que el sistema pueda evaluarlas de forma automática. Algunas de las características más representativas de las ontologías son las siguientes [16]: Pueden existir ontologías múltiples: El propósito de una ontología es hacer explícito algún punto de vista, por lo que, a veces, será preciso combinar dos o más ontologías. Niveles de abstracción de las ontologías: Estos niveles de generalización o abstracción entregan una topología de ontologías. Multiplicidad de la representación: Un concepto puede ser representado de muchas formas, por lo que pueden coexistir múltiples representaciones de un mismo concepto. Mapeo de ontologías: Establecer relaciones entre los elementos de una o más ontologías, para establecer conexiones, especializaciones, generalizaciones, etc. En cuanto a su tipología, se encuentran cuatro tipos de ontologías en función de su alcance y posibilidad de aplicación [16]: Ontología de la aplicación: usadas por la aplicación. Como por ejemplo, ontología de procesos de producción, de diagnóstico de fallas, de diseño intermedio de barcos, etc. Ontología del dominio: específicas para un tipo de artefacto, generalizaciones sobre tareas específicas en algún dominio. Por ejemplo, ontología del proceso de producción. Ontologías técnicas básicas: describe características generales de artefactos. Por ejemplo: componentes, procesos, funciones. Ontologías genéricas: describe la categoría de más alto nivel. Otra forma de clasificar ontologías se pude realizar en función de su punto de vista, como por ejemplo: físico, de comportamiento, funcional, estructural, topológico, etc. Algunas de las aplicaciones y usos de las ontologías son: 18
Repositorios para la organización del conocimiento Normalizar los atributos de los metadatos aplicables a los documentos Permitir compartir conocimiento Posibilitar el trabajo cooperativo al funcionar como soporte común de conocimiento entre organizaciones, comunidades científicas, etc. Interoperatividad entre sistemas distintos Estructura de ontologías. La estructura de una ontología se forma con los siguientes elementos: Clases: Conceptos abstractos que forman parte del modelo o grupos de conceptos del dominio. Relaciones: Cómo las clases de la ontología interactúan entre sí. Las principales relaciones entre clases son: Subclase-de: relación de herencia. Partición de subclase: relación de descomposición. Axiomas: verdad auto-definida o verdad reconocida universalmente. Significado codificado dentro de una ontología. Reglas: Cláusulas de dos partes donde se definen los hechos del dominio. Si la primera parte de la función es verdadera, entonces se concluye que la segunda parte de la cláusula es también verdadera. Instancias: Son los últimos elementos de la jerarquía; representan conceptos del mundo real. Las clases pueden ser instanciadas en más de una ocasión. Para observar de forma más clara lo anterior, se muestran la Figura 1 y la Figura 2 que corresponden a la ontología que representa vuelos en un aeropuerto [17]. En la Figura 1, los cuadros blancos representan clases, y las flechas representan las relaciones entre clases. En la Figura 2, se observa una lista en donde se declaran las instancias para cada clase (Concept). Figura 1: Árbol de clasificación de clases en el dominio de Vuelos. 19
Figura 2: Diccionario de clases en el dominio de Vuelos. Lenguajes para ontologías. Las ontologías se expresan a través de un lenguaje lógico. Algunos lenguajes usados en ontologías están basados en la lógica de predicados, que ofrecen poderosas primitivas de modelado. Por otro lado, existen otros lenguajes basados en taxonomías de clases y atributos, que tienen un mayor poder expresivo, pero menor poder de inferencia. Dentro de los principales lenguajes de ontologías se destacan los siguientes: SHOE: Simple HTML Ontology Extensions. Fue el primer lenguaje de etiquetado para diseñar ontologías en la Web. Este lenguaje nació antes de que se ideara la Web Semántica. Las ontologías y las etiquetas se incrustaban en archivos HTML. OIL: Ontology Inference Layer. Este lenguaje, derivado en parte de SHOE, fue impulsado también por el proyecto de la Unión Europea On-To-Knowledge. Utiliza ya la sintaxis del lenguaje XML. DAML: Se basa ya en estándares del W3C. El lenguaje DAML se desarrolló como una extensión del lenguaje XML y de Resource Description Framework (RDF). OWL: Ontology Web Language o Lenguaje de Ontologías para la Web es un lenguaje de etiquetado semántico para publicar y compartir ontologías en la Web. Se trata de una recomendación del W3C, y puede usarse para representar ontologías de forma explícita. KIF: Knowledge Interchange Format es un lenguaje para representar ontologías, basado en la lógica de primer orden. KIF está basado en la lógica de predicados con extensiones para definir términos, metaconocimiento, conjuntos, razonamientos no monotónicos, etc. 20
Ontologías en e-government. Para desarrollar una plataforma semántica que facilite la consistencia de composición, reconfiguración y evolución de servicios de e-government y de documentos electrónicos, éstos se apoyan en ontologías. El uso de ontologías en servicios de e-government tiene el objetivo principal de mejorar la gestión de backoffice de los servicios. Es posible encontrar los siguientes tipos de ontologías en los sistemas de e- Government [18]: Ontologías de dominio. Ontologías de organización. Ontologías legislativas. Ontologías de servicios. Ontologías de procesos. Ontologías de documentos. Las ontologías, desarrolladas en distintos elementos, definiciones y relaciones entre los mismos, facilitan el diseño y construcción de sistemas de e-government, que son capaces de intercambiar y utilizar documentos, tratándolos como entidades independientes que contienen información sobre el procedimiento (workflow) a seguir por el documento y sobre los permisos de acceso a su contenido. Ontologías e interoperabilidad. Las ontologías, como representaciones de dominios y de bases de conocimiento, ofrecen una representación muy consistente de semánticas para sistemas interoperables. Las reparticiones de gobierno han comenzado a utilizar ontologías para apoyar sus sistemas semánticos para interoperabilidad en distintos niveles. Lo que comenzó como iniciativas de aplicaciones de metadatos, ya ha avanzado a niveles de establecer estándares sobre los lenguajes descriptivos de ontologías, enfocados en servicios Web. Estándares para ontologías. Debido a los múltiples usos de las ontologías, los lenguajes descriptivos de ontologías existentes tienen fortalezas para describir ciertos dominios de conocimiento y, debilidades o limitaciones sobre otros dominios. Por lo tanto, algunos lenguajes para ontologías han sido catalogados como estándares para ser utilizados sobre dominios específicos, como es el caso de OWL, que es una recomendación de la W3C para la representación explicita de dominios en la Web. Cada gobierno tiene su propia forma de interpretar sus servicios y procesos, lo que implica que adoptan sus propios estándares para el desarrollo de ontologías, tratando de rescatar experiencias exitosas y buenas prácticas en la implementación y uso de éstas. 21
2.8 Repositorio Un repositorio corresponde a un sitio (lógico y físico) centralizado donde la información es almacenada y administrada. Un repositorio puede ser un lugar donde múltiples bases de datos o ficheros se ubican para ser distribuidos sobre una red de computadoras. Es un lugar de almacenamiento de objetos registrados que posee métodos de acceso que permiten recuperar objetos individuales posiblemente con una capa de autenticación y permisos adicionales [19]. El propósito de un repositorio aplicado a la gestión de esquemas XML y metadatos se extiende en los siguientes objetivos específicos: Promover el reuso de componentes: Los desarrolladores, arquitectos de información y otros actores logren localizar, por ejemplo, esquemas XML en un registro XML, ahorrando tiempo y esfuerzo en desarrollar los esquemas por sí mismos. Permitir un control de versiones eficiente: El repositorio debe contar con un sistema que permita seguir eficientemente la historia de cambios de las múltiples versiones de los objetos registrados. Promover el entendimiento unificado de los objetos registrados: Debido a que los metadatos para los objetos registrados son asequibles desde una ubicación única, se pretende dar una visión unificada de su significado. Asegurar la consistencia a lo largo de las organizaciones: Tener un lugar central (eventualmente replicado) para los objetos registrados ayuda a asegurar que estos se usan de forma consistente en las distintas reparticiones u organizaciones. Promover un acceso selectivo a los objetos registrados: Los controles de acceso que existen en un registro XML podrán asegurar acceso de sólo lectura o bien acceso irrestricto a los objetos registrados de acuerdo a las políticas de acceso. Incentivar el desarrollo colaborativo: Los usuarios podrán crear ítemes, por ejemplo, esquemas XML y enviarlos al registro XML para su uso y permitir potenciales mejoras por parte de otros usuarios. Así, una repartición podrá crear un esquema XML, enviarlo al registro y luego otra lo descarga, lo actualiza o adapta a sus necesidades y lo envía como una nueva versión del esquema. Proveer los siguientes datos relacionados con los objetos almacenados [3]: Fuente: Autor e Información de contacto. Documentación. Versionado. Información sobre el proceso de Coordinación. Información sobre calidad: Alcances, obligaciones. Ejemplos. XML.org. Es un portal web iniciado en 1999 por OASIS (Organization for the Advancement of Structured Information Standards), para minimizar la redundancia y la inconsistencia 22
en XML, promoviendo el acceso público a información y esquemas en XML en un repositorio centralizado. Hoy en día, XML.org ha expandido su investigación y ha emergido como un portal centralizado de XML que sirve como un importante recurso para desarrolladores y diseñadores para la construcción de documentos, aplicaciones y plataformas que utilizan tecnologías basadas en XML. El repositorio de recursos manejado por XML.org soporta estas secciones: Repositorio de información de iniciativas en la industria basadas en XML. Registro para XML Schema, DTD y otras especificaciones. Recursos para XML. InfoStructureBase Repository. La iniciativa principal de interoperabilidad del gobierno danés, InfoStructureBase, cuenta con un repositorio de información. Este repositorio contiene descripciones de procesos de negocio, documento de modelamiento de datos, descripciones de interfaces y esquemas XML de acceso público. Las reparticiones que utilizan este repositorio, deben revisar su contenido y verificar que los recursos que ingresan al repositorio respeten la consistencia de éste, en cuanto al control de versiones y la reutilización de datos. Repositorios para e-government. Para que un sistema de e-government actúe de forma unificada, es necesario que las reparticiones que lo conforman puedan ofrecer sus servicios de forma íntegra y que la interacción entre éstos sea efectiva, actuando como una sola plataforma centralizada. En otras palabras, los servicios públicos electrónicos deben ser interoperables. Uno de los aspectos importantes en la interoperabilidad en e-government es la centralización y reutilización de recursos. Si dos servicios desean realizar una transferencia de información de forma interoperable, ambos deben referenciar a las mismas estructuras de documentos (esquemas) y tipos de datos (metadatos). Por otro lado, por razones de eficiencia, estos elementos pueden ser reutilizados y no deben ser redundantes. La relevancia de un repositorio de esquemas y metadatos para e-government se enfoca en la necesidad de administrar de manera efectiva y eficiente tanto estructuras como tipos de datos que son accedidos abiertamente. Todo esto para que los servicios que utilicen esos recursos puedan hacerlo de forma interactiva y centralizada, formando así una sola entidad de transferencia de datos, es decir, interoperabilidad de información. 23