l'

.

UNIVERSIDAD DE CHILEFACULTAD DE CIENCIAS FíSICAS Y MATEMÁTICASDEPARTAMENTO 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 DEINGENIERO 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

SANTIAGO DE CHILEENERO 2007

iv

Índice.

v

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

vi

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

vii

Í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

viii

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.

1

1. Introducción.

2

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

3

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.

4

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.

5

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.

6

2. Conceptos Básicos.

7

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

8

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.).

9

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>

10

<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

11

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]

12

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>

13

,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.

14

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.

15

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.

16

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.

17

• 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

18

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:

19

• 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.

20

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.

21

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 back-office 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.

22

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

23

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.

24

3. Estado del Arte en gestión de esquemas y metadatos para e-Government.

25

3.1 Análisis de casos reales. Comunidad Europea: OntoGov.

OntoGov es un proyecto de desarrollo e investigación elaborado por la Comunidad Europea para el desarrollo y difusión de representaciones de conocimiento en la Administración Pública europea. El objetivo principal del proyecto OntoGov es minimizar la configuración manual de servicios de Administración Electrónica de la Comunidad Europea, desarrollando, evaluando y validando una plataforma semánticamente enriquecida que facilite la configuración y evolución de dichos servicios, mediante el uso de ontologías.

Los puntos a lograr con el desarrollo de las iniciativas de OntoGov son [22]: • Proveer a las administraciones públicas con una base que les permita,

fácilmente, tener una visión actual de sus configuraciones de servicios y reconfigurarlas cuando sea necesario.

• Entregar a todos los actores involucrados en los ciclos de vida de servicios públicos el conocimiento relacionado con la composición, reconfiguración y evolución de los servicios de gobierno electrónico.

La meta por alcanzar con la iniciativa es “mejorar la gestión del back-office de los

servicios de e-Government” [23], lo que involucra los siguientes puntos. • Disminuir la brecha entre la realización técnica de servicios de e-Government

y las entidades responsables de tomar de decisiones: motivar a todas las partes involucradas a participar de todas las fases de back-office (diseño, configuración, diseño, etc.).

• Gestión de ciclos de vida de servicios de e-Government: gestión de cambios, preservando la consistencia, detectando y reparando inconsistencias, la propagación de cambios y la implementación de éstos.

• Hacer el conocimiento explícito: capturar conocimientos acerca de servicios de e-Government y trazarlos de acuerdo a las decisiones de diseño de los modelos de servicios de e-Government.

La arquitectura de la plataforma semántica propuesta por el proyecto se

conforma de las siguientes componentes: • Componente de modelamiento de negocio: es la responsable de:

• Creación de ontologías de servicios. • Modificar ontologías. • Almacenar ontologías. • Consultar ontologías disponibles. • Gatillar cambios.

26

• Componente de configuración: realiza la consistencia entre las decisiones de diseño y la implementación de servicios.

• Componente de ejecución: Entrega el ambiente de ejecución de servicios y

monitorea el comportamiento de éstos en producción. Reino Unido: UK GovTalk.

Una de las experiencias en Europa más destacables en relación con planes conceptuales para e-Government es UK GovTalk. Esta iniciativa forma parte del plan de desarrollo de Government Gateway, principal proyecto de gobierno electrónico del Reino Unido, comenzado a comienzos del año 2000.

El propósito de UK GovTalk es incentivar al sector público, la industria y otras

partes interesadas a trabajar juntos en desarrollar y acordar políticas y estándares para gobierno electrónico en todo el Reino Unido.

El trabajo de UK GovTalk contempla dos áreas de desarrollo:

• Esquemas y estándares: Considera todos los aspectos relacionados con la

definición del Framework de interoperabilidad llamado Interoperability Framework for e-Government (e-GIF), el Estándar de metadatos para gobierno electrónico (e-GMS) y el Catálogo de Estándares de Datos del Gobierno (GDSC). Esto provee repositorios para diseñar y agregar esquemas XML, buenas prácticas y casos de estudio, además de ofrecer herramientas e información relevante.

• Documentos de políticas: Contiene documentación relacionada con las

políticas en tecnologías establecidas por la Unidad de gobierno electrónico del Reino Unido, y habilita espacios en línea para la discusión y consultas orientados al desarrollo de políticas en servicios de gobierno electrónico.

El elemento más importante en UK GovTalk es el Framework de interoperabilidad

(e-GIF). El e-GIF (en su versión 6.1) define políticas, técnicas y requisitos para alcanzar la interoperabilidad y coherencia entre los distintos sistemas del sector público. La arquitectura del e-GIF se puede ver en la Figura 3 [21].

27

Figura 3: Arquitectura de e-Gif.

Los componentes de la arquitectura de e-GIF son: • Metadatos en el e-GIF (e-GMS, GCL): El Government Metadata Standard (e-

GMS) está basado en el estándar de metadatos Dublín Core, y ha sido extendido para los sistemas de e-Government británicos. Define un conjunto de metadatos y esquemas básicos que sirven de base para los servicios a desarrollar. Cada servicio particular puede agregar nuevas restricciones o quitar las que no apliquen. El Government Category List (GCL) define una lista de categorías (valores) para cada elemento en el e-GMS.

• Government Data Standards Catalogue (GDSC): Especifica los tipos y convenciones básicas para los datos comunes a usar en todas las reparticiones del estado, usando esquemas XML.

• Schemas: Define buenas prácticas y guías para esquemas XML (XML Schemas), junto con casos de estudio para la creación de esquemas, entre otros. La especificación de datos, documentos, servicios, etc. se realiza a través de esquemas XML.

• TSC: El Technical Standards Catalogue define las tecnologías específicas sobre las cuales se recomienda que se creen los servicios y definiciones que harán posible la interoperabilidad en el e-Government.

• e-Services Development Framework (e-SDF): Provee una estructura para utilizar especificaciones y estándares de interoperabilidad de servicios electrónicos, para el intercambio de datos y mensajes en servicios automáticamente en el sector público. El e-SDF define un conjunto de componentes entre las cuales están el Government Message Reference Model (GMRM) que define un modelo de datos para los mensajes a ser intercambiados entre servicios, y el Government Common Information Model (GCIM) que define un modelo de datos, para especificar los requerimientos del negocio.

Australia: GovDex.

GovDex es un recurso del gobierno australiano desarrollado por agencias gubernamentales para facilitar la colaboración de procesos de negocio entre portafolios públicos y jurisdicciones administrativas. Es una iniciativa para facilitar la colaboración

28

de procesos de negocio entre portafolios, jurisdicciones administrativas y agencias. Promueve efectividad y eficiencia de la transferencia de información, a través de herramientas, métodos y componentes técnicas reusables. Todos éstos proveen una plataforma de interoperabilidad inter jurisdiccional para facilitar la creación, gestión e integración de la relación entre servicios y la comunidad [24]

Conceptualmente, GovDex no es un servicio de integración, sino que realiza un

conjunto de funciones que permiten el intercambio de datos sólo a los usuarios autorizados. GovDex facilita la configuración de integraciones, pero no está involucrado directamente en el flujo de datos. En ese sentido, GovDex respeta la independencia jurisdiccional.

Las componentes principales de la arquitectura del framework de GovDex que han sido definidas son:

• Framework de Desarrollo de Estándares (Development). • Framework de Despliegue de Servicios (Deployment). • Modelos y funciones operacionales para negocios y procesos de e-

Government (Governance). • Herramientas (Tools), métodos (Methods) y contenidos (Content) para la

integración de componentes. • Infraestructura técnica para entregar de forma adecuada la interoperabilidad

(Infrastructure).

En la Figura 4 se observa la arquitectura del Framework de GovDex, donde se muestra la relación entre sus componentes.

29

Figura 4: Arquitectura del Framework de GovDex

Entre los servicios de búsqueda de registros que brinda GovDex para la comunidad, se encuentra un Repositorio de Componentes (GovDex Component Repository). Este repositorio actúa como un repositorio generalizado y abierto de “conocimientos de negocio” y como un repositorio estrictamente controlado de componentes semánticas certificadas [25]. Este Repositorio de Componentes contempla las siguientes librerías de datos:

• Core Components Library: Librería que registra los componentes de código

en cuatro niveles: básicos, de asociación, de agregación y de tipo. • General Business Library: Contiene los datos que forman parte de los

modelos de negocio genéricos utilizados por los servicios públicos. • Functional Business Library: Contiene las ontologías y tesauros de las

funciones las funciones del servicio localizador del gobierno australiano. Hong Kong: HKSARG IF.

Para el Gobierno de la Región Administrativa Especial de Hong Kong (HKSARG), dentro de las iniciativas que ha desarrollado para e-Goverment, para alcanzar la integración entre sus servicios en línea, surgió el proyecto de diseño e implementación de una plataforma de interoperabilidad. Esta plataforma (llamada HKSARG Interoperability Framework (IF)) es un soporte para la implementación de servicios de e-Government integrados. La estrategia detrás de esta iniciativa es la entrega de servicios integrados y centrados en el cliente. Facilita la interoperabilidad técnica y la interoperabilidad de datos entre los distintos involucrados en transacciones en e-

30

Government. Esto es posible de lograr mediante la promulgación de estándares técnicos, y estableciendo un mecanismo para el alineamiento y especificación de los elementos de datos que tienen potencial para ser reusados de en distintas circunstancias [26]. El IF promueve la adopción de XML como medio de intercambio de datos entre las aplicaciones y en relación con esto último, el IF propone la creación de un registro común de datos estándar, particularmente esquemas XML que modelan las necesidades de información del Gobierno.

Dentro de HKSARG IF, se han elaborado un conjunto de estándares y guías aplicables sobre la estructura y tipo de datos, con el objetivo de:

• Contar con una metodología para analistas de negocios para especificar las definiciones y representaciones de información de forma consistente y estructurada.

• Alinear las definiciones y representaciones de datos que tienen el potencial de ser reusables.

HKSARG IF se ha especificado y diseñado considerando los siguientes dominios

[27]:

• Integración de aplicaciones. • Acceso e intercambio de información. • Seguridad. • Interconexión.

El IF promueve la adopción de XML como medio de intercambio de datos entre

las aplicaciones y en relación a esto último, el IF propone la creación de un registro común de datos estándar, particularmente esquemas XML que modelan las necesidades de información del Gobierno. Estados Unidos: FEA.

La Federal Enterprise Architecture (FEA - Arquitectura Corporativa Federal) es la plataforma desarrollada por el gobierno federal de Estados Unidos para que sus servicios en línea sean centrados en los ciudadanos, orientados a sus resultados y adaptados a las tecnologías existentes en e-Goverment. El propósito de FEA es contar con una plataforma común basada en negocios de e-Govermnent que mejore la gestión a nivel federal en las siguientes áreas:

• Asignación de presupuesto • Intercambio de información • Colaboración entre agencias • Medición de rendimiento • E-Government • Arquitecturas basadas en componentes

31

FEA es una base activa que define el negocio, la información necesaria para operarlo, la tecnología necesaria para apoyar sus operaciones y procesos transaccionales para implementar nuevas tecnologías en respuesta a las necesidades del negocio. Es un modelo conceptual que comienza a definir estructura documentada y coordinada para negocios transversales y desarrollo de diseños en el gobierno [29].

La misión principal de FEA es la entrega de valor a los servicios federales en línea, lo cual se pretende lograr con las siguientes acciones:

• Promover la interoperabilidad a nivel federal. • Promover el intercambio de recursos entre agencias. • Aumentar la capacidad de compartir información. La plataforma de FEA está siendo construida mediante una colección de

“modelos de referencia” interrelacionados, diseñados para facilitar el análisis inter agencias y la identificación de brechas y oportunidades para la interoperabilidad entre las agencias federales. En la Figura 4 se observa cómo están relacionados los “modelos de referencia” que forman parte del framework de FEA.

Figura 5: Modelos de Referencia de FEA

Los modelos de referencia de la plataforma de FEA son los siguientes [28]:

• Performance Reference Model - PRM (Modelo de Referencia de Rendimiento): Representa la plataforma estandarizada que es utilizada para medir el rendimiento de las iniciativas en TI más importantes para el gobierno federal.

• Business Reference Model - BRM (Modelo de Referencia de Negocio): Describe las operaciones de negocios del gobierno federal, independiente de las agencias que los implementan.

• Service Component Reference Model - SRM (Modelo de Referencia de Servicios): Clasifica las componentes de servicios respecto a cómo éstos apoyan los objetivos de negocio.

• Data Reference Model - DMR (Modelo de Referencia de Datos): Describe en un nivel de agregación, los datos y la información de apoyo de los programas de gobierno y de las operaciones de negocios. Este modelo permite a las agencias describir los tipos de interacciones e intercambios que ocurren entre el gobierno federal y los ciudadanos. Entre los tipos de datos más importantes en este modelo destacan los esquemas para documentos en XML (XML

32

Schemas), metadatos y ontologías. Éstos son administrados bajo DRM mediante una serie de iniciativas que incluyen guías, estándares, sistemas de registro y repositorios, entre otros [30].

• Technical Reference Model - TRM (Modelo de Referencia Técnico): Entrega los fundamentos para categorizar los estándares, especificaciones y tecnologías para el soporte de construcción, entrega e intercambio de componentes de negocio y de aplicación que podrían ser usados en arquitecturas basadas en componentes u orientadas a servicios.

Brasil: e-PING.

El proyecto de mayor impacto relacionado con la gestión de información administrativa pública en Brasil es la Red Br@sil.gov. Ésta consiste en el desarrollo de una red multiservicios para el gobierno federal, para así contar con una infraestructura interoperable de comunicación a larga distancia, lo cual permitirá alcanzar el nivel máximo de gobierno electrónico establecido por la legislación vigente.

Los objetivos de este proyecto se resumen en los siguientes tres puntos: • Universalización e Integración de servicios. • Gobierno al alcance de todos. • Desarrollo de una infraestructura avanzada.

Para alcanzar la interoperabilidad de servicios, Br@sil.org ha adoptado la

arquitectura e-PING (Patrones de Interoperabilidad de Gobierno Electrónico). E-PING define un conjunto mínimo de políticas y especificaciones técnicas que regulan el uso de TICs para la interoperabilidad de servicios de gobierno electrónico, estableciendo las condiciones de interacción entre organismos de gobierno y la ciudadanía [31].

Las áreas de cobertura para –PING, están segmentadas en: • Interconexión. • Seguridad. • Medios de acceso • Organización e intercambio de información. • Integración para e-Government. Para cada uno de estos segmentos existen componentes especificadas, para las

cuales se han establecido una serie de iniciativas, entre las que destacan: • Alineamiento con Internet. • Adopción de XML para información de la administración pública. • Catálogo de datos de uso común. • Catálogo de referencia de XML Schemas. • Uso de metadatos. • Desarrollo de un estándar de metadatos (e-PMG).

33

Chile: RNDE.

Las consideraciones establecidas en el Gobierno Chileno para una política nacional de interoperabilidad son:

• Adopción de XML • Uso de navegadores como principal medio de acceso medio de acceso • Uso de esquemas y metadatos, basados en un modelo abierto e internacional • Soluciones adquiribles en el mercado • Gradualidad en la adopción

Uno de los principales puntos a desarrollar por el plan de Gobierno Electrónico

de Chile es la creación de un marco de trabajo que describa aspectos de estandarización de gestión de documentación electrónica a fin de asegurar la interoperabilidad entre las reparticiones. El framework de interoperabilidad de información estaría encabezado por un Registro Nacional de Documentación Electrónica (RNDE) que es un registro de información. El RNDE debe poseer como soporte a un grupo expertos en aspectos de modelamiento de información (metadatos, XML, etc.) quienes van a crear, incorporar y mantener la documentación presentada. 3.2 Buenas prácticas. Arquitectura de Interoperabilidad. Una buena práctica establecida por algunos países es el desarrollo de una Arquitectura de Interoperabilidad, como una definición formal de una plataforma en donde distintos servicios pueden operar de forma unificada. Una arquitectura de interoperabilidad se forma a partir de un conjunto de componentes. Algunas de éstas corresponden a módulos de modelamiento de negocios, otros corresponden a módulos de desarrollo de servicios y documentos, y también cuentan con módulos que forman parte de un nivel de infraestructura técnica. En otras palabras, una arquitectura de interoperabilidad se conforma de tres capas: capa de negocio, capa de desarrollo y capa de infraestructura. El propósito principal de diseñar una arquitectura de interoperabilidad es establecer una plataforma centralizada para que sea utilizada por los servicios para que éstos sean modelados, configurados, modificados y controlados. Guidelines de diseño de XML Schema. Para la implementación de archivos XML Schema (XSD), se han elaborado guidelines de diseño de XML Schema, con el objetivo de entregar de forma pública una pauta de recomendaciones para implementar esquemas. Estas recomendaciones consideran idioma, namespaces, manejo de elementos y atributos y uso de metadatos.

34

Cuando los servicios respetan las recomendaciones establecidas para XML Schemas, las estructuras de los documentos XML que intercambian pueden ser reutilizadas para otros documentos, y pueden soportar la transferencia interoperable de documentación. Estándares de metadatos – Dublin Core. Los estándares de metadatos elaborados por los organismos de e-Government han seguido como base el estándar Dublin Core Metadata Standard. Este estándar es usado para descripción de recursos de información de dominios, el cual representa los estándares ISO 15836-2003, NISO Z39.85-2001 y CEN Workshop Agreement CWA 13874 (10.12), los cuales son de gran difusión el el desarrollo de aplicaciones Web. Dublin Core es una organización dedicada a la promoción y difusión de normas interoperables sobre metadatos y el desarrollo de vocabularios especializados en metadatos para la descripción de recursos que permitan sistemas de recuperación más inteligentes. Uno de los esfuerzos es el desarrollo en colaboración y el continuo perfeccionamiento de convenciones sobre metadatos. Lenguaje estándar para ontologías. Como se mencionó en el capítulo anterior, las ontologías utilizan un lenguaje descriptivo para que éstas sean expresadas. En la actualidad existe una considerable variedad de lenguajes para ontologías, cada uno de éstos con cualidades que los hacen útiles para determinados tipos de dominios. Esto implica que un sistema de e-Government debe escoger uno o más (preferentemente pocos) lenguajes para utilizar en la descripción explícita de sus ontologías, y que estos lenguajes sean efectivamente usados. Por lo tanto es una buena práctica establecer como normativa el uso de determinados lenguajes para representar conocimiento de dominios, y motivar el uso de éstos a través de la difusión de guías y ejemplos de uso.

35

4. Contenidos para Sistema Repositorio de esquemas y metadatos.

36

Al momento de desarrollar un Sistema Repositorio de esquemas y metadatos, es imperativo definir sus contenidos, que en su integridad forman el marco de trabajo para llevar a cabo la realización del repositorio. Estos contenidos involucran procesos, buenas prácticas de diseño de elementos, control de versiones y gestión de documentación electrónica.

Para el Gobierno de Chile, estos contenidos deben respetar la normativa existente (Decreto Nº 81) y considerar los avances obtenidos en interoperabilidad de servicios públicos. El repositorio de esquemas y metadatos debe formar parte de un Registro Nacional de Documentación Electrónica (RNDE), el cual a la vez formaría parte de las iniciativas del PRYME.

Considerando la normativa y los aspectos técnicos relacionados con e-

Government, la definición de contenidos para un sistema repositorio debe realizarse con un considerable grado de formalidad para que estos contenidos sean el marco de interoperabilidad efectivo para el diseño e implementación del sistema, y para que sean utilizados como guías para iniciativas similares de sistemas de almacenamiento de objetos para servicios electrónicos públicos.

En este capítulo se describen los contenidos definidos para un sistema

repositorio de esquemas y metadatos para servicios públicos del Gobierno de Chile. Estos contenidos serán descritos como especificaciones necesarias y deseables para el desarrollo del sistema.

Los contenidos a definir en este trabajo se han clasificado en los siguientes

temas: • Buenas prácticas para Esquemas XML: • Estándar para metadatos. • Uso de ontologías para representaciones de conocimiento. • Control de Versiones de recursos. • Almacenamiento de datos. • Validación de recursos. • Taxonomía de recursos. • Disponibilidad del sistema • Control de usuarios.

4.1 Buenas prácticas para el diseño de esquemas XML.

Para realizar una gestión eficiente de almacenamiento y difusión de esquemas XML dentro de un sistema repositorio, éstos deben respetar una estructura específica. La descripción de esta estructura puede ser definida mediante un conjunto de especificaciones (obligatorias y sugerencias) que juntos corresponden a guías de diseño para esquemas de documentos electrónicos.

37

Una especificación de guías para el diseño de esquemas XML contiene dos tipos de guías:

• Requerimientos obligatorios: corresponden a especificaciones que deben cumplirse en el diseño de esquemas XML, para que éstos sean validados en el repositorio, y sean compatibles con aspectos técnicos propios de los servicios en línea.

• Buenas prácticas recomendadas: son sugerencias que han generado resultados positivos donde han sido aplicadas. Consisten en recomendaciones de diseño que permiten tomar decisiones correctas de acuerdo a determinados casos.

Para describir cada una de las buenas prácticas propuestas en este trabajo, se

seguirá el siguiente formato: • Título: encabezado descriptivo de la buena práctica. • Identificador: Cadena de caracteres que permiten identificar a la buena

práctica de forma no ambigua (de la forma BPEXMLnumero_de_la_especificación).

• Nivel de Obligación: indica si la buena practica es de uso obligatorio o es de uso recomendado (ver párrafo anterior)

• Descripción: Explicación detallada de la buena práctica.

A continuación se muestran las buenas prácticas para el diseño de esquemas XML. Título Uso de metadatos y valores estándares. Identificador BPEXML01 Nivel de Obligación Requerimiento obligatorio. Descripción Los documentos electrónicos, y en particular sus

esquemas, deben hacer uso explícito de metadatos que respeten el estándar establecido para éstos y cuyas referencias se ubiquen en los registros centrales de información utilizados por los servicios electrónicos públicos.

Título Lenguaje oficial Identificador BPEXML02 Nivel de Obligación Requerimiento obligatorio. Descripción Las reglas de diseño de esquemas XML deben estar

basadas en las siguientes recomendaciones del Consorcio de la World Wide Web (W3C): XML Schema Part 1: Structures y XML Schema Part 2: Data Types [20].

38

Título Versión del lenguaje Identificador BPEXML03 Nivel de Obligación Requerimiento obligatorio. Descripción Todos los esquemas XML y sus respectivas instancias

deben estar basados en el conjunto de especificaciones técnicas del W3C que tengan el estatus de recomendación [20]. En este sentido, el Decreto 81 no especifica una versión determinada a usar de XML Schema, por lo que se recomienda seguir lo expresado en este párrafo. No obstante, los prototipos no deben usarse en ambientes de producción hasta que la(s) especificación(es) alcancen el estatus de recomendación puesto que son las únicas versiones que el W3C asegura su estabilidad.

Título Idioma oficial Identificador BPEXML04 Nivel de Obligación Requerimiento obligatorio. Descripción Los elementos, atributos y nombres de tipos deben

estar compuestos de palabras en idioma castellano. Los caracteres permitidos son sólo aquellos en los rangos a-z y A-Z. Los números no deben usarse para estos efectos [20].

Título Codificación de caracteres Identificador BPEXML05 Nivel de Obligación Requerimiento obligatorio. Descripción La codificación de caracteres a usar en los esquemas

debe ser UTF-8 [3] tal como lo expresa el artículo 9 del Decreto N°81 [20].

Título Nombramiento de elementos, atributos y tipos Identificador BPEXML06 Nivel de Obligación Requerimiento obligatorio. Descripción Según el artículo 14 del Decreto 81, toda etiqueta y tipo

de dato que aparezcan en un esquema XML deben figurar en un registro central o diccionario. Asimismo, aquellas etiquetas nuevas deben enviarse al registro para su evaluación y posterior aprobación en nuevos esquemas. Los nombres de los elementos en los esquemas XML deben ser escritos de acuerdo a la convención Upper Camel Case (UCC), esto es, palabras compuestas eliminando los espacios y poniendo en mayúscula la primera letra de cada palabra. En cuanto a los atributos, estos deben ser escritos siguiendo la convención Coger Camel Case (LCC), vale decir, palabras compuestas eliminando los espacios y poniendo en mayúscula la primera letra a

39

partir de la segunda palabra [20]. Tanto los elementos, atributos y tipos deben ser nombrados en forma singular a no ser que el concepto sea en si mismo plural.

Título Uso de símbolos especiales en elementos, atributos

y tipos Identificador BPEXML07 Nivel de Obligación Requerimiento obligatorio. Descripción El uso de símbolos tales como: punto, guiones (alto y

bajo) u otra clase de separadores (por ejemplo, espacios) no deben usarse en los elementos, atributos y tipos [20]. Lo mismo es válido para aquellos caracteres no permitidos en la especificación XML del Consorcio W3C.

Título Uso de acrónimos y abreviaturas Identificador BPEXML08 Nivel de Obligación Requerimiento obligatorio. Descripción Los acrónimos y abreviaturas u otro tipo de truncado de

palabras no deben ser usados a excepción que estos sean parte de un registro central, en cuyo caso si se utilizan al inicio de la declaración de un atributo entonces deben aparecer en minúsculas; en el resto de los casos siempre deben ser escritos en mayúsculas [20]. Aquellas abreviaturas o acrónimos que se usen en elementos o tipos de datos deben permanecer en mayúsculas.

Título Versión del esquema Identificador BPEXML09 Nivel de Obligación Requerimiento obligatorio. Descripción Para poder realizar un manejo eficiente de versiones de

esquemas, estos deben explicitar la versión del esquema dentro de un elemento “annotation” (<annotation>), o como atributo del elemento <xsd:schema>. Además, la versión del esquema debe ser mostrada claramente en el nombre del archivo XSD donde se almacena el código del esquema.

Título Modelar datos y no formularios. Identificador BPEXML10 Nivel de Obligación Buena práctica recomendada. Descripción Esto significa que es mejor preocuparse del

modelamiento mismo de los datos que un documento describe y no de aspectos de formato, ya que XML separa estructura y formato. Si bien los formularios Web son de gran uso para documentación electrónica

40

de servicios, decidir si utilizarlos no es un factor importante en el diseño final de documentos XML [32].

Título Un esquema un solo documento. Identificador BPEXML11 Nivel de Obligación Buena práctica recomendada. Descripción Se sugiere evitar utilizar XML Schema como base para

crear familias de documentos [32]. Así se logra modularidad, y las modificaciones sobre un esquema XML tienen impacto sólo a nivel local (sobre el único documento XML que ocupa ese esquema).

Título Limitar el impacto del cambio Identificador BPEXML12 Nivel de Obligación Buena práctica recomendada. Descripción Dentro de un esquema XML existen componentes

complejas que permiten representaciones de datos no triviales. Sin embargo, el cambio que se aplica sobre estas componentes es de un alto impacto en el esquema. Por lo tanto se recomienda el uso moderado de componentes complejas como definiciones globales, restricciones de tipos complejos y referencias relativas [32].

Título Desarrollo para revisiones y modificaciones Identificador BPEXML13 Nivel de Obligación Buena práctica recomendada. Descripción Para que un esquema XML sea entendible y

modificable por otros desarrolladores, deberían cumplir un conjunto de condiciones, tanto propias del diseño como aspectos complementarios. Estas consideraciones incluyen:

• Documentación de esquema XML. • Considerar testeabilidad • Evitar uso de componentes poco conocidas

Título Uso del elemento “documentation” para

comentarios. Identificador BPEXML14 Nivel de Obligación Buena práctica recomendada. Descripción Una forma simple y entendible de escribir comentarios

en un esquema XML, para que sean considerados como componentes XML, es a través de la utilización del objeto “documentation” (uso: <documentation>comentarios</documentation>). Con el uso de este objeto, los comentarios pueden ser utilizados fácilmente para preparar documentación del esquema.

41

Para ver un ejemplo de aplicación de estas buenas prácticas para diseño de

esquemas en XML, ver capítulo 5. Caso de Aplicación: Repositorio de esquemas y metadatos para el DCC. 4.2 Estándar para metadatos. Como se mencionó en el punto anterior, los esquemas XML deben utilizar metadatos que ya estén definidos, y eso implica que la forma de representar esas definiciones debe seguir un estándar. Para definir un estándar para metadatos en el caso de las reparticiones públicas chilenas, se puede comenzar por rescatar los avances logrados por otros países en este aspecto, y considerar lo entregado por Dublin Core para la definición de metadatos en la Web. Todo esto sumado a las consideraciones de la normativa chilena, permite establecer un tipo de representación de metadatos que puede ser utilizado como estándar. En particular, el estándar propuesto en esta Memoria está basado en Dublín Core Metadata Standard (ISO 15836:2003).

La propuesta de estándar para metadatos se describe a continuación: Elementos de un metadato. Metadato • Accesibilidad

• Audiencia • Contribuidor • Creador • Fecha • Descripción • Disposición • Formato • Identificador • Versión

• Lenguaje • Locación • Preservación • Relación • Fuente • Estado • Asunto • Titulo • Tipo

42

Niveles de Obligación de elementos de un metadato. Elementos Obligatorios Obligatorios si y sólo

si son aplicables Recomendados

Nombre Accesibilidad Preservación Fecha Audiencia Lenguaje Asunto Disposición Descripción Creador Relación Contribuidor Formato Fuente Identificador Locación Estado Tipo Versión Descripción de elementos. Los elementos de un metadato se describen a continuación siguiendo el siguiente formato:

• Elemento: nombre del Elemento. • Definición: descripción del elemento. • Nivel de Obligación: valor de obligación del elemento (ver tabla anterior). • Propósito: uso por el cual el elemento ha sido definido.

Elemento Nombre. Definición Nombre asignado al metadato. Nivel de Obligación Obligatorio. Propósito Permitir la búsqueda de un metadato por medio de un

nombre descriptivo. Elemento Fecha. Definición Fecha asociada con un evento en el ciclo de vida del

metadato. Nivel de Obligación Obligatorio. Propósito Entregar información del periodo exacto cuando el

metadato fue puesto a disposición. Elemento Asunto. Definición Tópico del contenido del metadato. Nivel de Obligación Obligatorio. Propósito Entregar información del tópico relacionado con el

metadato.

43

Elemento Creador. Definición Entidad responsable de la creación del contenido del

metadato. Nivel de Obligación Obligatorio. Propósito Permitir al usuario saber de la organización o persona

que elaboró el metadato. Elemento Formato. Definición La manifestación física o digital del metadato. Nivel de Obligación Obligatorio Propósito Mostrar el contenido específico del metadato. Elemento Identificador. Definición Referencia no ambigua al metadato dentro de un

contexto determinado. Nivel de Obligación Obligatorio. Propósito Permitir al usuario buscar un metadato específico. Elemento Locación. Definición Ubicación física del metadato. Nivel de Obligación Obligatorio. Propósito Entregar la ubicación física exacta de un metadato. Elemento Estado Definición Estado definido actual para el metadato. Nivel de Obligación Obligatorio Propósito Permitir al usuario saber del estado exacto del

metadato. Elemento Tipo. Definición Naturaleza o género del contenido del metadato. Nivel de Obligación Obligatorio. Propósito Entregar información relacionada con el tipo utilizado

para clasificar el metadato. Elemento Versión. Definición Cadena de caracteres que describe avance de

desarrollo del metadato. Nivel de Obligación Obligatorio. Propósito Mostrar la evolución de los avances realizados sobre el

metadato. Elemento Accesibilidad. Definición Indica la disponibilidad y usabilidad del metadato a

grupos específicos.

44

Nivel de Obligación Obligatorio si y solo si es aplicable. Propósito Entregar información de los niveles de accesos posibles

al metadato. Elemento Audiencia. Definición Categoría de usuario al cual se provee el metadato. Nivel de Obligación Obligatorio si y solo si es aplicable. Propósito Entregar al usuario información del enfoque en el cual

el metadato se ha elaborado, para así indicar quienes son los potenciales usuarios del metadato.

Elemento Disposición. Definición Instrucciones de retensión y disposición para el

metadato. Nivel de Obligación Obligatorio si y solo si es aplicable. Propósito Ayudar al usuario a administrar metadatos, en cuanto a

distinguir entre los que pueden ser utilizados y los que no pueden ser utilizados.

Elemento Relación. Definición Referencias a metadatos relacionados. Nivel de Obligación Obligatorio si y solo si es aplicable. Propósito Entregar información de metadatos que están

relacionados con el metadato en específico. Elemento Fuente. Definición Referencia al recurso sobre el cual el metadato

presente deriva. Nivel de Obligación Obligatorio si y solo si es aplicable. Propósito Permitir al usuario encontrar metadatos que han sido

desarrollados sobre la base de un metadato en específico.

Elemento Preservación. Definición Información para apoyar la preservación del metadato a

mediano y largo plazo. Nivel de Obligación Recomendado. Propósito Entregar al usuario la información necesaria para

futuras actualizaciones sobre el metadato. Elemento Lenguaje. Definición Lenguaje del contenido interno del metadato. Nivel de Obligación Recomendado. Propósito Permitir a los usuarios limitar sus búsquedas de

acuerdo a un lenguaje específico. Elemento Descripción.

45

Definición Descripción textual del contenido del metadato. Nivel de Obligación Recomendado. Propósito Entregar información que permita al usuario si necesita

o no el metadato, de acuerdo a sus requerimientos. Elemento Contribuidor. Definición Entidad responsable de hacer contribuciones al

contenido del metadato. Nivel de Obligación Recomendado. Propósito Permitir al usuario saber de la organización o persona

que puso a disposición el metadato.

Para ver un ejemplo de aplicación de esta propuesta de estándar para metadatos, ver Capítulo 5. Caso de Aplicación: Repositorio de esquemas y metadatos para el DCC.

4.3 Uso de ontologías. Para que los esquemas y metadatos almacenados en el sistema repositorio sean usados de forma efectiva y eficiente por las reparticiones públicas, no basta con que estos elementos respeten un formato determinado, establecido por buenas prácticas o un estándar. Lo más importante sin duda es que estos elementos representen los dominios de conocimiento involucrados en la interacción entre reparticiones. Es decir, tanto esquemas como metadatos deben ser coherentes en su contenido con los sistemas reales que forman parte de la plataforma de interoperabilidad de servicios públicos. Una manera formal y estructurada de lograr lo anterior mencionado es utilizando ontologías. El uso de ontología permite:

• Estructurar y explicitar el conocimiento de servicios públicos y reparticiones. • Apoyar la trazabilidad de decisiones de diseño en los modelos de servicios

públicos. • Preservar la consistencia de la configuración de servicios, documentos y

datos. Lenguaje para ontologías. Como se vio en el punto 2.7 Ontologías, existe en la actualidad una variedad de lenguajes para representar ontologías. Cada uno de estos lenguajes obtiene su máxima utilidad en determinados tipos de aplicaciones. De los lenguajes que se mencionaron, considerando las características del Proyecto presentado en esta Memoria, se decidió por utilizar el lenguaje para ontologías OWL (Ontology Web Language). La razón principal de esta elección para representar

46

ontologías se centra en que OWL utiliza una sintaxis basada en XML, ya que es una extensión de RDF/XML, plataforma para metadatos en la Web. Por otra parte, OWL es una derivación mejorada de DAML+OIL, otro lenguaje para ontologías con sintaxis basada en XML. Utilizar una sintaxis basada en XML permite un análisis de consistencia, a nivel de contenido, más directo entre ontologías, esquemas y metadatos. Estructura – Descripción de componentes. A continuación se muestra la sintaxis en OWL para la representación de componentes de una ontología. El propósito de esto es mostrar de forma lo más clara posible cada una de las componentes que describen formalmente a una ontología como objeto de representación de dominio de conocimiento.

Para ver la descripción detallada de cada una de las componentes genéricas de una ontología, ver 5.7: Ontologías. Ontología. La declaración de una ontología se realiza siguiendo la siguiente sintaxis establecida por OWL:

<owl:Ontology rdf:about= topico_descriptivo> <rdfs:comment> comentarios </rdfs:comment> <owl:priorVersion rdf:resource=url_de_version /> <owl:imports rdf:resource=url_de_recursos_a_importar/> <rdfs:label>etiqueta_descriptiva </rdfs:label> ... </owl:Ontology>

Figura 6: Sintaxis en OWL para Ontología.

Clases. La forma de especificar clases en OWL debe respetar la siguiente sintaxis:

<owl:Class rdf:ID=identificador_de_la_clase> (declaración de clase) <rdfs:label>etiqueta_descriptiva_de_la _clase</rdfs:label> (declaración de etiqueta) <rdfs:comment>comentarios </rdfs:comment>(declaración de comentario) </owl:Class>(cierre de declaración de clase)

Figura 7: Sintaxis en OWL para Clases.

47

Propiedades. Las clases cuentan con una o más propiedades. Una propiedad es un atributo de una clase. Hacen posible detallar la descripción de una clase. Conceptualmente, una propiedad es equivalente a un axioma. En OWL existen tres tipos principales de propiedades: DatatypeProperty (tipos de datos), ObjectProperty (propiedades que se representan mediante objetos) y SubPropertyOf (sub-propiedades) [33]. La sintaxis utilizada por OWL para la definición de propiedades es la siguiente:

(DatatypeProperty) <owl:DatatypeProperty rdf:ID=id_de_la_propiedad> <rdfs:label>etiqueta_de_la_propiedad </rdfs:label> <rdfs:comment>comentarios </rdfs:comment> <rdfs:domain rdf:resource=#clase_que_utiliza_la_propiedad />(dominio que utiliza esta propiedad) <rdfs:range rdf:resource=URL_de_referencia _a_rango />(rango de valores permitidos) </owl:DatatypeProperty> (ObjectProperty) <owl:ObjectProperty rdf:ID= id_de_la_propiedad > <rdfs:label> etiqueta_de_la_propiedad </rdfs:label> <rdfs:comment>comentarios </rdfs:comment> <rdfs:domain rdf:resource=# clase_que_utiliza_la_propiedad />(dominio que utiliza esta propiedad) <rfds:range rdf:resource="# clase_que_determina el rango />(rango de valores permitidos) </owl:ObjectProperty> (SubPropertyOf) <owl:ObjectProperty rdf:ID= id_de_la_propiedad > <rdfs:subPropertyOf rdf:resource=# id_de_la_propieda_padre /> <rdfs:range rdf:resource=# clase_que_determina el rango /> ... </owl:ObjectProperty>

Figura 8: Sintaxis en OWL para Propiedades.

Relaciones. Subclase-de. Para declarar una clase definida como subclase, se debe especificar como lo mostrado anteriormente, con la salvedad de declarar el elemento “subClassOf” dentro de la especificación de la clase [33]. Dentro de este elemento se especifica la referencia a la clase sobre la cual se es subclase. La sintaxis es la siguiente:

48

<owl:Class rdf:ID=identificador_de_la_clase> (declaración de clase) <rdfs:label>etiqueta_descriptiva_de_la _clase</rdfs:label> (declaración de etiqueta) <rdfs:comment>comentarios comentarios</rdfs:comment>(declaración de comentario) <rdfs:subClassOf rdf:resource=#identificador_de_clase_padre>(declaración de subclase) </owl:Class>

Figura 9: Sintaxis en OWL para Relaciones –Subclase-de.

Partición de subclase. Para representar relaciones de descomposición, OWL permite el uso del elemento UnionOf. Esto establece la descomposición de una clase en una o más subclases. La sintaxis para el uso de UnionOf es la siguiente:

<owl:Class rdf:ID=identificador_de_la_clase>(declaración de clase padre) .. <owl:UnionOf parseType="collection">(declaración de union de subclases) <owl:Class …>(subclase 1) … </owl:Class>(cierre subclase 1) … <owl:Class …>(subclase n) … </owl:Class>(cierre subclase n) </owl:UnionOf>(cierre unión) </owl:Class> (cierre clase padre)

Figura 10: Sintaxis en OWL para Relaciones – Partición de subclase.

Reglas. Para la definición de reglas, en OWL se utiliza el elemento Restriction. Con este elemento, se establecen restricciones sobre los valores de las propiedades y/o clases, y sobre las relaciones entre clases. La forma de definir una restricción en OWL se muestra en la Figura 11:

49

<owl:Class rdf:ID=identificador_de_la_clase> (declaración de clase) <rdfs:label>etiqueta_descriptiva_de_la _clase</rdfs:label> (declaración de etiqueta) <rdfs:comment>comentarios </rdfs:comment>(declaración de comentario) (restricciones) < owl:Restriction > < owl:onProperty rdf:resource=#etiqueta_de_propiedad/> … <owl:restriccion_de_valor= … rdf:resource=#etiqueta_de_clase/> < owl:toClass rdf:resource=#etiqueta_de_clase/> </ owl:Restriction> </ owl:Class>

Figura 11: Sintaxis en OWL para Restricciones

Instancias. El concepto de instancia dentro de una clase, se refiere a los posibles valores que puede tomar ésta. También, dentro de una instancia, las propiedades de la clase van tomando determinados valores. Representan elementos reales que se clasifican dentro de un concepto que se representa en una clase. La sintaxis en OWL para instancias es la siguiente:

(declaración de clase) <owl:Class rdf:ID=identificador_de_clase > <rdfs:label>Etiqueta_de_clase</rdfs:label> <rdfs:comment>comentarios </rdfs:comment> </owl:Class> (declaración de instancia) <Etiqueta_de_clase rdf:ID=identificador_de_instancia> <rdfs:label> Etiqueta_de_instancia</rdfs:label> <rdfs:comment> comentarios </rdfs:comment> (propiedades) <propiedad_1>valor_de_propiedad_1</ propiedad_1> … <propiedad_n>valor_de_propiedad_n</ propiedad_n > </ Etiqueta_de_clase >

Figura 12: Sintaxis en OWL para Instancias.

50

4.4 Control de versiones de recursos.

Un repositorio de esquemas y metadatos tiene que cumplir con requerimientos de consistencia de datos, de reutilización de objetos a almacenar, y de trabajo colaborativo. Considerando esto, lo más recomendable, para contar con un sistema de control de versiones de esquemas y metadatos, es que este sistema sea concurrente, que administre todos los registros de cambios de implementación de componentes, y que fomente el trabajo colaborativo. Todo lo anterior mencionado se desarrolla a través de un sistema de tipo CVS (Concurrent Versions System). CVS tiene su base en una arquitectura cliente-servidor. Un servidor guarda la(s) versión(es) actual(es) de la componente que se está almacenando y su historia, los clientes conectan al servidor para sacar una copia completa de la componente, para posteriormente trabajar en esa copia y entonces ingresar sus cambios con una serie de comandos específicos. Varios clientes pueden sacar copias del proyecto al mismo tiempo. Posteriormente, cuando ingresan sus modificaciones, el servidor trata de acoplar las aplicaciones. Si hay alguna falla en este proceso, por ejemplo debido a que dos clientes tratan de cambiar la misma línea en un archivo en particular, entonces el servidor entrega una serie de alternativas que permiten solucionar el conflicto [34]. Este sistema de control de versiones debe formar parte de un módulo dentro del cual se administre el proceso de actualización de esquemas y metadatos. Cuando se ingresa una nueva versión de un esquema o metadato ya existente, el sistema asignará automáticamente un nuevo número de versión, o si se desea, el usuario que actualiza el esquema o metadato debe ingresar un número de versión. En el caso que dos o más usuarios desean actualizar un esquema o un metadato simultáneamente, el sistema de control de versiones, a través de un administrador de versiones, procede a analizar el caso y a solucionarlo de acuerdo a un criterio determinado. 4.5 Almacenamiento de datos del repositorio.

En un sistema repositorio de esquemas y metadatos existen dos tipos de datos por almacenar: los datos de administración del sistema y los datos correspondientes a los recursos a almacenar en el repositorio. Los primeros corresponden a datos de la administración de usuarios. Por otra parte, los segundos hacen referencia a los esquemas y metadatos mismos, con la información complementaria que permite representarlos.

Por lo tanto, para contar con modularidad de datos dentro del sistema, se

recomienda que los datos de administración del sistema y los datos del repositorio sean registrados y consultados en motores de Bases de Datos distintas. Para los datos de administración del sistema, utilizar una Base de Datos relacional y para los datos del repositorio utilizar una Base de Datos nativa para XML.

51

Para ambos tipos de Bases de Datos, se recomienda el uso de tecnologías del tipo Open Source (Código Abierto). Para el caso de la Base de Datos relacional, se puede utilizar PostgreSQL o MySQL. En cuanto a la Base de Datos XML a utilizar en el repositorio, se recomienda el uso de eXist como motor para documentos en XML. Como se puede observar en la Figura 13, un sistema repositorio de esquemas y metadatos agrupa tres módulos: Sistema Interno (administración de funcionalidades), Administración de Sistema (control de usuarios) y Repositorio de esquemas y metadatos. En estos dos módulos se administran directamente los datos del sistema repositorio, a través del almacenamiento y consulta en Bases de Datos por separado, con una Base de Datos Relacional y una Base de Datos XML.

Figura 13: Sistema Repositorio de esquemas y metadatos - Administración de Datos.

Modelos de Datos. Otro aspecto importante en el almacenamiento de datos de cualquier sistema, y en particular en un sistema repositorio de recursos, es el modelamiento de los datos que se manejan. Administración de Sistema En este módulo existen dos componentes fundamentales: usuarios y roles. Estas componentes conforman los datos necesarios para representar la administración de usuarios del sistema repositorio.

AdministraciónSistema

Sistema Interno Repositorio deEsquemas y Metadatos

BD Relacional

BD XML

SISTEMA REPOSITORIO DE ESQUEMAS Y METADATOS

52

El siguiente es el modelo de datos para la administración de usuarios:

Figura 14: Sistema Repositorio de esquemas y metadatos - Modelo relacional de Datos – Administración de Sistema.

Repositorio de esquemas y metadatos. ¿Cómo almacenar esquemas XML y metadatos? Como se mencionó anteriormente, existen motores de Bases de Datos que permiten administrar documentos en XML de forma nativa (modelamiento de datos mediante XML).

El siguiente es el modelo de datos para el módulo de repositorio de esquemas y metadatos:

Usuario

Rol Tiene

Teléfono

Nacionalidad

E-mail

Descripción

TieneFunción Nombre

ID

Descripción

1, n

0, n

0, n

0, n

Username

Contraseña Nombres Apellido Apellido Paterno

Nombre

53

Figura 15: Sistema Repositorio de esquemas y metadatos - Modelo de Datos – Administración de Repositorio.

4.6 Validación de recursos.

Un recurso almacenado en un repositorio es útil para ser utilizado en la medida que éste sea válido, tanto por su estructura interna como por su consistencia con el sistema donde se utiliza. Tipos de validación.

Tanto esquemas como metadatos deben pasar por dos tipos de validación:

Esquema

Usuarios_suscritos

Fecha de postulación

Fecha_de_creación

Filename

Namespace

Autor

Versión

Titulo

Keywords

Descripción

Path

Estado

Atributos

Fecha

Usuario

Comentarios

Filename

Identificador

Formato

Metadato

Estado

Tipo

Versión

Accesibilidad

Audiencia

Disposición

Relación

Fuente

Preservación

Lenguaje

Nombre

Descripción

Contribuidor

Fecha

Asunto

Creador

Elementos

1...n

54

• Validación de sintaxis: tiene como propósito validar la estructura interna de

esquemas y metadatos a nivel de código. En este tipo de validación los esquemas y metadatos deben ser revisados en lo que respecta a código (estructura y declaración de elementos, uso de caracteres, etc.). Por ejemplo, se debe verificar que el código de un esquema siga el estándar XML Schema.

• Validación de consistencia: En esta validación los esquemas y metadatos deben ser revisados para analizar si son consistentes con el dominio de los sistemas donde son usados. En otras palabras, estos recursos deben ser representativos a nivel conceptual con las componentes reales de los sistemas. No basta con que un recurso esa correcto en cuanto a su estructura interna, sino que también ese recurso debe ser coherente con uno o más componentes reales que se desean representar con el recurso. Por ejemplo, un metadato que represente el dato “nombre de persona” no puede aceptar dígitos en la cadena de caracteres que representa una instancia de “nombre de persona”.

Etapas de validación. Un esquema o metadato, al ser ingresado al repositorio debe pasar por las siguientes etapas de validación:

• Proponer recurso: El usuario sube un recurso al repositorio. Una vez ingresado, se realiza una validación de sintaxis general.

• Primera revisión: El recurso queda a disposición de los usuarios para observaciones de sintaxis y consistencia. En esta etapa el recurso puede ser aprobado para pasar a una segunda revisión, o puede ser rechazado.

• Segunda revisión: Si el recurso es aceptado en la primera revisión, pasa a una revisión oficial, la cual tiene énfasis en análisis de sintaxis y consistencias más exhaustivos, para lo cual se hace un uso riguroso de las buenas prácticas de esquemas, el estándar para metadatos y el uso formal de ontologías.

• Adherencia de recurso: Una vez que el recurso es validado por segunda vez, se agrega de forma definitiva al repositorio, formalizando su adherencia al sistema.

En la Figura 16 se observa se forma más clara la forma en que las buenas

prácticas para esquemas, el estándar para metadatos y el uso formal de ontologías son aspectos de gran importancia para la validación de esquemas y metadatos en un repositorio.

55

Figura 16: Sistema Repositorio de esquemas y metadatos - Validación de recursos.

4.7 Taxonomía de recursos.

Por taxonomía se entiende por el procedimiento de clasificación de recursos dentro de un sistema repositorio. En un repositorio de esquemas y metadatos existen recursos genéricos, y recursos que corresponden a derivaciones de éstos, y así sucesivamente. Por otro lado, los recursos almacenados se agrupan en determinadas categorías. Es por eso que es de gran relevancia para la organización de recursos, que el sistema tenga un módulo de administración de taxonomía.

Un módulo de administración de taxonomía permitirá una representación clara y

organizada de la jerarquía de recursos, tanto para los procesos propios del sistema como para los usuarios de necesitan explorar el repositorio. Organización de categorías.

En cuanto a la organización de categorías de recursos, éstas deben estar organizadas como un árbol, dónde cada nodo es una categoría, y las hojas los documentos contenidos por el nodo (categoría) padre, todo esto ordenado de forma alfabética por cada nivel del árbol. De esta forma, la exploración consistirá en bajar por el árbol de categorías, mostrando los hijos del nodo escogido en la iteración anterior.

Validación de Componentes

Proponer Recurso

Primera Revisión

Adherencia de Recurso

Segunda Revisión

Buenas prácticas para Esquemas

Uso de Ontologías

Estándar para Metadatos

Validación de Sintaxis

Validación de Consistencia

56

En la Figura 17 se muestra el modelo de datos para la administración de taxonomía. Como se puede observar, este modelo sigue una estructura de árbol, tal como se mencionó anteriormente.

Figura 17: Sistema Repositorio de esquemas y metadatos - Modelo de taxonomía

4.8 Disponibilidad del sistema.

Otro factor importante en la definición de contenidos de un sistema repositorio es la definición de grado de disponibilidad. Es de gran relevancia para el diseño de un sistema repositorio establecer de forma explícita cual será el nivel de disponibilidad requerido, en especial el medio de acceso al repositorio y los factores de seguridad y respaldo de recursos más importantes. Todo esto logra establecer una base fundamental para el diseño de los módulos responsables del la disponibilidad de recursos. Como el repositorio debe ser accedido entre múltiples usuarios ubicados físicamente en lugares distintos y es un sistema en línea, la forma de ingresar a este sistema debe ser acorde a estas características. Por lo tanto, la forma de acceder al sistema debe ser bajo una plataforma Web, a través del uso de un explorador Web. En este aspecto, la plataforma Web del sistema debe ser compatible al menos con Internet Explorer 6.0 y con Mozilla Firefox 1.5.

Taxonomía

Hijos

Descripción

Documentos

ID

Nombre

Atributos

Taxonomía

Atributos

Nombre

ID

,,,

,,,

57

Para que el sistema repositorio de esquemas y metadatos conserve la consistencia e integridad de sus datos, el acceso al sistema debe ser restringido, y sólo puede permitir el acceso de usuarios autorizados a través de un username y un password, o mediante el uso de certificados de firmas digitales. Otro factor no menos importante es la disponibilidad de recursos. Los recursos del repositorio deben estar disponibles gran parte del tiempo, lo deseable es que estén siempre disponibles (o casi siempre, con tiempos de downtime despreciables). Para alcanzar niveles de disponibilidad altos (sobre el 98%) se debe contar con al menos un respaldo (servidor pasivo) para cada Base de Datos que utiliza el sistema, aparte de considerar que cada servidor activo debe tener como mínimo un 98% de uptime. Los servidores pasivos también deben tener como mínimo un 98% de uptime.

En resumen, las especificaciones en este punto son: • Acceso al sistema: Web (aplicación: Internet Explorer 6.0 y Mozilla Firefox

1.5) • Control de acceso: username y password, o certificado de firma digital • Disponibilidad mínima requerida: 98% (uptime de 98% servidores activos y

uptime de 98% pasivos). 4.9 Control de usuarios. Tipos de usuarios. En cuanto a la gestión que realiza el sistema con respecto a los usuarios, estos deben contar con roles establecidos, para conservar la consistencia del sistema. Hay usuarios que sólo pueden explorar las taxonomías, mientras que otros podrán descargar y/o subir recursos, y otros que cumplirán funciones de administradores del sistema. En detalle, los tipos de usuarios que se definen para un sistema repositorio de esquemas y metadatos son:

• Usuario Común: Usuario no registrado, que sólo puede observar las taxonomías de recursos.

• Usuario Registrado: Autorizado para descargar y/o subir recursos. • Evaluador: Responsable de la validez de los recursos. • Administrador: responsable del control de recursos, taxonomías y de

usuarios. Cabe mencionar que estos tipos pueden dar origen a otros sub tipos de usuarios,

de acuerdo a los requerimientos de cada sistema repositorio en específico.

58

Permisos.

A continuación se detallan las funcionalidades autorizadas para cada tipo de usuario, de acuerdo a lo mencionado en el punto anterior.

• Usuario Común. • Consulta de taxonomías. • Vista de taxonomías.

• Usuario Registrado. • Consulta de taxonomías. • Vista de taxonomías. • Descarga de recursos. • Proponer recursos. • Registrar comentarios.

• Evaluador. • Consulta de taxonomías. • Vista de taxonomías. • Descarga de recursos. • Proponer recursos. • Registrar comentarios. • Evaluar recursos. • Evaluar comentarios.

• Administrador. • Consulta de taxonomías. • Vista de taxonomías. • Descarga de recursos. • Proponer recursos. • Registrar comentarios. • Editar taxonomías. • Administrar recursos. • Administrar permisos. • Administrar usuarios.

59

5. Caso de Aplicación: Repositorio de esquemas y metadatos para el DCC.

60

Como parte final del desarrollo de este Proyecto, se procede a mostrar el desarrollo de un caso de aplicación, el cual aplica los contenidos para el desarrollo de un repositorio de esquemas y metadatos para el Departamento de Ciencias de la Computación de la Universidad de Chile (DCC), y como podría ser su comportamiento en la gestión de datos correspondientes a dos tipos de documentos utilizados en el Departamento.

El propósito del desarrollo de este Caso es mostrar cómo los contenidos

propuestos en el capítulo 4 pueden ser aplicados para el diseño de un sistema repositorio de esquemas y metadatos, en particular para un repositorio a utilizar en el DCC. Específicamente, se hará énfasis en cómo deben ser administrados los esquemas y metadatos correspondientes a dos tipos de documentos administrativos utilizados por oficinas del DCC.

Los documentos con los que se va a trabajar en el desarrollo de este Caso son:

Solicitud de Beca de Permanencia y Solicitud de Convenio a Honorarios. El primero corresponde a un formulario que llena gente que está en condición de pasantía dentro del DCC, para solicitar una Beca para cubrir gastos de mantenimiento mientras un alumno de postgrado realiza su pasantía. Por otra parte, la Solicitud de Convenio a Honorarios es un formulario que es llenado para formalizar un convenio en la modalidad de honorarios entre el DCC y una persona que prestará servicios para el departamento. 5.1 Definición de esquemas.

Se procede a diseñar los esquemas, en formato XSD, correspondientes a ambos documentos, de acuerdo a las buenas prácticas propuestas en este Proyecto.

Primero, se analizan los documentos y los elementos que contienen. En la Figura

18 se muestran los campos que forman parte de cada uno de los documentos utilizados en este Caso.

61

Solicitud de Beca de Permanencia. Solicitud de Convenio a Honorarios. Centro Costo. Fecha. Nacionalidad. Nombres. C. Identidad. Pasaporte Nro. País. Domicilio. Cargo e institución extranjera. Trabajo a desarrollar. Monto total. Monto mensual. Detalle: Estadía, Alimentación, Movilización y Pasajes. Periodo de permanencia: Desde y Hasta. Nombre Profesor Representante. Firma Solicitante.

Centro Costo. Fecha. Nacionalidad. Nombres. C. Identidad. Estado Civil. Fecha de Nacimiento. Fono. Domicilio. Comuna. Periodo de pago: Desde y Hasta. Glosa. Periodo de la actividad. Monto total. Monto mensual. Funcionario Público. Cargo en la Universidad. Firma Director.

Figura 18: Estructura general – Solicitud de Beca de Permanencia y Solicitud de Convenio a

Honorarios. Se puede observar en la Figura 18 que existe una similitud considerable entre ambos documentos (ambos son formularios y utilizan campos en común, como se ve en los campos marcados en negrita). Esto podría a analizar la posibilidad de desarrollar un solo esquema para ambos documentos, y especificar detalles para adaptar ese esquema a uno u otro elemento. Sin embargo, de acuerdo a la buena práctica BPEXML11 (ver 4.1 Buenas prácticas para el diseño de esquemas XML.), es recomendable desarrollar un esquema sólo para un documento, por razones de modularidad e impacto de evolución de esquemas. Por lo tanto la similitud de documentos puede ser aprovechada para re-utilización de código de un esquema, para basarse en el diseño del otro, pero no de unificar ambos documentos en un solo esquema. Por otra parte, se tiene que ambos documentos son formularios, lo cual podría ser aprovechado para implementar esquemas específicos para formularios. No obstante, a nivel de esquema se deben diseñar los datos dentro de un contexto de modelo, y el formato de formulario se implementa en otro nivel (hoja de estilo), independiente del esquema. Esto sugiere, de acuerdo a la buena práctica BPEXML10 (ver 4.1 Buenas prácticas para el diseño de esquemas XML.), no diseñar esquemas a base formularios, sino que en base a modelamiento de datos. En cuanto a los campos de los documentos, se establece que éstos sean representados explícitamente mediante metadatos (BPEXML01), lo cual es de gran utilidad para la utilización de tipos de datos comunes en ambos documentos, y para la representación uniforme de datos.

62

Considerando estas prácticas, y las demás definidas en esta Memoria, se procede a diseñar los esquemas en XML correspondientes a Solicitud de Beca de Permanencia y Solicitud de Convenio a Honorarios. Para ver en detalle el código correspondientes a estos esquemas, ver Anexo 1 – “Esquema XML para Solicitud de Beca de Permanencia” y Anexo 2 – “Esquema XML para Solicitud de Convenio a Honorarios”. 5.2 Definición de metadatos. Como se mencionó en el punto anterior, los esquemas deben hacer uso explícito de metadatos. Ahora, todos los metadatos a utilizar para el diseño de documentos electrónicos en XML que sean almacenados en el repositorio deben ser representados de forma explícita y de acuerdo al estándar definido en este proyecto. Los esquemas diseñados hacen referencia a determinados tipos de datos, o sea, a metadatos. En este punto se procede a diseñar cada uno de los metadatos utilizados en los documentos seleccionados para este Caso. Los metadatos definidos son:

• Centro Costo • Nacionalidad • País • Dirección en Chile • Cargo en DCC • Dinero en pesos chilenos • Nombre de Persona • Apellido de Persona • Rol Único Tributario • Estado Civil en Chile • Fono • Glosa • Booleano (Si o No) • Nombre de Institución • Firma

En términos de implementación, los códigos de los metadatos corresponden a

esquemas arquitecturales, desarrollados en archivos XSD. Este tipo de esquemas, a diferencia de los esquemas documentales, describen metadatos que son utilizados para especificar elementos en los esquemas documentales. Un esquema arquitectural se divide en dos partes: descripción del metadato de acuerdo al estándar, y estructura interna de valor(es) posible(es) que puede tomar el metadato.

Para ver en detalle el código correspondientes a estos metadatos, ver Anexo 3 – “Metadatos para Solicitud de Beca de Permanencia y Solicitud de Convenio a Honorarios”.

63

5.3 Ontología. Como se ha mencionado en puntos anteriores, los elementos que serán almacenados en un repositorio deben ser consistentes con las componentes de la realidad que desean representar. Para lo cual, se formalizan las representaciones de esas componentes mediante la elaboración y uso de ontologías. Al contar con un repositorio de esquemas y metadatos, el DCC debe formalizar todo el conjunto de dominios que maneja como parte de sus servicios. Así, será factible realizar un análisis de consistencia entre recursos (esquemas y metadatos) y conceptos reales. Dentro de lo que es el desarrollo de este Caso, se representa la ontología correspondiente a los dominios que están directamente relacionados con los documentos que se analizan en este Caso. Por lo tanto, los dominios a representar mediante ontologías son:

• Los documentos en sí, como tipos de documentos. • Las personas involucradas en las Solicitudes • Las instituciones involucradas en las Solicitudes.

En la Figura 19 se muestra un diagrama de los conceptos que forman parte de

los dominios definidos en este punto, y la relación que existe entre estos conceptos. Los cuadros mostrados en esta Figura corresponden a conceptos manejados por los servicios administrativos del DCC.

64

Figura 19: Repositorio de esquemas y metadatos para el DCC – Conceptos En la Figura 20 se observa en forma más detallada lo anterior, ya con el uso de

clases, relaciones, propiedades, y restricciones, de acuerdo a la estructura de ontologías. Los cuadros mostrados en esta Figura corresponden a clases.

Carta

Empresa

Solicitud

PersonaExtranjero

Documento

PersonaChile

Persona

Institución

Educación

…

Departamento de Carrera

…

Involucra

Universidad

Facultad

Solicitud de Convenio a Honorarios

Solicitud de Beca de Permanencia

Trabaja para

65

Figura 20: Repositorio de esquemas y metadatos para el DCC – Ontología.

El detalle de la representación en OWL de las ontologías definidas en este

trabajo, se encuentra en Anexo 4 – “Ontologías para Documentación en el DCC”.

Persona[Nombre, Apellido, Fecha de Nacimiento, Dirección, Nacionalidad, País de Origen, Fono]

Persona-Chile [RUT, Estado Civil]

Persona-Extranjero [Identificación, Nro Pasaporte]

Documento[Tipo, Encabezado, Cuerpo, Firma]

Carta[…]

Solicitud [Datos del Solicitante, Montos, Dirigida a]

Decreto[…]

Solicitud de Beca de

Permanencia

Solicitud de Convenio a Honorarios

Institución[Nombre, Director, Cargo(s), Direccion…]

Empresa[…]

Educacion[…]

Universidad[…]

Facultad[…]

Departamento de Carrera[…]

Involucra a

Involucra a

Trabaja para

66

5.4 Diseño de Repositorio para esquemas y metadatos en el DCC.

Todas las propuestas definidas en el capítulo 4 forman parte de un conjunto de contenidos que se materializan como módulos o subsistemas de apoyo dentro del diseño del Repositorio para el DCC. Tanto aspecto de diseño de recursos, uso de representaciones conceptuales y las consideraciones aplicadas a cualquier sistema repositorio de recursos, de una forma u otra, directa o indirectamente, son considerados dentro del desarrollo del diseño general del sistema Repositorio.

En el desarrollo de este Caso, en lo que respecta a diseño del sistema, se ha

tomado como referencia el proyecto “Repositorio de esquemas XML”, desarrollado en el semestre de otoño del 2006 como parte de los proyectos del curso “Ingeniería de Software” (CC51A), que imparte el DCC [35]. Este proyecto consistió en el desarrollo de un sistema repositorio de esquemas XML para el DCC, el cual se accede vía Web, y contiene una serie de subsistemas responsables de la administración de usuarios, de sesiones y de recursos.

Las propuestas definidas en esta Memoria, aplicadas a un sistema repositorio en

particular, como es en este caso para un repositorio a utilizar en el DCC, complementan el diseño elaborado en el proyecto mencionado anteriormente, agregando módulos y subsistemas que apoyan la administración de la información de usuarios y sesiones y, principalmente, en la administración de los recursos del repositorio (esquemas y metadatos).

A continuación se describe en detalle cómo los contenidos definidos en esta

Memoria son utilizados para elaborar una propuesta de diseño de un sistema repositorio de esquemas y metadatos para el DCC. Diseño general. El diseño del Sistema Repositorio de esquemas y metadatos para el DCC se desarrolla de la siguiente forma: El sistema consta de tres módulos:

• Sistema administrador de aplicación: responsable de la administración de la información del sistema, en lo que respecta a usuarios y sesiones.

• Sistema administrador de XML: responsable de la administración de recursos, que en este caso corresponden a esquemas XML, metadatos en XML y ontologías.

• Sistema interno: Es el nexo entre las funcionalidades del sistema y los dos sistemas anteriormente mencionados.

En la Figura 21 se observa claramente el diseño interno del Repositorio de

esquemas y metadatos para el DCC.

67

Figura 21: Repositorio de esquemas y metadatos para el DCC – Diseño interno.

El Sistema interno se desarrolla a partir de los siguientes módulos:

• Administrador de usuarios: control de usuarios. • Administrador de consultas: información de las consultas que los usuarios

realizan al repositorio. • Administrador de recursos: control de recursos a nivel interno. • Administrador de opiniones: información de las opiniones de los usuarios con

respecto a un recurso. • Administrador de repositorio: control de almacenamiento de recursos. • Administrador de suscripciones: información de suscripciones de recursos. • Administrador de taxonomía: organización jerárquica de recursos.

En la Figura 22 se muestra en detalle el diseño del Sistema interno.

Sistema administrador de aplicación

Sistema interno Sistema Administrador

de XML

SISTEMA REPOSITORIO DE ESQUEMAS Y METADATOS PARA EL DCC

68

Figura 22: Repositorio de esquemas y metadatos para el DCC – Sistema interno. Almacenamiento y taxonomía de recursos.

El sistema Repositorio de esquemas y metadatos para el DCC maneja dos Bases de Datos: la primera, relacionada con el Sistema administrador de aplicación, corresponde a una base relacional, y la otra Base de Datos, relacionada con el Sistema administrador de XML, es una Base de Datos XML que utiliza eXist como motor para documentos en XML.

En la Figura 23 se muestra cómo las Bases de Datos utilizada por el Repositorio

se relacionan con los módulos principales del sistema.

Sistema interno

Administrador de usuarios Administrador de consultas Administrador de recursos

Administrador de repositorio

Administrador de opiniones

Administrador de suscripciones

Administrador de Taxonomía

69

Figura 23: Repositorio de esquemas y metadatos para el DCC – Bases de Datos.

En lo que respecta a modelos de datos, la Base de Datos Relacional sigue un modelo muy similar al modelo relacional mostrado en el punto 4.5 (Figura 14), donde se representan datos correspondientes a usuarios y sesiones. En la Base de Datos XML, se sigue un modelo nativo para cada tipo de recurso, parecido al modelo nativo de esquemas y metadatos mostrado también en el punto 4.5 (Figura 15). La taxonomía de recursos, tanto de esquemas, metadatos y ontologías, esta debe seguir una estructura de árbol (ver Figura 17), es decir, una taxonomía raíz, sus atributos, sus componentes y otras taxonomías como nodos hijos.

A modo de ejemplo, se muestra en la Figura 24, parte de la taxonomía para metadatos, de acuerdo a los metadatos implementados en el desarrollo de este Caso de Aplicación.

Sistema administrador de aplicación

Sistema interno Sistema Administrador

de XML

SISTEMA REPOSITORIO DE ESQUEMAS Y METADATOS PARA EL DCC

BD Relacional

BD XML

Esquemas (XSD)

Metadatos (XSD – Esquema arquitectural)

Ontologías (XML - OWL)

Usuarios, Sesiones.

70

Figura 24: Repositorio de esquemas y metadatos para el DCC – Taxonomía - Metadatos.

metadata ID=“REP_METADATA”

Nombre=“Metadata”

general

dineroPesosChile-v1-0.xsd direccion-v1-0.xsd estadoCivil-v1-0.xsd rolUnicoTributario-v1-0.xsd

centroCosto-v1-0.xsd

Nombre=“General”

cargoDcc-v1-0.xsd

apellidoPersona-v1-0.xsd booleano-v1-0.xsd firma-v1-0.xsd fono-v1-0.xsd glosa-v1-0.xsd nacionalidad-v1-0.xsd nombreInstitucion-v1-0.xsd nombrePersona-v1-0.xsd pais-v1-0.xsd

uchile

ID=“REP_METADATA_GENERAL”

chile

dcc

ID=“REP_METADATA_CHILE”

Nombre=“Chile”

ID=“REP_METADATA_UCHILE”

Nombre=“Uchile”

ID=“REP_METADATA_DCC”

Nombre=“Dcc”

71

Control de Versiones. Para controlar de forma efectiva y eficiente las versiones de los recursos almacenados en el repositorio, se propone utilizar un subsistema de control de versiones con una arquitectura basada en CVS. Ahora, este subsistema de control de versiones, dentro del sistema repositorio, debe ser utilizado como soporte de un módulo de control de versiones, que a la vez, se debe ubicar dentro del Administrador de Repositorio tal como lo muestra la Figura 25.

Figura 25: Repositorio de esquemas y metadatos para el DCC – Administrador de Repositorio.

Validación de recursos. Uno de los aspectos más interesantes en el desarrollo de esta Memoria es la validación de esquemas y metadatos, tanto a nivel de sintaxis como a nivel de consistencia. Es en este aspecto donde la definición de buenas prácticas para el diseño de esquemas, el uso de un estándar para la representación de metadatos, y el uso de ontologías permiten establecer un entorno de diseño formal para el diseño de esquemas en XML y metadatos, y así apoyar un proceso de validación ordenado y completo. Al observar el diseño del Sistema Repositorio de esquemas y metadatos para el DCC, dentro del Administrador de Recursos, se encuentra un módulo de validación. Es en este módulo donde se apoya el proceso de validación de esquemas y metadatos mediante buenas prácticas para esquemas, el estándar para metadatos y el uso de ontologías, tal como se observa en la Figura 26. Este apoyo se puede realizar a través de un conjunto de análisis a realizar por los administradores del sistema, o con el uso de aplicaciones que realicen análisis a nivel de código. Para la implementación de esas aplicaciones, se puede sacar provecho que esquemas, metadatos y ontologías utilizan en sus códigos una sintaxis XML.

Administrador de Repositorio

Agregar namespace

Agregar recurso Entregar hijos árbol de namespace

Control de Versionesde recursos

Entregar recurso Modificar namespace Eliminar namespace

Sistema basado en arquitectura CVS

72

Figura 26: Repositorio de esquemas y metadatos para el DCC – Administrador de Recursos.

Disponibilidad del Sistema. Para que el Repositorio de esquemas y metadatos para el DCC logre niveles de disponibilidad altos, se debe contar con un servidor Web con al menos un 98% de uptime, y este servidor debe tener una réplica pasiva que lo respalde, con el mismo porcentaje de uptime. Por otra parte, las dos Bases de Datos que utiliza el sistema deben contar con sus respectivas réplicas de respaldo. Para lo cual las inserciones, borrados y modificaciones sobre los datos almacenados deben ser equivalentes tanto en las Bases de Datos y servidores activos como en las pasivos. Control de usuarios. Se establece, de acuerdo a las características del sistema Repositorio de esquemas y metadatos para el DCC, y según el contenido propuesto que hace referencia a la gestión de usuarios, que la clasificación de usuarios del sistema es la siguiente:

Administrador de Recursos

Modificar recursos

Modificar evaluación

Asociar recursos Envío de recursos Actualizar recursos

Buenas prácticas para Esquemas

Estándar para Metadatos

Uso de Ontologías

Evaluar recursos

Validación de sintaxis

Validación de consistencia

73

1) Usuario Común

Funcionalidades permitidas: a) Consulta de taxonomías. b) Vista de taxonomías.

2) Usuario Registrado

Funcionalidades permitidas: a) Consulta de taxonomías. b) Vista de taxonomías. c) Descarga de recursos. d) Proponer recursos. e) Registrar comentarios.

3) Usuario Registrado con derechos de lectura de comentarios.

Funcionalidades permitidas: a) Consulta de taxonomías. b) Vista de taxonomías. c) Descarga de recursos. d) Proponer recursos. e) Registrar comentarios. f) Leer comentarios.

4) Evaluador.

Funcionalidades permitidas: a) Consulta de taxonomías. b) Vista de taxonomías. c) Descarga de recursos. d) Proponer recursos. e) Registrar comentarios. f) Evaluar recursos. g) Evaluar comentarios.

5) Administrador.

Funcionalidades permitidas: a) Consulta de taxonomías. b) Vista de taxonomías. c) Descarga de recursos. d) Proponer recursos. e) Registrar comentarios. f) Editar taxonomías. g) Administrar recursos. h) Administrar permisos. i) Administrar usuarios.

74

6. Conclusiones.

75

6.1 Conclusiones del trabajo realizado.

Considerando la cercanía con los plazos establecidos por el Decreto 81 para materializar los niveles de servicios públicos, se hace muy necesario concretar iniciativas como la que se ha mostrado en este trabajo, y también otras iniciativas que tengan como fin último la modernización de los servicios del Estado de Chile.

La comprensión y la vista unificada es de gran importancia para lograr la interoperabilidad de información. Al compartir de forma centralizada la estructura de un documento, los servicios que lo intercambian pueden funcionar de manera interoperable, ya que el esquema define la tipología de un documento, la cual debe ser comprendida íntegramente para una eficiente transferencia de información. La interoperabilidad de servicios electrónicos es una necesidad en la Administración Pública, para que ésta sea eficiente y centrada en la comunidad. Por otro lado, es imperativo establecer criterios unificados para la elaboración de documentos electrónicos, para que éstos se adapten a plataformas de interoperabilidad. En este sentido, las guías y estándares de diseño e implementación para documentos y datos electrónicos juegan un rol fundamental.

Las guías de diseño para esquemas son un considerable recurso que facilita el diseño de esquemas, para que éstos sean correspondientes con las condiciones de interoperabilidad.

La utilidad de los metadatos se centra en su alta capacidad para describir tipos

de datos, tanto sus características como sus instancias. A diferencia de lo que son los datos en forma genérica, los metadatos son datos con una estructura específica para elementos descriptivos.

En e-Government, las ontologías son utilizadas para la formalización centralizada de dominios, para que servicios y documentos sean implementados de forma consistente de acuerdo a las características propias de los contextos en donde se aplican. La importancia del uso de ontologías se centra principalmente en que permiten formalizar de forma unificada dominios de reparticiones, servicios, documentos y datos, para que éstos sean desarrollados para un sistema de e-Government interoperable.

Los países que han liderado el desarrollo de proyectos en e-Government cuentan con plataformas de interoperabilidad que entregan a las reparticiones y a la comunidad una serie de información que incluye estándares, guías y buenas prácticas. Por otra parte, sus arquitecturas de interoperabilidad soportan componentes centralizadas, en particular librerías y repositorios de información, para que ésta sea administrada de forma eficiente, evitando redundancias e inconsistencias. En el caso de los países sudamericanos citados en esta Memoria, éstos ya cuentan con políticas claras para alcanzar niveles de interoperabilidad en sus servicios. En cuanto a servicios en línea, éstos cada día aumentan y mejoran su capacidad y adaptabilidad a la comunidad. No obstante, es necesario desarrollar sistemas concretos que se adapten a las políticas establecidas, y mejorar la calidad y la eficiencia de los sistemas involucrados en la interoperabilidad de la Administración Pública.

76

Los objetivos de la implementación de un repositorio de esquemas y metadatos tienen su base en el reuso de recursos, en el desarrollo colaborativo, en la gestión de versiones y en la consistencia de datos.

Los contenidos propuestos en este Proyecto pueden ser utilizados para el diseño de cualquier repositorio de esquemas y metadatos para una repartición pública. En particular, en este trabajo se ha mostrado cómo estos contenidos son usados como apoyo al diseño de un sistema repositorio de esquemas y metadatos para el DCC. El desarrollo del Caso de Aplicación contempló dos aspectos de gran importancia: diseño de un sistema repositorio de recursos, y desarrollo válido a nivel de sintaxis y a nivel de consistencia para esquemas y metadatos en XML. El primer aspecto hace referencia a los distintos puntos involucrados en el diseño de cualquier sistema repositorio de recursos, sean éstos documentos, datos estructurados, o aplicaciones. Por otra parte, el segundo aspecto hace hincapié en el diseño formal, organizado y consistente de esquemas y metadatos en XML. El aporte más significativo de la aplicación de los contenidos definidos en este trabajo se concentra en la definición de diseño realizada sobre el subsistema Administrador de Recursos y sobre el Administrador de Repositorio, como por ejemplo, en los módulos de validación de recursos y en el módulo de control de versiones.

A modo de resumen de todo lo mencionado en los puntos anteriores, se concluye que la definición de los contenidos definidos en este Proyecto, como especificaciones formales para el diseño, implementación y almacenamiento de esquemas y metadatos utilizados por documentos en XML, son utilizables como un soporte para administrar de forma más eficiente estos recursos dentro de los servicios públicos del Estado de Chile. 6.2 Propuestas de mejoras. Extender almacenamiento de recursos a hojas de estilos. Si bien en este Proyecto de Título se definieron contenidos para un repositorio de esquemas y metadatos, estos contenidos se pueden extender al almacenamiento centralizado de otras componentes que forman un documento XML, como lo son las hojas de estilo (XSL). Así, se podrán almacenar las componentes de un documento XML necesarias para su diseño final: su estructura (esquemas) y su formato de presentación (hoja de estilo). De esta forma, se tendrá en un repositorio los recursos que, junto con el contenido, forman parte de un documento electrónico en XML. Incluir otros contenidos genéricos. Por otra parte, estos contenidos pueden ser utilizados como base para definir otros contenidos genéricos, tanto para esquemas y metadatos, como para cualquier otro tipo de recurso que se represente con XML. Aquellos contenidos deben ser definidos de acuerdo a qué tipos de recursos se desean almacenar en un sistema repositorio. Cabe mencionar que todo contenido genérico que se desee definir debe ser útil para el desarrollo de cualquier sistema repositorio de esquemas, metadatos y/o de cualquier otro tipo de recurso de tipo XML a usar por cualquier repartición pública.

77

Definir contenidos específicos para cada repartición, que complementen los contenidos genéricos. Como los contenidos definidos en este Proyecto tienen un carácter genérico para el desarrollo de sistemas repositorios para reparticiones públicas, existe la posibilidad que una repartición en particular necesite ampliar esos contenidos con especificaciones que consideren aspectos de mayor detalle en el desarrollo específico de un repositorio en particular que se adapte a los requerimientos propios de esa repartición. No obstante, aquellos contenidos específicos propios de cada repartición no deben ser inconsistentes ni contradictorios con los contenidos genéricos. Muy por el contrario, deben asumir la validez de los contenidos genéricos, y considerando a éstos como base para ser elaborados como especificaciones con mayor detalle, válidas para determinadas reparticiones.

78

APÉNDICES.

79

APÉNDICE 1: ”ESQUEMA XML PARA SOLICITUD DE BECA DE PERMANENCIA”. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" id="solicitudBecaPermanencia" version="1.0" date="2005-11-10"> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/uchile/centroCosto-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/nacionalidad-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/nombrePersona-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/genera/apellidoPersona-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/pais-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/chile/direccion-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/nombreInstitucion-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/dcc/cargoDcc-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/chile/dineroPesosChile-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/firma-v1-0.xsd"/> <xsd:annotation> <xsd:documentation xml:lang="es">Elemento principal</xsd:documentation> </xsd:annotation> <xsd:element name="solicitudBecaPermanencia" type="TipoSolicitudBecaPermanencia"/>

80

<xsd:annotation> <xsd:documentation xml:lang="es">Detalle Elemento principal</xsd:documentation> </xsd:annotation> <xsd:complexType name="TipoSolicitudBecaPermanencia"> <xsd:sequence> <xsd:element name="centroCosto" type="aem:centroCosto"/> <xsd:element name="fecha" type="xsd:date"/> <xsd:element name="nacionalidad" type="aem:nacionalidad" minOccurs="1"/> <xsd:element name="nombre" type="tipoNombre"/> <xsd:element name="cedulaIdentidad" type="xsd:string"/> <xsd:element name="numeroPasaporte" type="xsd:string"/> <xsd:element name="pais" type="aem:pais"/> <xsd:element name="Domicilio" type="aem:direccion"/> <xsd:element name="cargoInstitucionExtranjera" type="tipoCargo"/> <xsd:element name="trabajoADesarrollar" type="aem:cargoDcc"/> <xsd:element name="montoTotal" type="aem:dineroPesosChile"/> <xsd:element name="montoMensual" type="aem:dineroPesosChile"/> <xsd:element name="detalle" type="tipoDetalle"/> <xsd:element name="periodo" type="tipoPeriodo"/> <xsd:element name="profesorResponsable" type="tipoNombre"/> <xsd:element name="firmaSolicitante" type="aem:firma"/> </xsd:sequence> <xsd:attribute name="folio" type="aem:folio"/> </xsd:complexType> <xsd:annotation> <xsd:documentation xml:lang="es">elemento tipoNombre</xsd:documentation> </xsd:annotation> <xsd:complexType name="tipoNombre"> <xsd:sequence> <xsd:element name="nombre" type="aem:nombrePersona" minOccurs="1"/> <xsd:element name="apellido" type="aem:apellidoPersona" minOccurs="1"/> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation xml:lang="es">elemento tipoCargo</xsd:documentation> </xsd:annotation> <xsd:complexType name="tipoCargo"> <xsd:sequence> <xsd:element name="cargo" type="xsd:string"/> <xsd:element name="institucion" type="aem:nombreInstitucion"/> </xsd:sequence> </xsd:complexType>

81

<xsd:annotation> <xsd:documentation xml:lang="es">elemento tipoDetalle</xsd:documentation> </xsd:annotation> <xsd:complexType name="tipoDetalle"> <xsd:sequence> <xsd:element name="estadia" type="aem:dineroPesosChile"/> <xsd:element name="alimentacion" type="aem:dineroPesosChile"/> <xsd:element name="movilizacion" type="aem:dineroPesosChile"/> <xsd:element name="pasajes" type="aem:dineroPesosChile"/> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation xml:lang="es">elemento tipoPeriodo</xsd:documentation> </xsd:annotation> <xsd:complexType name="tipoPeriodo"> <xsd:sequence> <xsd:element name="desde" type="xsd:date"/> <xsd:element name="hasta" type="xsd:date"/> </xsd:sequence> </xsd:complexType> </xsd:schema>

82

APÉNDICE 2: ”ESQUEMA XML PARA SOLICITUD DE CONVENIO A HONORARIOS”. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified" id="solicitudConvenioHonorarios" version="1.0" date="2005-11-10"> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/uchile/centroCosto-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/chile/rolUnicoTributario-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/nombrePersona-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/genera/apellidoPersona-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/nacionalidad-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/chile/estadoCivil-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/fono-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/chile/direccion-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/glosa-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/chile/dineroPesosChile-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/booleano-v1-0.xsd"/> <xsd:include schemaLocation="http://rep.aem.dcc.uchile.cl/core/metadata/general/firma-v1-0.xsd"/>

83

<xsd:annotation> <xsd:documentation xml:lang="es">Elemento principal</xsd:documentation> </xsd:annotation> <xsd:element name="solicitudCovenioAHonorarios" type="TiposolicitudCovenioAHonorarios"/> <xsd:annotation> <xsd:documentation xml:lang="es">Detalle Elemento principal</xsd:documentation> </xsd:annotation> <xsd:complexType name="TiposolicitudCovenioAHonorarios"> <xsd:sequence> <xsd:element name="fecha" type="xsd:date"/> <xsd:element name="centroCosto" type="aem:centroCosto"/> <xsd:element name="rut" type="aem:rolUnicoTributario"/> <xsd:element name="nombre" type="tipoNombre"/> <xsd:element name="nacionalidad" type="aem:nacionalidad" minOccurs="1"/> <xsd:element name="estadoCivil" type="aem:estadoCivil"/> <xsd:element name="fechaNacimiento" type="xsd:date"/> <xsd:element name="fono" type="aem:fono"/> <xsd:element name="Domicilio" type="aem:direccion"/> <xsd:element name="periodoPago" type="tipoPeriodo"/> <xsd:element name="glosa" type="aem:glosa"/> <xsd:element name="periodoActividad" type="tipoPeriodo"/> <xsd:element name="montoMensual" type="aem:dineroPesosChile"/> <xsd:element name="montoTotal" type="aem:dineroPesosChile"/> <xsd:element name="funcionarioPublico" type="aem:booleano"/> <xsd:element name="cargoUniversidad" type="aem:booleano"/> <xsd:element name="firmaDirector" type="aem:firma"/> </xsd:sequence> <xsd:attribute name="folio" type="xsd:date"/> </xsd:complexType> <xsd:annotation> <xsd:documentation xml:lang="es">elemento tipoNombre</xsd:documentation> </xsd:annotation> <xsd:complexType name="tipoNombre"> <xsd:sequence> <xsd:element name="nombre" type="aem:nombrePersona" minOccurs="1"/> <xsd:element name="apellido" type="aem:apellidoPersona" minOccurs="1"/> </xsd:sequence> </xsd:complexType> <xsd:annotation> <xsd:documentation xml:lang="es">elemento tipoPeriodo</xsd:documentation> </xsd:annotation> <xsd:complexType name="tipoPeriodo">

84

<xsd:sequence> <xsd:element name="desde" type="xsd:date"/> <xsd:element name="hasta" type="xsd:date"/> </xsd:sequence> </xsd:complexType> </xsd:schema>

85

APÉNDICE 3: “METADATOS PARA SOLICITUD DE BECA DE PERMANENCIA Y SOLICITUD DE CONVENIO A HONORARIOS”. Metadato: Centro de Costo. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Centro de Costo</Nombre> <Fecha>2006-11-16</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>centroCosto</Identificador> <Locacion>"metadata\uchile\centroCosto-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="centroCosto"> <xsd:restriction base="xsd:positiveInteger"> <xsd:pattern value="\d{4}" /> </xsd:simpleType> </xsd:schema>

86

Metadato: Nacionalidad. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Nacionalidad</Nombre> <Fecha>2006-11-16</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>nacionalidad</Identificador> <Locacion>"metadata\general\nacionalidad-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="nacionalidad"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="Afgana"/> <xsd:enumeration value="Sudafricana"/> <xsd:enumeration value="Albana"/> <xsd:enumeration value="Alemana"/> <xsd:enumeration value="Andorra"/> <xsd:enumeration value="Angolesa"/> <xsd:enumeration value="Antigua y Barbuda"/> <xsd:enumeration value="Antillano"/> <xsd:enumeration value="Saudi"/> <xsd:enumeration value="Argelina"/> <xsd:enumeration value="Argentina"/> <xsd:enumeration value="Armenia"/>

87

<xsd:enumeration value="Aruba"/> <xsd:enumeration value="Australiana"/> <xsd:enumeration value="Austriaca"/> <xsd:enumeration value="Azerbaijan"/> <xsd:enumeration value="Bahamas"/> <xsd:enumeration value="Bahrain"/> <xsd:enumeration value="Bangladesh"/> <xsd:enumeration value="Barbados"/> <xsd:enumeration value="Bielorrusa"/> <xsd:enumeration value="Belga"/> <xsd:enumeration value="Belice"/> <xsd:enumeration value="Benin"/> <xsd:enumeration value="Bermudas"/> <xsd:enumeration value="Boliviana"/> <xsd:enumeration value="Bosnia"/> <xsd:enumeration value="Botswana"/> <xsd:enumeration value="Brasilera"/> <xsd:enumeration value="Brunei Darussulam"/> <xsd:enumeration value="Bulgara"/> <xsd:enumeration value="Burkina Faso"/> <xsd:enumeration value="Burundi"/> <xsd:enumeration value="Butan"/> <xsd:enumeration value="Camboyana"/> <xsd:enumeration value="Camerunesa"/> <xsd:enumeration value="Canadiense"/> <xsd:enumeration value="Cape Verde"/> <xsd:enumeration value="Chad"/> <xsd:enumeration value="Chilena"/> <xsd:enumeration value="China"/> <xsd:enumeration value="Chipriota"/> <xsd:enumeration value="Colombiana"/> <xsd:enumeration value="Comoros"/> <xsd:enumeration value="Congo"/> <xsd:enumeration value="Norcoreana"/> <xsd:enumeration value="Surcoreana"/> <xsd:enumeration value="Costa de Marfil"/> <xsd:enumeration value="Costaricense"/> <xsd:enumeration value="Croata"/> <xsd:enumeration value="Cubana"/> <xsd:enumeration value="Danesa"/> <xsd:enumeration value="Djibouti"/> <xsd:enumeration value="Dominica"/> <xsd:enumeration value="Ecuatoriana"/> <xsd:enumeration value="Egipcia"/> <xsd:enumeration value="Salvadorerña"/> <xsd:enumeration value="Emiratos Arabes Unidos"/> <xsd:enumeration value="Eritrea"/> <xsd:enumeration value="Eslovenia"/> <xsd:enumeration value="Española"/>

88

<xsd:enumeration value="EstadoUnidense"/> <xsd:enumeration value="Estonia"/> <xsd:enumeration value="Etiope"/> <xsd:enumeration value="Fiji"/> <xsd:enumeration value="Filipina"/> <xsd:enumeration value="Finesa"/> <xsd:enumeration value="Francesa"/> <xsd:enumeration value="Gabon"/> <xsd:enumeration value="Gambia"/> <xsd:enumeration value="Georgiana"/> <xsd:enumeration value="Ghanesa"/> <xsd:enumeration value="Granada"/> <xsd:enumeration value="Griega"/> <xsd:enumeration value="Guatemalteca"/> <xsd:enumeration value="Guinea"/> <xsd:enumeration value="Guinea-Bissau"/> <xsd:enumeration value="Guinea Equatorial"/> <xsd:enumeration value="Haitiana"/> <xsd:enumeration value="Holandesa"/> <xsd:enumeration value="Hondureña"/> <xsd:enumeration value="Hungara"/> <xsd:enumeration value="India"/> <xsd:enumeration value="Indonesia"/> <xsd:enumeration value="Iraki"/> <xsd:enumeration value="Irani"/> <xsd:enumeration value="Irlandesa"/> <xsd:enumeration value="Islandesa"/> <xsd:enumeration value="Israelita"/> <xsd:enumeration value="Italiana"/> <xsd:enumeration value="Jamaicana"/> <xsd:enumeration value="Japonesa"/> <xsd:enumeration value="Jordana"/> <xsd:enumeration value="Kazakhstan"/> <xsd:enumeration value="Kenia"/> <xsd:enumeration value="Kiribati"/> <xsd:enumeration value="Kuwait"/> <xsd:enumeration value="Kyrgyzstan"/> <xsd:enumeration value="Laos"/> <xsd:enumeration value="Letonia"/> <xsd:enumeration value="Lesotho"/> <xsd:enumeration value="Libanesa"/> <xsd:enumeration value="Liberia"/> <xsd:enumeration value="Libia"/> <xsd:enumeration value="Liechtenstein"/> <xsd:enumeration value="Lituana"/> <xsd:enumeration value="Luxemburgo"/> <xsd:enumeration value="Macao"/> <xsd:enumeration value="Macedonia"/> <xsd:enumeration value="Madagascar"/>

89

<xsd:enumeration value="Malasia"/> <xsd:enumeration value="Malawi"/> <xsd:enumeration value="Maldivas"/> <xsd:enumeration value="Mali"/> <xsd:enumeration value="Malta"/> <xsd:enumeration value="Marroqui"/> <xsd:enumeration value="Mauricio"/> <xsd:enumeration value="Mauritania"/> <xsd:enumeration value="Mexicana"/> <xsd:enumeration value="Micronesia"/> <xsd:enumeration value="Moldova"/> <xsd:enumeration value="Monaco"/> <xsd:enumeration value="Mongol"/> <xsd:enumeration value="Mozambique"/> <xsd:enumeration value="Myanmar (Burma)"/> <xsd:enumeration value="Namibia"/> <xsd:enumeration value="Nepal"/> <xsd:enumeration value="Nicaraguense"/> <xsd:enumeration value="Niger"/> <xsd:enumeration value="Nigeriana"/> <xsd:enumeration value="Noruega"/> <xsd:enumeration value="Neozelandes"/> <xsd:enumeration value="Oman"/> <xsd:enumeration value="Pakistani"/> <xsd:enumeration value="Palestina"/> <xsd:enumeration value="Panameña"/> <xsd:enumeration value="Papua Nueva Guinea"/> <xsd:enumeration value="Paraguaya"/> <xsd:enumeration value="Peruana"/> <xsd:enumeration value="Polaca"/> <xsd:enumeration value="Portugesa"/> <xsd:enumeration value="Puerto Rico"/> <xsd:enumeration value="Qatar"/> <xsd:enumeration value="Britanica"/> <xsd:enumeration value="Republica Centroafricana"/> <xsd:enumeration value="Checa"/> <xsd:enumeration value="Republica Democratica del Congo"/> <xsd:enumeration value="Dominicana"/> <xsd:enumeration value="Eslovaca"/> <xsd:enumeration value="Ruanda"/> <xsd:enumeration value="Rumana"/> <xsd:enumeration value="Rusa"/> <xsd:enumeration value="Sahara"/> <xsd:enumeration value="Samoa"/> <xsd:enumeration value="San Cristobal-Nevis (St. Kitts)"/> <xsd:enumeration value="San Marino"/> <xsd:enumeration value="San Vincente y las Granadinas"/> <xsd:enumeration value="Santa Lucia"/> <xsd:enumeration value="Sao Tome y Principe"/>

90

<xsd:enumeration value="Senegalesa"/> <xsd:enumeration value="Seychelles"/> <xsd:enumeration value="Sierra Leona"/> <xsd:enumeration value="Singapur"/> <xsd:enumeration value="Siria"/> <xsd:enumeration value="Somali"/> <xsd:enumeration value="Sri Lanka (Ceilan)"/> <xsd:enumeration value="Sudan"/> <xsd:enumeration value="Sueca"/> <xsd:enumeration value="Suiza"/> <xsd:enumeration value="Surinam"/> <xsd:enumeration value="Swaziland"/> <xsd:enumeration value="Tailandesa"/> <xsd:enumeration value="Taiwanesa"/> <xsd:enumeration value="Tajikistan"/> <xsd:enumeration value="Tanzania"/> <xsd:enumeration value="Timor Oriental"/> <xsd:enumeration value="Togo"/> <xsd:enumeration value="Tonga"/> <xsd:enumeration value="Trinidad y Tobago"/> <xsd:enumeration value="Tunesina"/> <xsd:enumeration value="Turkmenistan"/> <xsd:enumeration value="Turca"/> <xsd:enumeration value="Ucraniana"/> <xsd:enumeration value="Uganda"/> <xsd:enumeration value="Uruguaya"/> <xsd:enumeration value="Uzbekistan"/> <xsd:enumeration value="Vanuatu"/> <xsd:enumeration value="Venezolana"/> <xsd:enumeration value="Vietnamita"/> <xsd:enumeration value="Yemen"/> <xsd:enumeration value="Yugoslava"/> <xsd:enumeration value="Zambia"/> <xsd:enumeration value="Zimbabwe"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato: Pais. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

91

<xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Pais</Nombre> <Fecha>2006-11-15</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>pais</Identificador> <Locacion>"metadata\general\pais-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="pais"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="Afganistan"/> <xsd:enumeration value="Africa del Sur"/> <xsd:enumeration value="Albania"/> <xsd:enumeration value="Alemania"/> <xsd:enumeration value="Andorra"/> <xsd:enumeration value="Angola"/> <xsd:enumeration value="Antigua y Barbuda"/> <xsd:enumeration value="Antillas Holandesas"/> <xsd:enumeration value="Arabia Saudita"/> <xsd:enumeration value="Argelia"/> <xsd:enumeration value="Argentina"/> <xsd:enumeration value="Armenia"/> <xsd:enumeration value="Aruba"/> <xsd:enumeration value="Australia"/> <xsd:enumeration value="Austria"/> <xsd:enumeration value="Azerbaijan"/> <xsd:enumeration value="Bahamas"/> <xsd:enumeration value="Bahrain"/> <xsd:enumeration value="Bangladesh"/> <xsd:enumeration value="Barbados"/> <xsd:enumeration value="Belarusia"/> <xsd:enumeration value="Belgica"/> <xsd:enumeration value="Belice"/>

92

<xsd:enumeration value="Benin"/> <xsd:enumeration value="Bermudas"/> <xsd:enumeration value="Bolivia"/> <xsd:enumeration value="Bosnia"/> <xsd:enumeration value="Botswana"/> <xsd:enumeration value="Brasil"/> <xsd:enumeration value="Brunei Darussulam"/> <xsd:enumeration value="Bulgaria"/> <xsd:enumeration value="Burkina Faso"/> <xsd:enumeration value="Burundi"/> <xsd:enumeration value="Butan"/> <xsd:enumeration value="Camboya"/> <xsd:enumeration value="Camerun"/> <xsd:enumeration value="Canada"/> <xsd:enumeration value="Cape Verde"/> <xsd:enumeration value="Chad"/> <xsd:enumeration value="Chile"/> <xsd:enumeration value="China"/> <xsd:enumeration value="Chipre"/> <xsd:enumeration value="Colombia"/> <xsd:enumeration value="Comoros"/> <xsd:enumeration value="Congo"/> <xsd:enumeration value="Corea del Norte"/> <xsd:enumeration value="Corea del Sur"/> <xsd:enumeration value="Costa de Marfil"/> <xsd:enumeration value="Costa Rica"/> <xsd:enumeration value="Croacia"/> <xsd:enumeration value="Cuba"/> <xsd:enumeration value="Dinamarca"/> <xsd:enumeration value="Djibouti"/> <xsd:enumeration value="Dominica"/> <xsd:enumeration value="Ecuador"/> <xsd:enumeration value="Egipto"/> <xsd:enumeration value="El Salvador"/> <xsd:enumeration value="Emiratos Arabes Unidos"/> <xsd:enumeration value="Eritrea"/> <xsd:enumeration value="Eslovenia"/> <xsd:enumeration value="España"/> <xsd:enumeration value="Estados Unidos"/> <xsd:enumeration value="Estonia"/> <xsd:enumeration value="Etiopia"/> <xsd:enumeration value="Fiji"/> <xsd:enumeration value="Filipinas"/> <xsd:enumeration value="Finlandia"/> <xsd:enumeration value="Francia"/> <xsd:enumeration value="Gabon"/> <xsd:enumeration value="Gambia"/> <xsd:enumeration value="Georgia"/> <xsd:enumeration value="Ghana"/>

93

<xsd:enumeration value="Granada"/> <xsd:enumeration value="Grecia"/> <xsd:enumeration value="Groenlandia"/> <xsd:enumeration value="Guadalupe"/> <xsd:enumeration value="Guam"/> <xsd:enumeration value="Guatemala"/> <xsd:enumeration value="Guayana Francesa"/> <xsd:enumeration value="Guerney"/> <xsd:enumeration value="Guinea"/> <xsd:enumeration value="Guinea-Bissau"/> <xsd:enumeration value="Guinea Equatorial"/> <xsd:enumeration value="Guyana"/> <xsd:enumeration value="Haiti"/> <xsd:enumeration value="Holanda"/> <xsd:enumeration value="Honduras"/> <xsd:enumeration value="Hong Kong"/> <xsd:enumeration value="Hungria"/> <xsd:enumeration value="India"/> <xsd:enumeration value="Indonesia"/> <xsd:enumeration value="Irak"/> <xsd:enumeration value="Iran"/> <xsd:enumeration value="Irlanda"/> <xsd:enumeration value="Islandia"/> <xsd:enumeration value="Islas Caiman"/> <xsd:enumeration value="Islas Faroe"/> <xsd:enumeration value="Islas Malvinas"/> <xsd:enumeration value="Islas Marshall"/> <xsd:enumeration value="Islas Solomon"/> <xsd:enumeration value="Islas Virgenes Britanicas"/> <xsd:enumeration value="Islas Virgenes (U.S.)"/> <xsd:enumeration value="Israel"/> <xsd:enumeration value="Italia"/> <xsd:enumeration value="Jamaica"/> <xsd:enumeration value="Japon"/> <xsd:enumeration value="Jersey"/> <xsd:enumeration value="Jordania"/> <xsd:enumeration value="Kazakhstan"/> <xsd:enumeration value="Kenia"/> <xsd:enumeration value="Kiribati"/> <xsd:enumeration value="Kuwait"/> <xsd:enumeration value="Kyrgyzstan"/> <xsd:enumeration value="Laos"/> <xsd:enumeration value="Latvia"/> <xsd:enumeration value="Lesotho"/> <xsd:enumeration value="Libano"/> <xsd:enumeration value="Liberia"/> <xsd:enumeration value="Libia"/> <xsd:enumeration value="Liechtenstein"/> <xsd:enumeration value="Lituania"/>

94

<xsd:enumeration value="Luxemburgo"/> <xsd:enumeration value="Macao"/> <xsd:enumeration value="Macedonia"/> <xsd:enumeration value="Madagascar"/> <xsd:enumeration value="Malasia"/> <xsd:enumeration value="Malawi"/> <xsd:enumeration value="Maldivas"/> <xsd:enumeration value="Mali"/> <xsd:enumeration value="Malta"/> <xsd:enumeration value="Marruecos"/> <xsd:enumeration value="Martinica"/> <xsd:enumeration value="Mauricio"/> <xsd:enumeration value="Mauritania"/> <xsd:enumeration value="Mexico"/> <xsd:enumeration value="Micronesia"/> <xsd:enumeration value="Moldova"/> <xsd:enumeration value="Monaco"/> <xsd:enumeration value="Mongolia"/> <xsd:enumeration value="Mozambique"/> <xsd:enumeration value="Myanmar (Burma)"/> <xsd:enumeration value="Namibia"/> <xsd:enumeration value="Nepal"/> <xsd:enumeration value="Nicaragua"/> <xsd:enumeration value="Niger"/> <xsd:enumeration value="Nigeria"/> <xsd:enumeration value="Noruega"/> <xsd:enumeration value="Nueva Caledonia"/> <xsd:enumeration value="Nueva Zealandia"/> <xsd:enumeration value="Oman"/> <xsd:enumeration value="Pakistan"/> <xsd:enumeration value="Palestina"/> <xsd:enumeration value="Panama"/> <xsd:enumeration value="Papua Nueva Guinea"/> <xsd:enumeration value="Paraguay"/> <xsd:enumeration value="Peru"/> <xsd:enumeration value="Polinesia Francesa"/> <xsd:enumeration value="Polonia"/> <xsd:enumeration value="Portugal"/> <xsd:enumeration value="Puerto Rico"/> <xsd:enumeration value="Qatar"/> <xsd:enumeration value="Reino Unido"/> <xsd:enumeration value="Republica Centroafricana"/> <xsd:enumeration value="Republica Checa"/> <xsd:enumeration value="Republica Democratica del Congo"/> <xsd:enumeration value="Republica Dominicana"/> <xsd:enumeration value="Republica Eslovaca"/> <xsd:enumeration value="Reunion"/> <xsd:enumeration value="Ruanda"/> <xsd:enumeration value="Rumania"/>

95

<xsd:enumeration value="Rusia"/> <xsd:enumeration value="Sahara"/> <xsd:enumeration value="Samoa"/> <xsd:enumeration value="San Cristobal-Nevis (St. Kitts)"/> <xsd:enumeration value="San Marino"/> <xsd:enumeration value="San Vincente y las Granadinas"/> <xsd:enumeration value="Santa Helena"/> <xsd:enumeration value="Santa Lucia"/> <xsd:enumeration value="Santa Sede (Vaticano)"/> <xsd:enumeration value="Sao Tome y Principe"/> <xsd:enumeration value="Senegal"/> <xsd:enumeration value="Seychelles"/> <xsd:enumeration value="Sierra Leona"/> <xsd:enumeration value="Singapur"/> <xsd:enumeration value="Siria"/> <xsd:enumeration value="Somalia"/> <xsd:enumeration value="Sri Lanka (Ceilan)"/> <xsd:enumeration value="Sudan"/> <xsd:enumeration value="Suecia"/> <xsd:enumeration value="Suiza"/> <xsd:enumeration value="Sur Africa"/> <xsd:enumeration value="Surinam"/> <xsd:enumeration value="Swaziland"/> <xsd:enumeration value="Tailandia"/> <xsd:enumeration value="Taiwan"/> <xsd:enumeration value="Tajikistan"/> <xsd:enumeration value="Tanzania"/> <xsd:enumeration value="Timor Oriental"/> <xsd:enumeration value="Togo"/> <xsd:enumeration value="Tonga"/> <xsd:enumeration value="Trinidad y Tobago"/> <xsd:enumeration value="Tunisia"/> <xsd:enumeration value="Turkmenistan"/> <xsd:enumeration value="Turquia"/> <xsd:enumeration value="Ucrania"/> <xsd:enumeration value="Uganda"/> <xsd:enumeration value="Union Europea"/> <xsd:enumeration value="Uruguay"/> <xsd:enumeration value="Uzbekistan"/> <xsd:enumeration value="Vanuatu"/> <xsd:enumeration value="Venezuela"/> <xsd:enumeration value="Vietnam"/> <xsd:enumeration value="Yemen"/> <xsd:enumeration value="Yugoslavia"/> <xsd:enumeration value="Zambia"/> <xsd:enumeration value="Zimbabwe"/> </xsd:restriction> </xsd:simpleType> </xsd:schema>

96

Metadato: Dirección. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Direccion</Nombre> <Fecha>2006-11-14</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>direccion</Identificador> <Locacion>"metadata\chile\direccion-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:complexType name="direccion"> <xsd:sequence> <annotation><documentation>elementos obligatorios</documentation></annotation> <xsd:element name="tipoDireccion" type="aem:tipoDireccion" default="avenida"/> <xsd:element name="nombreDireccion" type="xsd:string"/> <xsd:element name="numeroDireccion" type="xsd:string"/> <xsd:simpleType name="tipoDireccion"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="calle"/>

97

<xsd:enumeration value="avenida"/> <xsd:enumeration value="pasaje"/> <xsd:enumeration value="camino"/> <xsd:enumeration value="ruta"/> <xsd:enumeration value="circunvalacion"/> <xsd:enumeration value="edificio"/> </xsd:restriction> </xsd:simpleType> <annotation><documentation>elementos opcionales</documentation></annotation> <xsd:element name="numeroDepartamentoCasa" type="xsd:string" minOccurs="1"/> </xsd:sequence> </xsd:complexType> </xsd:schema> Metadato: Cargo en DCC. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Cargo en el DCC</Nombre> <Fecha>2006-11-14</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>cargoDcc</Identificador> <Locacion>"metadata\dcc\cargoDcc-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo>

98

<Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="cargoDcc"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="Director"/> <xsd:enumeration value="Profesor Jornada Completa"/> <xsd:enumeration value="Profesor Media Jornada"/> <xsd:enumeration value="Secretaria"/> <xsd:enumeration value="Investigador"/> <xsd:enumeration value="Administrativo"/> <xsd:enumeration value="Auxiliar"/> <xsd:enumeration value="Tecnico"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato: Dinero en Pesos Chilenos. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Dinero en Pesos Chilenos</Nombre> <Fecha>2006-11-15</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>dineroPesosChile</Identificador> <Locacion>"metadata\chile\dineroPesosChile-v1-0.xsd"</Locacion> <Estado>Validado</Estado>

99

<Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:complexType name="dineroPesosChile"> <xsd:sequence> <xsd:element name="simbolo"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:pattern value="$"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="valor"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxInclusive value="999999999"/> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:schema> Metadato: Nombre de Persona. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Nombre de Persona</Nombre> <Fecha>2006-11-16</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador>

100

<Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>nombrePersona</Identificador> <Locacion>"metadata\general\nombrePersona-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="nombrePersona"> <xsd:restriction base="xsd:token"> <xsd:maxLength value="30"/> <xsd:pattern value="[A-Z][A-Za-z_]*"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato: Apellido de Persona <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Apellido de Persona</Nombre> <Fecha>2006-11-16</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType>

101

<Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>apellidoPersona</Identificador> <Locacion>"metadata\general\apellidoPersona-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="apellidoPersona"> <xsd:restriction base="xsd:token"> <xsd:maxLength value="40"/> <xsd:pattern value="[A-Z][A-Za-z_]*"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato: Rol Único Tributario. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Rol Unico Tributario</Nombre> <Fecha>2006-11-15</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>rolUnicoTributario</Identificador> <Locacion>"metadata\chile\rolUnicoTributario-v1-0.xsd"</Locacion> <Estado>Validado</Estado>

102

<Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:complexType name="rolUnicoTributario"> <xsd:sequence> <xsd:element name="numero"> <xsd:simpleType> <xsd:restriction base="xsd:positiveInteger"> <xsd:maxInclusive value="99999999"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="dv"> <xsd:simpleType> <xsd:restriction base="xsd:token"> <xsd:pattern value="(\d|k|K)"/> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:schema> Metadato: Estado Civil. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Estado Civil</Nombre> <Fecha>2006-11-14</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente>

103

<Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>estadoCivil</Identificador> <Locacion>"metadata\chile\estadoCivil-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="estadoCivil"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="soltero"/> <xsd:enumeration value="soltera"/> <xsd:enumeration value="casado"/> <xsd:enumeration value="casada"/> <xsd:enumeration value="viudo"/> <xsd:enumeration value="viuda"/> <xsd:enumeration value="separado"/> <xsd:enumeration value="separada"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato:Fono. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Fono</Nombre> <Fecha>2006-11-14</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador>

104

<Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>fono</Identificador> <Locacion>"metadata\general\fono-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="fono"> <xsd:restriction base="xsd:positiveInteger"> <xsd:pattern value="\d{5,10}" /> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato: Glosa. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE xsd:schema [ <!ENTITY punt "-_.,:;&#161;&#191;&apos;&quot;&#047;"> <!ENTITY alfa "A-Za-z&vocMinAc;&vocMayAc;&nN;"> <!ENTITY num "0-9"> ]> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Glosa</Nombre> <Fecha>2006-11-16</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador>

105

<Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>glosa</Identificador> <Locacion>"metadata\general\glosa-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="glosa"> <xsd:restriction base="xsd:token"> <xsd:maxLength value="2400"/> <xsd:pattern value="[&punt;&alfa;&num;\s]*"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato: Booleano. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Booleano</Nombre> <Fecha>2006-11-14</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType>

106

<Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>booleano</Identificador> <Locacion>"metadata\general\booleano-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="booleano"> <xsd:restriction base="xsd:token"> <xsd:enumeration value="Si"/> <xsd:enumeration value="No"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato: Nombre de Institución. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE xsd:schema [ <!ENTITY num "0-9"> ]> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Nombre de Institucion</Nombre> <Fecha>2006-11-16</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato>

107

<Identificador>nombreInstitucion</Identificador> <Locacion>"metadata\general\nombreInstitucion-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version> </Metadata> </xsd:appinfo> </xsd:annotation> <xsd:simpleType name="nombreInstitucion"> <xsd:restriction base="xsd:token"> <xsd:maxLength value="30"/> <xsd:pattern value="[A-Z][A-Za-z_&num;]*"/> </xsd:restriction> </xsd:simpleType> </xsd:schema> Metadato: Firma. <?xml version="1.0" encoding="UTF-8"?> <xsd:schema targetNamespace="http://rep.aem.dcc.uchile.cl/core" xmlns:aem="http://rep.aem.dcc.uchile.cl/core" xmlns:xsd="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xsd:annotation> <xsd:appinfo> <Metadata> <Nombre>Metadato:Firma</Nombre> <Fecha>2006-11-17</Fecha> <Asunto>Datos Formularios Administrativos DCC</Asunto> <Creador>Departamento de Ciencias de la Computacion - Universidad de Chile</Creador> <Contribuyente>Desarrollado por Esteban Almuna(mailto:ealmuna@dcc.uchile.cl)</Contribuyente> <Audiencia>desarrolladores servicios electronicos</Audiencia> <Formato> <MediaType>text/xml</MediaType> <Sintaxis>http://www.w3.org/2001/XMLSchema</Sintaxis> </Formato> <Identificador>firma</Identificador> <Locacion>"metadata\general\firma-v1-0.xsd"</Locacion> <Estado>Validado</Estado> <Tipo>Metadato</Tipo> <Version>1.0</Version>

108

</Metadata> </xsd:appinfo> </xsd:annotation> <annotation> <documentation>Esta es una representacion general. Puede ser modificada si se desea implementar un tipo especifico.</documentation> </annotation> <xsd:complexType name="firma"> <xsd:complexContent> <xsd:restriction base="xsd:anyType"/> </xsd:complexContent> </xsd:complexType> </xsd:schema>

109

APÉNDICE 4: ”ONTOLOGÍAS PARA DOCUMENTACIÓN EN EL DCC”. <?xml version="1.0" encoding="UTF-8"?> <rdf:RDF xmlns:owl ="http://www.w3.org/2002/07/owl#" xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" xmlns:xsd ="http://www.w3.org/2001/XMLSchema#" xmlns:aem="http://rep.aem.dcc.uchile.cl/core"> <!--Ontología: Documentacion en el DCC--> <owl:Ontology rdf:about= "documentacion_electronica_en_dcc"> <rdfs:comment>En esta ontologia se representan conceptos utilizados por dos documentos administrativos del DCC </rdfs:comment> <owl:priorVersion rdf:resource="http://rep.aem.dcc.uchile.cl/ontologias/2006/20061120/documentacion_dcc" /> <rdfs:label>documentos_dcc</rdfs:label> </owl:Ontology> <!--Persona: clase principal--> <owl:Class rdf:ID="Persona"> <rdfs:label>persona_natural</rdfs:label> <rdfs:comment>Representacion de una persona. Una persona tiene nombre(s), apellido(s), fecha de nacimiento, direccion geográfica, nacionalidad(es), pais de origen y fono. Por otra parte, una persona trabaja para una institucion</rdfs:comment> <owl:Restriction> <owl:onProperty rdf:resource="#Nombre"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="#Apellido"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="#Nacionalidad"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </owl:Class> <!--Persona: Propiedades--> <owl:ObjectProperty rdf:ID="Trabaja_para" > <rdfs:label>trabaja_para</rdfs:label>

110

<rdfs:comment>Una persona trabaja para una institucion</rdfs:comment> <rdfs:domain rdf:resource="#Persona"/> <rfds:range rdf:resource="#Institucion" /> </owl:ObjectProperty> <owl:DatatypeProperty rdf:ID="Nombre" > <rdfs:label>nombre_persona</rdfs:label> <rdfs:comment>Nombre de una persona</rdfs:comment> <rdfs:domain rdf:resource="#Persona"/> <rfds:range rdf:resource="&aem;nombrePersona" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Apellido" > <rdfs:label>apellido de persona</rdfs:label> <rdfs:comment>Apellido_una persona</rdfs:comment> <rdfs:domain rdf:resource="#Persona"/> <rfds:range rdf:resource="&aem;apellidoPersona" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Fecha_de_nacimiento" > <rdfs:label>fecha_nacimiento</rdfs:label> <rdfs:comment>Fecha de nacimiento de una persona</rdfs:comment> <rdfs:domain rdf:resource="#Persona"/> <rfds:range rdf:resource="&xsd;dateTime" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Direccion" > <rdfs:label>direccion</rdfs:label> <rdfs:comment>Ubicacion geografica de residencia de una persona</rdfs:comment> <rdfs:domain rdf:resource="#Persona"/> <rfds:range rdf:resource="&aem;direccion" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Nacionalidad" > <rdfs:label>nacionalidad</rdfs:label> <rdfs:comment>Nacionalidad de una persona</rdfs:comment> <rdfs:domain rdf:resource="#Persona"/> <rfds:range rdf:resource="&aem;nacionalidad" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Pais" > <rdfs:label>pais</rdfs:label> <rdfs:comment>Pais de origen</rdfs:comment> <rdfs:domain rdf:resource="#Persona"/> <rfds:range rdf:resource="&aem;pais" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Fono" > <rdfs:label>fono</rdfs:label>

111

<rdfs:comment>numero de telefono</rdfs:comment> <rdfs:domain rdf:resource="#Persona"/> <rfds:range rdf:resource="&aem;fono" /> </owl:DatatypeProperty> <!--Persona: Persona-Chile--> <owl:Class rdf:ID="Persona_Chile"> <rdfs:label>persona_chile</rdfs:label> <rdfs:comment>Representacion de una persona de nacionalidad Chilena. Tiene un RUT y un estado civil definido en Chile</rdfs:comment> <rdfs:subClassOf rdf:resource="#Persona"> </owl:Class> <!--Persona-Chile: Propiedades--> <owl:DatatypeProperty rdf:ID="RUT" > <rdfs:label>rut</rdfs:label> <rdfs:comment>identificacion de persona en Chile</rdfs:comment> <rdfs:domain rdf:resource="#Persona_Chile"/> <rfds:range rdf:resource="&aem;rolUnicoTributario" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="EstadoCivil" > <rdfs:label>estado_civil</rdfs:label> <rdfs:comment>Estado Civil valido de una persona en Chile</rdfs:comment> <rdfs:domain rdf:resource="#Persona_Chile"/> <rfds:range rdf:resource="&aem;estadoCivil" /> </owl:DatatypeProperty> <!--Persona: Persona-Extranjero--> <owl:Class rdf:ID="Persona_Extranjero"> <rdfs:label>persona_extranjero</rdfs:label> <rdfs:comment>Representacion de una persona extranjera. Tiene una identificacion de su pais de origen y un numero de pasaporte</rdfs:comment> <rdfs:subClassOf rdf:resource="#Persona"> </owl:Class> <!--Persona-Extranjero: Propiedades--> <owl:DatatypeProperty rdf:ID="identificacion" > <rdfs:label>identificacion_extranjero</rdfs:label> <rdfs:comment>Codigo de identificacion de extranjero</rdfs:comment> <rdfs:domain rdf:resource="#Persona_Extranjero"/> <rfds:range rdf:resource="&xsd;string" /> </owl:DatatypeProperty>

112

<owl:DatatypeProperty rdf:ID="Pasaporte" > <rdfs:label>numero_pasaporte</rdfs:label> <rdfs:comment>numero de pasaporte</rdfs:comment> <rdfs:domain rdf:resource="#Persona_Extranjero"/> <rfds:range rdf:resource="&xsd;string" /> </owl:DatatypeProperty> <!--Documento: clase Principal--> <owl:Class rdf:ID="Documento"> <rdfs:label>documento_administrativo</rdfs:label> <rdfs:comment>Representacion de un documento administrativo en el DCC. Tiene un tipo, un encabezado, un cuerpo, fecha y firma. Por otra parte, un documento involucra a una o mas personas y/o a una institucion</rdfs:comment> <owl:Restriction> <owl:onProperty rdf:resource="#Involucra_persona"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="#Involuvra_institucion"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality> </owl:Restriction> </owl:Class> <!--Documento: Propiedades--> <owl:ObjectProperty rdf:ID="Involucra_persona" > <rdfs:label>involucra_persona</rdfs:label> <rdfs:comment>Un documento puede involucrar a una o mas personas</rdfs:comment> <rdfs:domain rdf:resource="#Documento"/> <rfds:range rdf:resource="#Persona" /> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="Involucra_institucion" > <rdfs:label>involucra_persona</rdfs:label> <rdfs:comment>Un documento puede involucrar a una institucion</rdfs:comment> <rdfs:domain rdf:resource="#Documento"/> <rfds:range rdf:resource="#Institucion" /> </owl:ObjectProperty> <owl:DatatypeProperty rdf:ID="Tipo" > <rdfs:label>tipo</rdfs:label> <rdfs:comment>Tipo de Documento</rdfs:comment> <rdfs:domain rdf:resource="#Documento"/> <rfds:range rdf:resource="&xsd;string" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Encabezado" >

113

<rdfs:label>encabezado</rdfs:label> <rdfs:comment>Titulo o encabezado de un documento</rdfs:comment> <rdfs:domain rdf:resource="#Documento"/> <rfds:range rdf:resource="&xsd;string" /> </owl:DatatypeProperty> <owl:ObjectProperty rdf:ID="Cuerpo" > <rdfs:label>cuerpo</rdfs:label> <rdfs:comment>Contenido de un documento</rdfs:comment> <rdfs:domain rdf:resource="#Documento"/> </owl:ObjectProperty> <owl:DatatypeProperty rdf:ID="Fecha" > <rdfs:label>fecha</rdfs:label> <rdfs:comment>Fecha en la cual se llena el documento</rdfs:comment> <rdfs:domain rdf:resource="#Documento"/> <rfds:range rdf:resource="&xsd;dateTime" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Firma" > <rdfs:label>firma</rdfs:label> <rdfs:comment>Firma de un documento</rdfs:comment> <rdfs:domain rdf:resource="#Documento"/> <rfds:range rdf:resource="&aem;firma" /> </owl:DatatypeProperty> <!--Documento: Carta--> <owl:Class rdf:ID="Carta"> <rdfs:label>carta</rdfs:label> <rdfs:comment>Representacion de una carta, como tipo de documento</rdfs:comment> <rdfs:subClassOf rdf:resource="#Documento"> </owl:Class> <!--Documento: Decreto--> <owl:Class rdf:ID="Decreto"> <rdfs:label>carta</rdfs:label> <rdfs:comment>Representacion de un decreto, como tipo de documento</rdfs:comment> <rdfs:subClassOf rdf:resource="#Documento"> </owl:Class> <!--Documento: Solicitud--> <owl:Class rdf:ID="Solicitud"> <rdfs:label>carta</rdfs:label> <rdfs:comment>Representacion de una solicitud, como tipo de documento. Una Solicitud tiene un centro de costo asociado, los datos del solicitante, la persona o institucion a quien va dirigida y puede tener montos.</rdfs:comment>

114

<owl:Restriction> <owl:onProperty rdf:resource="#Dirigida_a_persona"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality> </owl:Restriction> <owl:Restriction> <owl:onProperty rdf:resource="#Dirigida_a_institucion"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">0</owl:minCardinality> </owl:Restriction> <rdfs:subClassOf rdf:resource="#Documento"> </owl:Class> <!--Solicitud: Propiedades--> <owl:DatatypeProperty rdf:ID="Centro_costo" > <rdfs:label>centro_de_costo</rdfs:label> <rdfs:comment>Centro de costo</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rfds:range rdf:resource="aem;centroCosto" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Datos_solicitante" > <rdfs:label>datos_de_solicitante</rdfs:label> <rdfs:comment>Datos de la persona que realiza la solicitud</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> <rfds:range rdf:resource="#Persona" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Dirigida_a_persona" > <rdfs:label>dirigido_a_persona</rdfs:label> <rdfs:comment>Persona quien se dirige la solicitud</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rfds:range rdf:resource="#Persona" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Dirigida_a_institucion" > <rdfs:label>dirigido_a_intitucion</rdfs:label> <rdfs:comment>Institucion a la cual se dirige la solicitud</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rfds:range rdf:resource="#Persona" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Montos" > <rdfs:label>montos</rdfs:label> <rdfs:comment>Cifras en dinero a solicitar</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> </owl:DatatypeProperty>

115

<owl:DatatypeProperty rdf:ID="Monto_Mensual" > <rdfs:label>monto_mensual</rdfs:label> <rdfs:comment>Monto mensual a postular</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rdfs:subPropertyOf rdf:resource="#Montos" /> <rfds:range rdf:resource="&aem;dineroPesosChile" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Monto_Total" > <rdfs:label>monto_total</rdfs:label> <rdfs:comment>Monto total a postular</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rdfs:subPropertyOf rdf:resource="#Montos" /> <rfds:range rdf:resource="&aem;dineroPesosChile" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Periodo" > <rdfs:label>periodo</rdfs:label> <rdfs:comment>Periodo de vigencia de solicitud</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Periodo_desde" > <rdfs:label>periodo_desde</rdfs:label> <rdfs:comment>Inicio de periodo</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rdfs:subPropertyOf rdf:resource="#Periodo" /> <rfds:range rdf:resource="&xsd;dateTime" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Periodo_hasta" > <rdfs:label>periodo_hasta</rdfs:label> <rdfs:comment>Fin de periodo</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud"/> <rdfs:subPropertyOf rdf:resource="#Periodo" /> <rfds:range rdf:resource="&xsd;dateTime" /> </owl:DatatypeProperty> <!--Solicitud: Solicitud de Beca de Permanencia--> <owl:Class rdf:ID="Solicitud_Beca_Permanencia"> <rdfs:label>solicitud_de_beca_de_permanencia</rdfs:label> <rdfs:comment>Representacion de una Solicitud de Beca de Permanencua, como tipo de Solicitud.</rdfs:comment> <owl:Restriction> <owl:onProperty rdf:resource="#Detalle_Montos"/> <owl:maxCardinality rdf:datatype="&xsd;nonNegativeInteger">4</owl:maxCardinality>

116

</owl:Restriction> <rdfs:subClassOf rdf:resource="#Solicitud"> </owl:Class> <!--Solicitud de Beca de Permanencia: Propiedades--> <owl:DatatypeProperty rdf:ID="Datos_Postulante_Beca" > <rdfs:label>datos_de_postulante_a_beca</rdfs:label> <rdfs:comment>Datos de la persona que realiza la solicitud de Beca</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Beca_Permanencia"/> <rdfs:subPropertyOf rdf:resource="#Datos_solicitante" /> <rfds:range rdf:resource="#Persona-Extranjero" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Cargo_Extranjero" > <rdfs:label>cargo_en_extranjero</rdfs:label> <rdfs:comment>Cargo desempeñado en extranjero e Intitucion correspondiente</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Beca_Permanencia"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Cargo" > <rdfs:label>cargo</rdfs:label> <rdfs:comment>Cargo en xtranjero</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Beca_Permanencia"/> <rdfs:subPropertyOf rdf:resource="#Cargo_Extranjero" /> <rfds:range rdf:resource="&xsd;string" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Institucion_Extranjero" > <rdfs:label>institucion_en_extranjero</rdfs:label> <rdfs:comment>Institucion en extranjero</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Beca_Permanencia"/> <rdfs:subPropertyOf rdf:resource="#Cargo_Extranjero" /> <rfds:range rdf:resource="&aem;nombreInstitucion" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Trabajo_desarrollar" > <rdfs:label>trabajo_a_desarrollar</rdfs:label> <rdfs:comment>Trabajo a desarrollar en el DCC</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Beca_Permanencia"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> <rfds:range rdf:resource="&aem;cargoDcc" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Detalle_Montos" > <rdfs:label>datos_de_postulante_a_beca</rdfs:label> <rdfs:comment>Datos de la persona que realiza la solicitud de Beca</rdfs:comment>

117

<rdfs:domain rdf:resource="#Solicitud_Beca_Permanencia"/> <rdfs:subPropertyOf rdf:resource="#Montos" /> <rfds:range rdf:resource="&aem;dineroPesosChile" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Profesor_responsable" > <rdfs:label>profesor_responsable</rdfs:label> <rdfs:comment>Profesor responsable del solicitante</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Beca_Permanencia"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> <rfds:range rdf:resource="#Persona" /> </owl:DatatypeProperty> <!--Solicitud: Solicitud de Convenio a Honorarios--> <owl:Class rdf:ID="Solicitud_Convenio_Honorarios"> <rdfs:label>solicitud_de_convevio_a_honorarios</rdfs:label> <rdfs:comment>Representacion de una Solicitud de Convenio a Honorarios, como tipo de Solicitud.</rdfs:comment> <rdfs:subClassOf rdf:resource="#Solicitud"> </owl:Class> <!--Solicitud de Convenio a Honorarios: Propiedades--> <owl:DatatypeProperty rdf:ID="Datos_Postulante_Convenio" > <rdfs:label>datos_de_postulante_a_convenio</rdfs:label> <rdfs:comment>Datos de la persona que realiza la solicitud de Convenio</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Convenio_Honorarios"/> <rdfs:subPropertyOf rdf:resource="#Datos_solicitante" /> <rfds:range rdf:resource="#Persona-Chile" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Glosa" > <rdfs:label>glosa</rdfs:label> <rdfs:comment>Detalle de la solicitud</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Convenio_Honorarios"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> <rfds:range rdf:resource="&aem;glosa" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Funcionario_publico" > <rdfs:label>funcionario_publico</rdfs:label> <rdfs:comment>Es o no funcionario publico</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Convenio_Honorarios"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> <rfds:range rdf:resource="&aem;booleano" /> </owl:DatatypeProperty>

118

<owl:DatatypeProperty rdf:ID="Cargo_universidad" > <rdfs:label>cargo_universidad</rdfs:label> <rdfs:comment>Tiene o no cargo en la Universidad</rdfs:comment> <rdfs:domain rdf:resource="#Solicitud_Convenio_Honorarios"/> <rdfs:subPropertyOf rdf:resource="#Cuerpo" /> <rfds:range rdf:resource="&aem;booleano" /> </owl:DatatypeProperty> <!--Institucion--> <owl:Class rdf:ID="Institucion"> <rdfs:label>institucion</rdfs:label> <rdfs:comment>Representacion de una Instutucion involucrada en procesos administrativos del DCC. Cada institucion tiene un nombre, un director, y cargos dentro de su organizacion</rdfs:comment> <owl:Restriction> <owl:onProperty rdf:resource="#Cargos"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> </owl:Class> <!--Institucion: Propiedades--> <owl:DatatypeProperty rdf:ID="Nombre_Institucion" > <rdfs:label>nombre_de_institucion</rdfs:label> <rdfs:comment>Nombre de la institucion</rdfs:comment> <rdfs:domain rdf:resource="#Institucion"/> <rfds:range rdf:resource="&aem;nombreInstitucion" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Director" > <rdfs:label>director</rdfs:label> <rdfs:comment>Autoridad de mayor cargo en una institucion</rdfs:comment> <rdfs:domain rdf:resource="#Institucion"/> <rfds:range rdf:resource="#Persona" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Cargos" > <rdfs:label>cargos</rdfs:label> <rdfs:comment>Cargos existentes en la organizacion de una Institucion</rdfs:comment> <rdfs:domain rdf:resource="#Institucion"/> <rfds:range rdf:resource="#" /> </owl:DatatypeProperty> <owl:DatatypeProperty rdf:ID="Direccion_Institucion" > <rdfs:label>direccion_de_institucion</rdfs:label> <rdfs:comment>Ubicacion geografica de una isntitucion</rdfs:comment> <rdfs:domain rdf:resource="#Institucion"/>

119

<rfds:range rdf:resource="&aem;direccion" /> </owl:DatatypeProperty> <!--Institucion: Empresa--> <owl:Class rdf:ID="Empresa"> <rdfs:label>empresa</rdfs:label> <rdfs:comment>Representacion de una empresa, como tipo de institucion</rdfs:comment> <rdfs:subClassOf rdf:resource="#Institucion"> </owl:Class> <!--Institucion: Educacion--> <owl:Class rdf:ID="Educacion"> <rdfs:label>instutucion_de_educacion</rdfs:label> <rdfs:comment>Representacion de una Institucion de Educacion, como tipo de institucion</rdfs:comment> <rdfs:subClassOf rdf:resource="#Institucion"> </owl:Class> <!--Institucion: Universidad--> <owl:Class rdf:ID="Universidad"> <rdfs:label>universidad</rdfs:label> <rdfs:comment>Representacion de una Universidad, como tipo de institucion de Educacion</rdfs:comment> <owl:Restriction> <owl:onProperty rdf:resource="#tiene_Facultad"/> <owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> <rdfs:subClassOf rdf:resource="#Educacion"> </owl:Class> <!--Universidad: Propiedades--> <owl:ObjectProperty rdf:ID="tiene_Facultad"> <rdfs:domain rdf:resource="#Universidad" /> <rdfs:range rdf:resource="#Facultad" /> </owl:ObjectProperty> <!--Institucion: Facultad--> <owl:Class rdf:ID="Facultad"> <rdfs:label>facultad</rdfs:label> <rdfs:comment>Representacion de una Facultad, como tipo de institucion de Educacion</rdfs:comment> <owl:Restriction> <owl:onProperty rdf:resource="#tiene_Departamento"/>

120

<owl:minCardinality rdf:datatype="&xsd;nonNegativeInteger">1</owl:minCardinality> </owl:Restriction> <rdfs:subClassOf rdf:resource="#Educacion"> </owl:Class> <!--Facultad: Propiedades--> <owl:ObjectProperty rdf:ID="tiene_Departamento"> <rdfs:domain rdf:resource="#Facultad" /> <rdfs:range rdf:resource="#Departamento_carrera" /> </owl:ObjectProperty> <!--Institucion: Departamento_carrera--> <owl:Class rdf:ID="Departamento_carrera"> <rdfs:label>departamento_de_carrera</rdfs:label> <rdfs:comment>Representacion de un Departamento de Carrera, como tipo de institucion de Educacion</rdfs:comment> <rdfs:subClassOf rdf:resource="#Educacion"> </owl:Class> <!--Ejemplo de instancia: DCC como instancia de Departamento de carrera--> <Departamento_carrera rdf:ID="DCC_uchile"> <rdfs:label>Departamento de Ciencias de la Computacion</rdfs:label> <rdfs:comment>DCC como instancia de un Departamento de Carrera</rdfs:comment> <Nombre_Institucion>"Departamento de Ciencias de la Computacion - Universidad de Chile"</Nombre_Institucion> <Director><Persona rdf:ID="Director_DCC"></Persona></Director> <Cargos>"Director"</Cargos> <Cargos>"Profesor Jornada Completa"</Cargos> <Cargos>"Profesor Media Jornada"</Cargos> <Cargos>"Secretaria"</Cargos> <Cargos>"Investigador"</Cargos> <Cargos>"Administrativo"</Cargos> <Cargos>"Auxiliar"</Cargos> <Cargos>"Tecnico"</Cargos> <Direccion_Institucion>"Banco Encalada 2120 Santiago Chile"</Direccion_Institucion> </ Departamento_carrera> </rdf:RDF>

121

Bibliografía.

122

[1] Ministerio Secretaría General de la Presidencia. 2004. Decreto Supremo N°81: Aprueba norma técnica para los órganos de la administración del Estado sobre interoperabilidad de documentos electrónicos. Diario Oficial. [2] Bravo Lillo, C. 2005. ¿Qué es la interoperabilidad. Disponible en http://www.menokitan.cl/index.php?option=com_content&task=view&id=80&Itemid=10. Leído el 13 de Abril de 2006. [3] Achiary, C. 2005. Interoperabilidad para el gobierno electrónico. X Congreso Internacional del CLAD sobre la Reforma del Estado y de la Administración Pública, Santiago, Chile. [4] World Bank. 2006. E-government. Disponible en http://www.worldbank.org/egov. Leído el 13 de Abril de 2006. [5] Ministerio Secretaría General de la Presidencia. 2006. Programa de Reforma y Modernización del Estado. Disponible en http://www.modernizacion.cl/1350/propertyname-2154.html. Leído el 26 de Junio de 2006. [6] Wikipedia. 2006. XML Schema. Disponible en http://es.wikipedia.org/wiki/Schema#Schema_XML. Leído el 26 de Junio de 2006 [7] W3C. 1999. Namespaces in XML - World Wide Web Consortium. Disponible en http://www.w3.org/TR/REC-xml-names/. Leído el 3 de agosto de 2006. [8] W3Schools. XML Schema Simple Elements. Disponible en http://www.w3schools.com/schema/schema_simple.asp. Leído el 3 de Agosto del 2006 [9] W3Schools. XML Schema Complex Elements. Disponible en http://www.w3schools.com/schema/schema_complex.asp. Leído el 3 de agosto de 2006. [10] Wikipedia. 2006. Metadato. Disponible en http://es.wikipedia.org/wiki/Metadatos. Leído el 09 Junio de 2006 [11] Cabinet Office, Office of the e-Envoy, Technology Policy Team, Interoperability Policy Advisor. 2004. e-Government Metadata Standard Version 3.0. UK GovTalk [12] Herman , Ivan. 2004. Current Development at W3C, and the Semantic Web. W3C Talk. Seúl, Corea. [13] Martínez, J. A. 2006. El uso de metadatos para mejorar la interoperabilidad del conocimiento en los servicios de administración electrónica.

123

[14] Lamarca, M.J. 1998. Hipertexto, el nuevo concepto de documento en la cultura de la imagen. Doctorado en Fundamentos, Metodología y Aplicaciones de las Tecnologías Documentales y Procesamiento de la Información. Universidad Complutense de Madrid, Facultad de Ciencias de la Información, Madrid, España. Disponible en http://www.hipertexto.info/documentos/meta_xml.htm. Leído el 28 de Marzo de 2006. [15] Gruber, Tom. Tom Gruber’s home page. Disponible en http://www-ksl.stanford.edu/people/gruber/. Leído el 14 de Agosto de 2006. [16] Martínez García, L y García García – Castro, C. Ontologías y Tesauros. Universidad Carlos III de Madrid, Madrid, España. Disponible en http://es.geocities.com/ontologias_y_tesauros/index.htm. Leído el 14 de Agosto de 2006. [17] Fernández-López, M. 2002. Meta-modeling for ontology development and knowledge exchange. Proceedings of the ECAI-02 Workshop on Ontologies and Semantic Interoperability. [18] Towards a Semantically-driven Software Engineering Environment for e-Government - Knut Hinkelmann – www.Ontogov.com [19]. Chiusano, J.M et al. (EPA Agency. USA). Requirements for an xml registry - May 2001. http://xml.gov/documents/completed/registryreport.pdf. [20] Pereira, A. 2005. Buenas prácticas para el diseño de esquemas XML del Gobierno de Chile. Ingeniero Civil en Computación. Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas, Santiago, Chile. [21] E-Government Unit Cabinet Office UK. 2005. e-Government Interoperability Framework Version 6.1. UK GovTalk. [22] OntoGov. 2006. Ontology-enabled e-Gov Service Configuration. Disponible en http://www.ontogov.com. Leído el el 26 de Junio de 2006. [23] Hinkelmann, K. 2005. Ontogov: Towards a Semantically-driven Software Engineering Environment for e-Government. Information Society Technologies. [24] O Riordan, A. 2006. GovDex Referente. Disponible en http://www.govdex.gov.au/confluence/display/GovDexReference/GovDex+Reference. Leído el 21 de Agosto de 2006. [25] O Riordan, A. 2006. GovDex Component Repository: Disponible en http://www.govdex.gov.au/confluence/pages/viewpage.action?pageId=647. Leído el 26 de Junio de 2006. [26] Office of the Government Chief Information Officer. 2006. XML SCHEMA DESIGN AND MANAGEMENT GUIDE-PART I: OVERVIEW Version 1.3. The Government of the Hong Kong Special Administrative Region. Honk Kong.

124

[27] Office of the Government Chief Information Officer. 2005. The HKSARG Interoperability Framework Version: 4.0. The Government of the Hong Kong Special Administrative Region: Honk Kong. [28] U.S. Office of Management and Budget. FEA Reference Model. Disponible en http://www.whitehouse.gov/omb/egov/a-2-EAModelsNEW2.html. Leído el 22 de Agosto de 2006. [29] U.S. Office of Management and Budget. 1999. Federal Enterprise Architecture Framework Version 1.1. The Chief Information Officers Council. [30] U.S. Office of Management and Budget. 2005. The Data Reference Model Version 2.0. The Chief Information Officers Council. [31] Comitê Executivo de Governo Eletrônico. 2004. e-PING Padrões de Interoperabilidade de Governo Eletrônico: Documento de Referência Versão 1.0. Governo Brasileiro. Brazil. [32] Gutiérrez, C. Buenas prácticas para el desarrollo de esquemas XML para elGobierno. Disponible en in3.cl/workshop2005/05_ClaudioGutierrez_Buenas_Practicas_Diseno_Documentacion_Electronica.pdf. Leído el 10 de Octubre de 2006. [33] W3C. 2004. OWL: The Ontology Web Language. Disponible en http://www.w3.org/TR/owl-features/. Leído el 17 de Octubre de 2006. [34] Wikipedia. 2006. CVS. Disponible en http://es.wikipedia.org/wiki/CVS. Leído el 23 de octubre de 2006. [35] Rozas, J.P. 2006. Documento Histórico del Proyecto Repositorio de esquemas XML. Ingeniería de Software (CC51A). Universidad de Chile, Facultad de Ciencias Físicas y Matemáticas. Santiago. Chile.