Post on 15-Oct-2018
LLEENNGGUUAAJJEE CCOOMMÚÚNN DDEE IINNTTEERRCCAAMMBBIIOO DDEE IINNFFOORRMMAACCIIÓÓNN
NNOOTTAASS EEXXPPLLIICCAATTIIVVAASS AA LLAA AARRQQUUIITTEECCTTUURRAA DDEE DDAATTOOSS
PLATAFORMA DE INTEROPERABILIDAD, PDI
INTRANET GUBERNAMENTAL
© República de Colombia - Derechos Reservados
Bogotá, D.C., Febrero de 2011.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 2 de 30
FORMATO PRELIMINAR AL DOCUMENTO
Título: LENGUAJE COMÚN DE INTERCAMBIO DE INFORMACIÓN NOTAS EXPLICATIVAS A LA ARQUITECTURA DE DATOS
Fecha elaboración aaaa-mm-dd:
2009-02-23
Sumario: Este documento tiene como objetivo dar claridad sobre los siguientes aspectos de la Arquitectura de Datos versión 5.0, con el propósito de facilitar el proceso de conceptualización de un Elemento de dato: – Documentación de metadatos (Fuente, Usos, Validación, Requiere y
Requerido por). – Definición de elementos de dato de tipo Lista y Grupo.
Palabras Claves: Usos, validación, expresiones regulares, metadato
Formato: DOC Lenguaje: Español
Fecha de publicación
aaaa-mm-dd: 2009-02-23
Fecha de modificación
aaaa-mm-dd: 2011-02-18
Dependencia: Ministerio de tecnologías de la Información y las Comunicaciones: Programa “Agenda de Conectividad” – Proyecto Intranet Gubernamental.
Código: Versión: 5.4 Estado: Aprobado
Categoría: Estándares
Autor (es): Informática Siglo 21 Heinsohn Business Technology
Firmas
Revisó: Milena Barbosa Consultor Técnico Dirección de Desarrollo Programa Agenda de Conectividad Lisney Forero Consultor Técnico REDCOM David Uribe Gerente Proyecto GEL-XML Heinsohn Business Technology
Aprobó: Johanna Pimiento Supervisor Contrato Programa Agenda de Conectividad Olga Lucía Sabogal Director de Consultoría REDCOM
Información Adicional:
Ubicación: El archivo magnético asociado al documento está localizado en
http://lenguaje.intranet.gov.co
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 3 de 30
CONTROL DE CAMBIOS
VERSIÓN FECHA RESPONSABLE NATURALEZA
1.0 2009-02-23 Luz Karime Valderrama Santibáñez
Creación del documento
2.0 2009-03-05 Luz Karime Valderrama Santibáñez
– Se ajustó el documento de acuerdo a las observaciones recibidas por el Programa Agenda de Conectividad y la Interventoría
– Se adicionaron las siguientes notas explicativas: 5.8 Fecha de Incorporación al Estándar GEL-XML. 5.9 Definición de Elementos de Tipo Grupo 5.10 Definición de Listas 5.11 Definición de Fuentes
3.0 2009-03-26 Luz Karime Valderrama Santibáñez
– Se adicionó una explicación a cada una de las Guías. – Se modificó la Figura 1. Lecturas recomendadas en GEL-
XML.
4.0 2009-04-07 Luz Karime Valderrama Santibáñez
Se ajustó la explicación de la nota a la arquitectura “5.6 Definición de los Usos del Elemento de dato”
5.0 2009-08-27 Flor Alba Rocha Heinsohn Business Technology
Se incluye el numeral 5.12 “Uso de identificadores de elementos de dato en idiomas diferentes al español”
5.1 2009-09-04 Roberto Contreras Pinto Heinsohn Business Technology
Se incluye el numeral 5.13 “Uso de identificadores de usos en idiomas diferentes al español” Se realizaron los ajustes de forma solicitados por la interventoría Redcom.
5.2 2010-02-05 Roberto Contreras Pinto Heinsohn Business Technology
Se eliminó la explicación de cómo se diligencia el formato de elementos simples de tipo numérico. Se eliminó la explicación de cómo se diligencia la fecha de incorporación del estándar. Se ajusta el numeral 5.8 “Definición de listas”. Se ajusta la definición de los grupos.
5.3 2010-06-04 Roberto Contreras Pinto Heinsohn Business Technology
Se incluye el manejo de elementos simple que son enumeraciones numeral 5.9.
5.4 2011-01-19 Roberto Contreras Pinto Heinsohn Business Technology
Ajuste en el formato preliminar de firmas Actualización de las referencias a la versión 5.0 del documento de arquitectura. Eliminación de la sección de que explicaba el uso del código de clasificación jerárquica, debido a que este metadato se eliminó de la arquitectura.
5.4 2011-02-14 Roberto Contreras Pinto Heinsohn Business Technology
Documento aprobado.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 4 de 30
TABLA DE CONTENIDO
DERECHOS DE AUTOR ....................................................................................................... 6
CRÉDITOS ......................................................................................................................... 7
1 INTRODUCCIÓN ........................................................................................................ 8
2 AUDIENCIA ................................................................................................................ 9
3 REQUISITOS ............................................................................................................ 10
4 ESTRUCTURA ........................................................................................................... 11
5 NOTAS EXPLICATIVAS A LA ARQUITECTURA .......................................................... 12
5.1 DOCUMENTACIÓN DE USOS DE LOS TIPOS DE DATO GEL-XML ................................... 12
5.2 EXPLICACIÓN DE EXPRESIONES REGULARES ............................................................ 13
5.3 DILIGENCIAMIENTO DEL METADATO REQUIERE ....................................................... 13
5.4 DILIGENCIAMIENTO DEL METADATO ES REQUERIDO POR ......................................... 14
5.5 DEFINICIÓN DE LOS USOS DEL ELEMENTO DE DATO ................................................. 15
5.6 VALIDACIONES ....................................................................................................... 16
5.7 DEFINICIÓN DE ELEMENTOS DE TIPO GRUPO ........................................................... 17
5.8 DEFINICIÓN DE LISTAS ........................................................................................... 21
5.9 CRITERIOS DE USO DE ELEMENTOS DE DATO SIMPLE CON ENUMERACIÓN ................ 23
5.10 DEFINICIÓN DE FUENTES ........................................................................................ 23
5.11 UTILIZACIÓN DE IDENTIFICADORES DE ELEMENTOS DE DATO EN IDIOMA DIFERENTE
AL ESPAÑOL ........................................................................................................................ 25
5.12 UTILIZACIÓN DE IDENTIFICADORES DE USOS EN IDIOMA DIFERENTE AL ESPAÑOL .... 27
5.13 PROTOCOLO DE ADAPTACIONES E INCORPORACIONES DE REPRESENTACIÓN DE
CLASIFICACIONES, NOMENCLATURAS Y/O LISTADOS ............................................................ 28
5.14 REGLAS Y PROTOCOLOS DE CONSTRUCCIÓN DE CLASIFICACIONES, NOMENCLATURAS Y
LISTADOS (EN ESPAÑOL Y OTROS IDIOMAS) ........................................................................ 29
5.15 PROTOCOLO DE MOVIMIENTO DE ELEMENTOS DE DATO EN CAPAS ........................... 30
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 5 de 30
LISTA DE FIGURAS Y TABLAS
Figura 1. Lecturas recomendadas ............................................................................... 9
Figura 2. Definición de usos para los Tipos de Dato GEL-XML ..................................... 12
Figura 3. Documentación de expresiones regulares ..................................................... 13
Figura 4. Documentación del metadato “Requiere” ...................................................... 14
Figura 5. Documentación del metadato “Requerido por” ............................................... 15
Figura 6. Definición de los usos de un elemento de dato .............................................. 16
Figura 7. Documentación de validaciones realizadas por sistemas informáticos ............. 17
Figura 8. Definición de un elemento de dato de tipo grupo ............................................ 18
Figura 9. Definición de un elemento de dato de tipo grupo ............................................ 19
Figura 10. Definición de un elemento de dato de compuesto en lugar de un elemento de
dato de tipo grupo ..................................................................................................... 20
Figura 11. Formato del elemento de dato agrupador ................................................... 21
Figura 12. Formato del elemento de dato tipo lista ...................................................... 22
Figura 13. Formato de elemento de dato con varias ocurrencias .................................. 22
Figura 14. Documentación del metadato “Fuente” ....................................................... 24
Figura 15. Definición del elemento de dato con identificadores en idioma diferente al
español .................................................................................................................... 26
Figura 16. Definición del uso en idioma diferente al español ........................................ 27
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 6 de 30
DERECHOS DE AUTOR
menos que se indique de forma contraria, el copyright del texto incluido en este documento es del Gobierno de la República de Colombia. Se PUEDE reproducir gratuitamente en cualquier formato o medio sin requerir un permiso expreso para
ello, bajo las siguientes condiciones: 1. El texto particular no se ha indicado como excluido y por lo tanto NO PUEDE ser copiado o distribuido. 2. La copia no se hace con el fin de distribuirla comercialmente. 3. Los materiales se DEBEN reproducir exactamente y no se deben utilizar en un contexto engañoso. 4. Las copias serán acompañadas por las palabras "copiado/distribuido con permiso del Gobierno de la República de Colombia. Todos los derechos reservados." 5. El título del documento DEBE ser incluido al ser reproducido como parte de otra publicación o servicio. Si se desea copiar o distribuir el documento con otros propósitos, DEBE solicitar el permiso entrando en contacto con el programa Agenda de Conectividad del Ministerio de tecnologías de la Información y las Comunicaciones de la República de Colombia.
A
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 7 de 30
CRÉDITOS
a información y datos contenidos en la versión 1.0 del documento fueron elaborados inicialmente por la empresa Informática Siglo 21, en el año 2009, y son el resultado de las actividades propias de la evolución del lenguaje
común de intercambio de información.
Las actualizaciones a este documento a partir de la versión 5.0 fueron realizadas por Heinsohn Business Technology, en desarrollo del contrato de mantenimiento del lenguaje común de intercambio de información, las cuales estuvieron enfocadas a la simplificación y evolución de ésta guía acorde con las nuevas necesidades generadas en el mejoramiento del lenguaje común de intercambio de información.
L
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 8 de 30
1 INTRODUCCIÓN
a Arquitectura de Datos define los lineamientos que se DEBEN seguir para realizar un uso adecuado del lenguaje común de intercambio de información.
Dentro de estos lineamientos el presente documento tiene como finalidad realizar aclaraciones y explicaciones de la manera en que se DEBEN definir algunos tipos de elemento de dato y la usabilidad de algunos metadatos definidos en el documento Arquitectura de Datos versión 5.0, con el propósito de proveer más detalle para el proceso de conceptualización de los elementos de dato del lenguaje común de intercambio de información.
L
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 9 de 30
2 AUDIENCIA
ste documento es un anexo a la Arquitectura de Datos versión 5.0 y está dirigido al personal que se encuentre a cargo de la administración del estándar. Este cuerpo regulador tiene la responsabilidad de asegurar que las
diferentes entidades que participan en Gobierno en Línea cumplan con todas las reglas establecidas en el lenguaje común de intercambio de información.
Figura 1. Lecturas recomendadas
E
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 10 de 30
3 REQUISITOS
ste documento es un anexo a la Arquitectura de Datos versión 5.0, por lo que la lectura de éste es prerrequisito para la comprensión del documento Notas Explicativas.
E
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 11 de 30
4 ESTRUCTURA ara facilitar el aprendizaje y la comprensión de las reglas, cada sección incluye una introducción al tema y especifica un conjunto de guías que manejan la siguiente estructura:
“Guía”: Provee información detallada de cómo diligenciar los metadatos, para la conceptualización de los elementos de dato del estándar.
“Explicación”: Provee información más detallada sobre la razón para la adopción de la guía.
“Ejemplo”: Ilustra mediante gráficas el uso de la guía en particular.
P
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 12 de 30
5 NOTAS EXPLICATIVAS A LA ARQUITECTURA
ste capítulo interpreta y explica la Arquitectura de Datos versión 5.0, para la conceptualización de nuevos los elementos de dato.
5.1 DOCUMENTACIÓN DE USOS DE LOS TIPOS DE DATO GEL-XML
a) Guía
Los usos definidos para los tipos de dato GEL-XML, DEBEN ser documentados en la plantilla de metadatos, tal como se realiza en la conceptualización de los usos de los elementos de dato del estándar.
Explicación
Los tipos de dato GEL-XML permiten parametrizar características similares de elementos de dato, la definición de usos facilitan la contextualización de los conceptos definidos a partir de tipos de dato GEL-XML.
Ejemplo
Para determinado elemento de dato, por ejemplo el tipo de dato Cadena 512 los usos se documentarían de la siguiente manera:
Figura 2. Definición de usos para los Tipos de Dato GEL-XML
E
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 13 de 30
5.2 EXPLICACIÓN DE EXPRESIONES REGULARES
a) Guía
En caso de utilizarse una expresión regular en la definición del Formato de un elemento de dato de tipo simple, ésta DEBE explicarse de forma general en el metadato Validación.
Explicación
La inclusión de una explicación general de expresiones regulares en el metadato Validación, permite dar mayor claridad al lector sobre el formato del elemento de dato.
Ejemplo
Para determinado elemento de dato, por ejemplo Número de Cédula de Ciudadanía la explicación general de la expresión regular utilizada, se DEBE documentar en el metadato Validación de la siguiente manera:
Figura 3. Documentación de expresiones regulares
5.3 DILIGENCIAMIENTO DEL METADATO REQUIERE
a) Guía
El metadato “Requiere” DEBE diligenciarse con los nombres de los elementos de dato que son Requeridos.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 14 de 30
Explicación
El metadato Requiere no se DEBE diligenciar con los identificadores de los elementos de dato, ya que debido a las reglas definidas en la Arquitectura de Datos para su conformación, éstos pueden no ser significativos para el lector.
Ejemplo
Para determinado elemento de dato, por ejemplo Nombre Persona, el metadato “Requiere” se DEBE documentar de la siguiente manera:
Figura 4. Documentación del metadato “Requiere”
5.4 DILIGENCIAMIENTO DEL METADATO ES REQUERIDO POR
a) Guía
El metadato “Es requerido por” DEBE diligenciarse con los nombres de los elementos de dato que hacen uso del elemento de dato.
Explicación
El metadato Es Requerido por no se DEBE diligenciar con los identificadores de los elementos de dato, ya que debido a las reglas definidas en la Arquitectura de Datos para su conformación, éstos pueden no ser significativos para el lector.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 15 de 30
Ejemplo
Para determinado elemento de dato, por ejemplo Dirección de Correo Electrónico, el metadato “Es requerido por” se DEBE documentar de la siguiente manera:
Figura 5. Documentación del metadato “Requerido por”
5.5 DEFINICIÓN DE LOS USOS DEL ELEMENTO DE DATO
a) Guía
El nombre y el identificador del uso definido para un elemento de dato, DEBEN ser diferentes al nombre e identificador de dicho elemento de dato.
Explicación
Utilizar el mismo identificador en un elemento de dato y en un uso hace que no sea posible diferenciar semánticamente la definición del uso y la definición del elemento de dato.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 16 de 30
Ejemplo
Para determinado elemento de dato, por ejemplo Fecha, los usos identificados se DEBEN documentar de la siguiente manera:
Figura 6. Definición de los usos de un elemento de dato
5.6 VALIDACIONES
a) Guía
Si en el metadato “Validación” se hace necesario incluir validaciones, que deben ser realizadas por sistemas de información que hacen uso del elemento de dato, se DEBE anteponer el siguiente texto: “El servicio informático que utilice el Elemento de Dato deberá validar que…”.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 17 de 30
Explicación
Es conveniente la inclusión del texto “El servicio informático que utilice el Elemento de Dato deberá validar que…” en el metadato Validación, para dar claridad al lector.
Ejemplo
Para determinado elemento de dato, por ejemplo Código Subpartida NANDINA, el metadato Validación se DEBE documentar de la siguiente manera:
Figura 7. Documentación de validaciones realizadas por sistemas informáticos
5.7 DEFINICIÓN DE ELEMENTOS DE TIPO GRUPO
a) Guía
Un grupo es un elemento de dato de tipo compuesto que DEBE cumplir con las siguientes características:
Solo uno de los elementos de dato que lo componen es obligatorio (los elementos de dato son mutuamente excluyentes)
Los elementos de dato que lo componen están enmarcados bajo un mismo concepto
Explicación
Un grupo es la representación de la selección de una opción entre varias y que están relacionadas al representar el mismo tipo de información.
Ejemplo
Para definir un elemento de dato que agrupe el tipo de parentesco que pudiera existir entre dos personas, el cual puede ser por consanguinidad,
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 18 de 30
civil o afinidad, se hace necesario definir un grupo, ya que desde el punto de vista jurídico estos tipos de parentesco son excluyentes.
Figura 8. Definición de un elemento de dato de tipo grupo
b) Guía
Se DEBE definir elementos de dato de tipo Grupo, cuando todos los elementos de dato que lo componen se encuentran ubicados en el área donde se requiere crear el Grupo.
Explicación
Para evitar referencias circulares entre las áreas de las capas, el elemento de dato de tipo Grupo que se defina, DEBE estar ubicado en el área donde se encuentran los elementos de dato que lo componen.
Ejemplo
Para definir un elemento de dato que agrupe las diferentes formas por la cuales se puede identificar una persona, las cuales pueden ser:
– Número Cédula Ciudadanía
– Número Tarjeta Identidad
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 19 de 30
– Número Registro Civil
– Número Identificación Adulto Sin Identificar
– Número Identificación Menor Sin Identificar
– Número Identificación Recién Nacido
Se DEBE crear un elemento de dato de tipo Grupo, el cual DEBERÁ estar ubicado en el área Identificación, ya que todos los elementos de dato que lo componen están ubicados en dicha área.
Figura 9. Definición de un elemento de dato de tipo grupo
c) Guía
Si se requiere definir un elemento de dato compuesto donde los elementos de dato que lo componen deben ser excluyentes, pero no todos se encuentran ubicados en la misma área de una capa, se RECOMIENDA definir el elemento de dato con la siguiente estructura:
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 20 de 30
Elemento de Dato Nombre Número de
Ocurrencias
Elemento Tipo idUsoElementoTIpo 1
Elemento opción 1 idUsoElemento1 0..1
Elemento opción 2 idUsoElemento2 0..1
Elemento opción n idUsoElementon 0..1
Explicación
Para evitar referencias circulares entre las áreas de las capas, se recomienda utilizar un elemento de dato de tipo enumeración cuyo número de ocurrencias sea obligatorio y un elemento de dato por cada opción del listado cuyo número de ocurrencias sea opcional.
Ejemplo
Por ejemplo, para definir un elemento de dato que permita enviar la información del tipo de persona, que ejerce actividades que tienen que ver con el descubrimiento y la explotación de yacimientos minerales, se debe utilizar los elementos de dato tipoPersona, tipoInformacionPersonaNatural y tipoInformacionPersonaJuridica, definiendo la siguiente estructura:
Figura 10. Definición de un elemento de dato de compuesto en lugar de un elemento de dato de tipo grupo
No se DEBE crear un grupo con los elementos de dato tipoInformacionPersonaNatural y tipoInformacionPersonaJuridica, ya que éstos están ubicados en áreas diferentes de la capa de uso Local.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 21 de 30
5.8 DEFINICIÓN DE LISTAS
a) Guía
Si un elemento de dato en su formato está compuesto por dos o más elementos de dato que tienen más de una ocurrencia, estos elementos de dato se DEBEN definir como una Lista.
Explicación
Para enviar la información de manera organizada y estructurada, es necesario definir un elemento de dato compuesto que agrupe los elementos de dato que se repitan y definir un elemento de dato compuesto, que contenga las ocurrencias de éste.
Ejemplo
Dentro de la información relacionada con la hoja de vida de un funcionario público se necesita tener en cuenta los idiomas que la persona habla, la experiencia laboral entre otros. Cómo se necesitan definir varios listados se DEBE definir un elemento de dato por cada lista que agrupe la información de idioma y experiencia laboral.
Figura 11. Formato del elemento de dato agrupador
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 22 de 30
Figura 12. Formato del elemento de dato tipo lista
b) Guía
Si un elemento de dato en su formato está compuesto por un elemento de dato que tiene más de una ocurrencia, No se DEBE crear un elemento de dato que lo agrupe.
Explicación
No generar un nivel adicional de anidamiento.
Ejemplo
El formato del elemento de dato solo tiene un listado; por tal razón no se define un elemento de dato que lo agrupe y se define el número de ocurrencias.
Figura 13. Formato de elemento de dato con varias ocurrencias
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 23 de 30
5.9 CRITERIOS DE USO DE ELEMENTOS DE DATO SIMPLE CON
ENUMERACIÓN
a) Guía
No se DEBEN definir elementos de dato simple con enumeraciones si:
Los valores permitidos de la enumeración no corresponden a un estándar nacional o internacional.
Los valores permitidos de la enumeración corresponden a tablas o registros del dueño de los datos que no aporten valor semántico en el intercambio de información.
Los valores permitidos de la enumeración son muy dinámicos.
Explicación
Se evita crear una enumeración de valores permitidos en el estándar que no aportan beneficio al proceso de intercambio de información.
b) Guía
Se DEBE diligenciar en el metadato validación la fuente de referencia de los valores de la enumeración siempre que se tenga la fuente.
Explicación
Permite al usuario del elemento de dato identificar los valores de la enumeración que se pueden utilizar en el uso del elemento de dato.
5.10 DEFINICIÓN DE FUENTES
a) Guía
Se recomienda el uso de fuentes mucho más específicas cuando una definición es construida a partir de diferentes fuentes.
Explicación
Debido a que la descripción de un elemento de dato puede ser construida a partir de diversas fuentes, es conveniente realizar una diferenciación en la descripción y relacionarla con las fuentes utilizadas.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 24 de 30
Ejemplo
Para determinado elemento de dato, por ejemplo Dato Menor Edad, el metadato “Fuente” se DEBERÍA documentar de la siguiente manera:
Figura 14. Documentación del metadato “Fuente”
b) Guía
Se recomienda seguir los siguientes lineamientos para diligenciar de una manera más precisa la fuente dependiendo del origen de la misma.
Si la descripción del elemento de dato es construida a partir de documentos aportados por la entidad como casos de uso, especificación entre otros, se DEBERÁ indicar la razón social completa de la entidad, nombre del archivo usado, y la fecha.
Si la fuente es tomada de Internet debe contener una URL Valida. Debe contener los siguientes datos:
o Autor o Titulo Seguido de [en línea] o Dirección URL o Fecha de último acceso entre corchetes [citado en: aaaa-mm-dd]
La URL debe corresponder a páginas oficiales si corresponde a estándares oficiales, sitios de entidades, sitios reconocidos, pero nunca a sitios que correspondan a páginas personales o comerciales.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 25 de 30
Si la fuente es tomada de un libro, aplican las normas de una referencia bibliográfica es decir:
o Autor o Nombre del Libro o Fecha de Edición o Editorial del Libro o Ciudad de Edición o En el caso que aplique: Página
Si la fuente es tomada de una Ley o un Decreto, debe contener:
o Número de la Ley ó Decreto o Año o Articulo
En el caso que aplique: Numeral, Literal y Parágrafo.
En el caso que sea una Resolución: Número, Fecha, Parágrafos
Si la descripción es construida (creada a partir de la experiencia de un experto) se DEBERÁ indicar en la fuente la forma mediante la cual se obtuvo la información, entidad, el nombre de la persona que la suministró, su cargo u oficio, ciudad y fecha de obtención.
El orden de las fuentes debe ser:
o Leyes-decretos o W3C o Definición aportada por experto o Documentos de Casos de Uso o Definiciones de Internet.
5.11 UTILIZACIÓN DE IDENTIFICADORES DE ELEMENTOS DE DATO EN
IDIOMA DIFERENTE AL ESPAÑOL
a) Guía
Se recomienda que para los identificadores de los elementos de dato cuyo idioma de origen sea diferente al español, se conserven en dicho idioma sólo para los elementos de dato ubicados en la capa de uso internacional.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 26 de 30
Explicación
Debido a que los identificadores de los elementos de dato y las etiquetas de los estándares internacionales vienen en idioma diferente al español estos DEBEN conservarse en lo posible en su idioma de origen para evitar incompatibilidades en el intercambio de datos.
Ejemplo Para los elementos de dato ubicados en la capa de uso internacional en donde se ubican los elementos de dato que hacen parte ó se encuentran definidos en estándares internacionales, se DEBE conservar el identificador del elemento de dato en el idioma de origen de la siguiente manera:
Figura 15. Definición del elemento de dato con identificadores en idioma diferente al español
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 27 de 30
5.12 UTILIZACIÓN DE IDENTIFICADORES DE USOS EN IDIOMA DIFERENTE
AL ESPAÑOL
a) Guía
Se recomienda que para los identificadores de los usos cuyo idioma de origen sea diferente al español, se conserven en dicho idioma sólo para los elementos de dato ubicados en la capa de uso internacional.
Explicación
Debido a que los identificadores de los usos de los elementos de dato y las etiquetas de los estándares internacionales vienen en idioma diferente al español estos DEBEN conservarse en lo posible en su idioma de origen para evitar incompatibilidades en el intercambio de datos.
Ejemplo Para los elementos de dato ubicados en la capa de uso internacional en donde se ubican los elementos de dato que hacen parte ó se encuentran definidos en estándares internacionales, se DEBE conservar el identificador del elemento de dato del uso en el idioma de origen de la siguiente manera:
Figura 16. Definición del uso en idioma diferente al español
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 28 de 30
5.13 PROTOCOLO DE ADAPTACIONES1 E INCORPORACIONES2 DE
REPRESENTACIÓN DE CLASIFICACIONES3, NOMENCLATURAS4 Y/O
LISTADOS
A continuación se presentan las reglas de inclusión de clasificaciones, nomenclaturas y/o
listados:
1. Buscar si existe una clasificación sobre el mismo concepto a nivel internacional o nacional respaldada por una institución de normalización, de ser así SE DEBE incorporar la clasificación, nomenclatura y/o listado existente (según el paso 3) Se debe dar prioridad a clasificaciones nacionales5.
2. Buscar si existe una clasificación existente sobre el mismo concepto a nivel internacional en el idioma español, de ser así SE DEBE incorporar la clasificación, nomenclatura y/o listado existente en español (según el paso 3).
3. Incluir los códigos de la clasificación internacional y/o nacional (en caso de que existan) e incluir las descripciones de los códigos en español (en caso que existan).
4. Si las descripciones disponibles no se entienden o no están contextualizadas para Colombia se DEBE crear un elemento de dato con las descripciones contextualizadas para Colombia. Las adaptaciones deben ser respaldadas por un ente oficial.
5. NO SE DEBE modificar los códigos de las clasificaciones.
Se debe dar prioridad a las clasificaciones utilizadas por el DANE ya que dichas
clasificaciones se consideran como oficiales dentro de Colombia y el DANE realiza las
respectivas adaptaciones al país.
1 Clasificaciones resultantes de modificar la estructura de una clasificación adoptada de tal forma que refleje
las características económicas y sociales de un país.
2 Uso directo de un listado externo para cualificar objetos.
3 Agrupamiento de fenómenos u objetos, en conjuntos homogéneos, exhaustivos y mutuamente excluyentes,
de acuerdo con criterios preestablecidos y en función del uso que tendrá la clasificación.
4 Asignación sistemática de nombres a cosas o un sistema de nombres o términos para cosas.
5 En Colombia el organismo rector de las clasificaciones es el DANE.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 29 de 30
5.14 REGLAS Y PROTOCOLOS DE CONSTRUCCIÓN DE CLASIFICACIONES,
NOMENCLATURAS Y LISTADOS (EN ESPAÑOL Y OTROS IDIOMAS)
A continuación se presentan las reglas de construcción de clasificaciones, nomenclaturas
y/o listados en otros idiomas:
En el caso de que no exista la clasificación dentro del estándar y se tenga la información tanto de la clasificación Internacional como la adaptada a Colombia, se incorporará al estándar la Clasificación adaptada a Colombia.
Si la adaptación corresponde sólo a la descripción de ítems de la clasificación, se DEBERÁ definir un elemento de dato para el código de la clasificación en la capa de Uso Común y se define otro elemento de dato para la descripción del código en la capa de Uso Local. Esta separación de capas se hace debido a que no todas las descripciones aplican a nivel Común. Es posible tener diferencias en el uso del idioma, por lo tanto, la descripción en la capa de Uso Local solo aplicaría (sería entendible) para Colombia.
Si la adaptación de la clasificación incluye modificaciones a los códigos, se DEBERÁ definir los elementos de dato para el código y la descripción en la capa de Uso Local.
Si la definición del elemento de dato es almacenada en un archivo, un acrónimo de del idioma de la plantilla se pondrá como sufijo (basado en un listado estándar, por ejemplo ES-CO, EN-US, etc.) en el nombre del archivo, por ejemplo ES-CO o EN-US. Si no existe dicho sufijo se entiende que por defecto el idioma es español de Colombia.
En el caso que el esquema corresponda a una codificación, éste tendrá las descripciones de los códigos en los idiomas que se hayan definido. Para el caso de los elementos de dato de las capa de uso Común y Local, PUEDEN ser inglés y español. En caso de hacer una modificación en las descripciones de una clasificación, nomenclatura y/o listado, la versión del esquema y de la definición del elemento de dato DEBE cambiar de versión menor.
Las correspondencias6 entre las clasificaciones no se definirán dentro del estándar, ya que las correspondencias no son conceptos de intercambio dentro del lenguaje común de intercambio de información.
6 El término correspondencia aquí es utilizado como la relación de una categoría de una clasificación con dos o
más categorías de una o varias clasificaciones. (http://www.dane.gov.co/files/nomenclaturas/glosario.pdf) Por
ejemplo se puede tener una clasificación para actividad económica y otra para tipo de productos. Si la
actividad económica es la agricultura tiene una relación (correspondencia) con productos como hortalizas.
NOTAS EXPLICATIVAS A LA
ARQUITECTURA DE DATOS
Página 30 de 30
Se debe preferir utilizar clasificaciones ya existentes en vez de crearlas debido a que
facilita el intercambio con las Entidades que ya las están utilizando como también evita
errores en la creación de las mismas.
5.15 PROTOCOLO DE MOVIMIENTO DE ELEMENTOS DE DATO EN CAPAS
Al mover un elemento de una capa o área se DEBE tener en cuenta:
1. Identificar los elementos de dato que requieren el elemento de dato a mover. 2. Consultar con los interesados (usuarios o creadores) de los elementos de dato que
serán reubicados y los identificados en el punto 1, sobre la factibilidad de hacer el movimiento. Si no hay objeciones ir al punto 4.
3. Discutir, analizar y acordar sobre la factibilidad del movimiento del elemento de dato con los interesados, se deberán analizar los siguientes puntos:
a. Número de elementos afectados b. Valor que daría al estándar mover el elemento. c. Impacto sobre los desarrollos de los interesados (económico y de tiempo)
4. Si el movimiento es aprobado, se realiza el numeral 4.a, Si el movimiento no es aprobado se realiza el numeral 4.b
a. La solicitud será generada por el organismo según las decisiones tomadas en el punto 3 para ajustar los elementos de dato que se hagan necesarios.
b. La solicitud de servicio se analizará para la siguiente versión mayor del estándar de Intercambio, el análisis se realizará según lo mencionado en el punto 3.
Se da facultad al Organismo de Administración y Gestión del lenguaje común de intercambio de información de generar la solicitud del punto 4.b, debido a que por experiencia las entidades pueden tardar en enviar las solicitudes de modificación sobre los elementos de dato.