1.309,2k - Lenguaje común para intercambio de información

Transcripción

LENGUAJE COMÚN DE INTERCAMBIO DE INFORMACIÓN
EVALUACIÓN DE ESTÁNDARES INTERNACIONALES
PLATAFORMA DE INTEROPERABILIDAD, PDI
INTRANET GUBERNAMENTAL
© República de Colombia - Derechos Reservados
Bogotá D.C., Noviembre de 2013
EVALUACIÓN DE ESTÁNDARES
INTERNACIONALES
FORMATO PRELIMINAR AL DOCUMENTO
Título:
Fecha elaboración
aaaa-mm-dd:
Sumario:
Palabras Claves:
Formato:
Fecha
de
publicación
aaaa-mm-dd:
Dependencia:
Código:
Categoría:
Autor (es):
Revisó:
Aprobó:
LENGUAJE COMÚN DE INTERCAMBIO DE INFORMACIÓN EVALUACIÓN DE
ESTÁNDARES INTERNACIONALES
2009-09-15
Presentar el proceso y los criterios de inclusión de estándares internacionales al
lenguaje común de intercambio de información
Estándares.
DOC
Lenguaje:
Español
Fecha de modificación
2009-09-15
aaaa-mm-dd:
2013-12-05
Ministerio de Tecnologías de la Información y las Comunicaciones:
Dirección de Gobierno en línea –Intranet Gubernamental.
Versión:
6.0
Estado:
Aprobada
Estándares
César Ariza
Líder Técnico - Informática Siglo 21
Roberto Contreras
Arquitecto -Heinsohn Business Technology
Danilo Castro
Arquitecto – CINTEL
Fabián Acevedo
Grupo de Trabajo de la Infraestructura de
Datos Espaciales y Gestión de Información
Geográfica (IDE y GIG) – Instituto
Geográfico Agustín Codazzi
Unión Temporal Synapsis – Level 3 UT-SG
Johanna Pimiento
Supervisor Contrato
Programa Agenda de Conectividad
Lisney Forero
Consultor Técnico
REDCOM
David Uribe Pardo
Gerente Proyecto GEL-XML
Heinsohn Business Technology
Angelica Jaramillo
Dirección de Gobierno en línea
Johanna Pimiento
Supervisor Contrato
Programa Agenda de Conectividad
Página 2 de 88
INTERNACIONALES
Lisney Forero
Consultor Técnico
REDCOM
David Uribe Pardo
Gerente Proyecto GEL-XML
Heinsohn Business Technology
Rafael Londoño
Dirección de Gobierno en línea
Información
Adicional:
Ubicación:
El archivo magnético asociado al documento está localizado en
http://lenguaje.intranet.gov.co
Página 3 de 88
INTERNACIONALES
CONTROL DE CAMBIOS
VERSIÓN
1.0
FECHA
2008-02-07
RESPONSABLE
Equipo GEL-XML / César
Ariza
Ariza
2.0
2008-06-12
3.0
2008-06-25
Ariza
4.0
2008-07-09
Ariza
4.1
2010-04-21
Roberto Contreras Heinsohn
Business Technology
5.0
2011-01-18
Business Technology
5.1
2011-02-03
5.2
2011-10-07
6.0
2013-12-05
Business Technology
Danilo Castro
CINTEL
Fabián Acevedo
Grupo de Trabajo de la
Infraestructura de Datos
Espaciales
y Gestión de Información
Geográfica
(IDE y GIG) – Instituto
Geográfico
Agustín Codazzi
UT-SG
DESCRIPCIÓN
Creación del documento.
Profundización en el análisis de los estándares
internacionales
Ajustes en los antecedentes de aplicación de estándares
internacionales.
Inclusión del proceso de adopción
Ajustes de forma a la presentación de los procesos.
Inclusión de ejemplos XML de los estándares analizados
en el documento.
Ajustes de forma
Eliminación de estados incorporación de los
estándares internacionales.
Ajuste de logos del Ministerio y de Gobierno en Línea.
Ajuste del nombre del Ministerio.
Ajuste de redacción.
Modificación del capítulo 5 de acuerdo a la
evolución de proceso de atención de solicitudes.
Se eliminaron las referencias que se hacían en el
documento al uso exclusivo de XML, como único casal
de intercambio de información.
Modificación del capítulo 5 de acuerdo a la
evolución de proceso de atención de solicitudes.
Se eliminó la sección 5.2 Adaptadores; debido a que
estaba enfocada desde un punto de vista técnico u no
semántico y al uso exclusivo de XML.
Se eliminaron términos que no se usaban en el
documento
Cambio de la sección 5; debido al replanteamiento del
proceso.
Ajustes de forma a la presentación
Adición de estándares correspondientes a ICDE
Ajustes de acuerdo al trabajo actual realizado en cuanto
a incorporación de nuevos estándares
Página 4 de 88
INTERNACIONALES
TABLA DE CONTENIDO
LENGUAJE COMÚN DE INTERCAMBIO DE INFORMACIÓN EVALUACIÓN DE ESTÁNDARES
INTERNACIONALES
1
1. DERECHOS DE AUTOR
7
2. CRÉDITOS
8
3. AUDIENCIA
9
4. INTRODUCCIÓN
10
5. ANTECEDENTES
11
5.1 MOTIVACIÓN ...............................................................................................................11
5.2 HACIA LA SOCIEDAD DEL CONOCIMIENTO ...............................................................................12
5.3 GENERALIDADES..........................................................................................................14
6. XBRL
15
7. HL7 (HEALTH LEVEL SEVEN) - CDA
19
8. LEGAL-XML
23
9. ESTÁNDARES DEL OPEN GEOSPATIAL CONSORTIUM (OGC) PARA INFORMACIÓN
GEOGRÁFICA Y YNTC 4611 PARA DESCRIPCIÓN DE METADATOS GEOGRÁFICOS
25
9.1 WMS ...........................................................................................................................28
9.2 WFS ............................................................................................................................31
9.3 NTC 4611 – ISO 19115 ..................................................................................................33
10. DUBLIN CORE
38
10.1 ELEMENTOS DEL DC. ........................................................................................................39
11. SERVICIOS TERMINOLÓGICOS EN SALUD
Diagnóstico
Tecnologías en Salud
58
59
59
11.1 CLASIFICACIONES INTERNACIONALES PARA LOS SERVICIOS TERMINOLÓGICOS EN SALUD. ...................60
Diagnóstico
60
Enfermedades - CIE-10
60
Atención Primaria en Salud - ICPC
61
Funcionalidad - CIF
61
11.2 TECNOLOGÍAS EN SALUD ....................................................................................................61
Procedimientos en Salud - CUPS
61
Medicamentos
63
Dispositivos Médicos
63
Página 5 de 88
INTERNACIONALES
12. LINEAMIENTOS PARA LA SELECCIÓN DE ESTÁNDARES INTERNACIONALES DE
INTERCAMBIO DE INFORMACIÓN
64
13. PROCESO PARA INCLUSIÓN DE ESTÁNDARES INTERNACIONALES EN LENGUAJE
COMÚN DE INTERCAMBIO DE INFORMACIÓN
65
14. TERMINOLOGÍA
65
15. CONCLUSIONES
67
16. TRABAJO FUTURO
68
17. APENDICES
69
17.1 APÉNDICE A: PALABRAS CLAVES A UTILIZAR PARA INDICAR NIVELES DE REQUERIMIENTO
(RFC 2119)..........................................................................................................................69
17.2 EXTRACTO DE LEGAL-XML.............................................................................................71
17.3 EXTRACTO DE HL7 .......................................................................................................71
17.4 EXTRACTO DE XBRL......................................................................................................72
18. ANEXOS
74
18.1 ELEMENTOS DE DATO DE WMS......................................................................................74
18.2 ELEMENTOS DE DATO DE WFS ......................................................................................84
Página 6 de 88
INTERNACIONALES
1. DERECHOS DE AUTOR
A
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:

El texto particular no se ha indicado como excluido y por lo tanto NO PUEDE ser copiado o
distribuido.

La copia no se hace con el fin de distribuirla comercialmente.

Los materiales se DEBEN reproducir exactamente y no se deben utilizar en un contexto
engañoso.

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."

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 la Dirección de Gobierno en línea del Ministerio de
Tecnologías de la Información y las Comunicaciones de la República de Colombia
Página 7 de 88
INTERNACIONALES
2. CRÉDITOS
L
a empresa Informática Siglo 21, dentro del marco del proyecto Administración y Gestión del
lenguaje común de intercambio de información, en febrero de 2008 generó una propuesta inicial
de evaluación e inclusión de estándares internacionales dentro del estándar.
La información y datos incluidos en este documento, hacen parte de las observaciones, comentarios,
aportes e investigaciones realizadas por la empresa Informática Siglo 21, el Programa Agenda de
Conectividad y la interventoría del citado proyecto.
Las actualizaciones a este documento a partir de la versión 4.1 fueron realizadas por el grupo
encargado de realizar la operación del estándar por parte 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 maderamiento del Lenguaje común de intercambio de información.
A partir del mes de junio de 2012 la operación de Lenguaje Común de Intercambio de Información
queda a cargo de la Unión Temporal Synapsis Level 3 (UT-SG), quienes a partir de la versión 6.0
realizaron los modificaciones necesarias al documento de acuerdo a los lineamientos establecidos de
la estrategia de Gobierno en Línea y a la normatividad vigente.
Página 8 de 88
INTERNACIONALES
3. AUDIENCIA
Este documento está dirigido al personal integrante del organismo regulador que estará encargado
de la administración del estándar y a las entidades que deseen incorporar estándares
internacionales dentro del lenguaje común de intercambio de información.
Adicionalmente aquellas entidades u organizaciones interesadas en participar en la iniciativa de
Gobierno en Línea, encontrarán en este documento lineamientos sobre cómo incluir estándares
internacionales dentro de Leguaje Común.
Para una mejor comprensión se recomiendan las lecturas de los documentos que muestra la Figura
1.
Figura 1.
Lecturas recomendadas
Página 9 de 88
INTERNACIONALES
4. INTRODUCCIÓN
E
ste documento presenta los lineamientos de incorporación de estándares internacionales de
intercambio de información para su uso dentro del estándar.
Asociados a las Tecnologías de la Información y la Comunicación – TIC`s; existen muchos
estándares de intercambio de información enfocados a resolver el mismo tipo de problemas, con
objetivos similares o que pueden ser utilizados en la misma área del conocimiento, pero que tienen
una estructura sintáctica diferente. Por ejemplo para la descripción (metadatos) de artículos de
noticias es posible utilizar lenguajes XML tales como: Dublin Core1, NI2FT, NewsML3 o RSS4.
La tarea de incorporar un estándar internacionalmente aceptado, para el caso Colombiano,
evidencia varios desafíos:

Seleccionar un estándar dentro de un número considerable de posibilidades definidas con el
mismo propósito.

Realizar las modificaciones necesarias al estándar seleccionado de acuerdo con las leyes y
requerimientos locales de Colombia (localización).

Creación de adaptadores, que permitirán la traducción de documentos que implementan el
estándar seleccionado al lenguaje y viceversa.
Por lo anterior, en la tarea de seleccionar un estándar para su incorporación, se hace necesario
definir las políticas y los lineamientos que permitan y faciliten su selección, adopción y adaptación.
Este documento está estructurado a nivel general con una sección que describe la motivación por la
cual los estándares internacional es deben ser utilizados e incluidos dentro del lenguaje y el estudio
de tres estándares internacionales seleccionados, en la siguiente sección se encuentran los
lineamientos para la selección de estándares internacionales, la especificación de un proceso de
inclusión de estándares internacionales y finalmente las conclusiones.
1
2
3
4
Tomado de http://www.dublincore.org el 01 de noviembre de 2013
Tomado de http://www.nitf.org/ el 01 de noviembre de 2013
Tomado de http://www.newsml.org/ el 01 de noviembre de 2013
Tomado de http://www.w3.org/WAI/highlights/about-rss.html el 01 de noviembre de 2013
Página 10 de 88
INTERNACIONALES
5. ANTECEDENTES
5.1
MOTIVACIÓN
E
l advenimiento de nuevas tecnologías y su masificación dentro de una sociedad generan
cambios sustanciales dentro de dicha sociedad. Las TIC sin lugar a dudas, en los finales del
siglo XX e inicios del siglo XXI han influenciado la sociedad hasta el punto de generar cambios
en ella o en parte de ella. Esta nueva sociedad se conoce como Sociedad de la Información.
El sociólogo Yoneji Masuda5, quien introdujo el término sociedad de la información (Information
Society), lo definió de la siguiente manera: “Sociedad que crece y se desarrolla alrededor de la
información y aporta un florecimiento general de la creatividad intelectual humana, en lugar de un
aumento del consumo material”6. Así como llegamos a la sociedad de la información, ésta
evolucionará a la sociedad del conocimiento o la sociedad del saber.
Manuel Castells7 define la sociedad del conocimiento como: "Una sociedad en la que las condiciones
de generación de conocimiento y procesamiento de información han sido sustancialmente alteradas
por una revolución tecnológica centrada en el procesamiento de información, la generación del
conocimiento y las tecnologías de la información".
Por otra parte, Abdul Waheed Khan8 escribe: “La sociedad de la información es la piedra angular de
las sociedades del conocimiento. El concepto de “sociedad de la información”, a mi parecer, está
relacionado con la idea de la “innovación tecnológica”, mientras que el concepto de “sociedades del
conocimiento” incluye una dimensión de transformación social, cultural, económica, política e
institucional, así como una perspectiva más pluralista y desarrolladora. El concepto de “sociedades
del conocimiento” es preferible al de la “sociedad de la información” ya que expresa mejor la
complejidad y el dinamismo de los cambios que se están dando. (...) el conocimiento en cuestión no
sólo es importante para el crecimiento económico sino también para empoderar y desarrollar todos
los sectores de la sociedad” 9.
5
Sociólogo japonés, su actividad profesional y académica tuvo una importancia decisiva en la definición estratégica de un modelo de
sociedad tecnológica para Japón, al tiempo fue uno de los pioneros en la conceptualización de la idea de 'sociedad de la información'.
6
Tomado de http://www.infoamerica.org/teoria/masuda1.htm el 1 de Noviembre de 2013
7 Manuel Castells catedrático de Sociología y de Urbanismo en la Universidad de California, Berkeley, así como Director del IN3 en la
Universitat Oberta de Catalunya. En los últimos veinte años ha llevado a cabo una vasta investigación en la que relaciona la evolución
económica y las transformaciones políticas, sociales y culturales en el marco de una teoría integral de la información.
8 Subdirector general de la UNESCO para la Comunicación y la Información.
9 Tomado de http://portal.unesco.org/ci/en/ev.php-URL_ID=11958&URL_DO=DO_TOPIC&URL_SECTION=201.html el 1 de Noviembre de
2013
Página 11 de 88
INTERNACIONALES
5.2
Hacia la sociedad del conocimiento
El crecimiento de la sociedad alrededor de la información implica tres acciones por parte de ella:
creación, manipulación y distribución de dicha información. No hay dudas de que las tres acciones
están en parte garantizadas. Ejemplos de las acciones antes mencionadas se encuentran por
doquier, la Internet con la explosión logarítmica de sus contenidos –creación-, los servicios que son
prestados digitalmente por la administración pública o las empresas privadas –manipulación- y las
infraestructuras montadas para la distribución de la información.
Figura 2. Interoperabilidad en la sociedad de la información
Sin embargo, uno de los desafíos que afronta la sociedad de la información y por ende la sociedad
del conocimiento, es la dificultad de conseguir una interoperabilidad real, es decir una correcta
distribución de la información combinada con su manipulación y creación. El desafío de la
interoperabilidad que afronta hoy la sociedad de la información, es similar al que presentaron
algunas organizaciones en el pasado, las cuales se denominaron “islas de información”. La metáfora
de las islas de información significa que la información se encuentra esparcida a lo largo de la
organización, en diferentes formatos y posiblemente replicada.
Las islas de información pueden combatirse creando una buena comunicación y compatibilidad entre
los sistemas e infraestructuras informáticas. Para lograr lo anterior, se hace necesario el uso de un
mismo canal, lenguaje y semántica de comunicación. Hoy por hoy, el canal de comunicación de
facto10 en los sistemas informáticos es la Internet, y a su vez dentro de la Internet el lenguaje de
comunicación de facto es el XML; en cuanto a la semántica de la comunicación, que es tener la
misma compresión de la información intercambiada. Existe una variedad de lenguajes XML,
soportados por una gran cantidad de asociaciones y entidades que demandan interoperabilidad en
determinadas áreas del conocimiento que bogan por permitir la interoperabilidad con la misma
semántica.
10
Un estándar o tecnología de facto es aquel patrón o norma que se caracteriza por no haber sido consensuada ni legitimada por un organismo de
estandarización al efecto. Por el contrario, se trata de una norma generalmente aceptada y ampliamente utilizada por iniciativa propia de un gran
número de interesados.
Página 12 de 88
INTERNACIONALES
Asociaciones, como la W3C (World Wide Web Consortium) o el Consorcio de Internet; OASIS
(Organization for the Advancement of Structured Information Standards. su traducción al español
es Asociación para el Avancede los Estándares de Información Estructurada), son ejemplos de la
necesidad de crear y utilizar estándares para el intercambio de información. Lenguajes como WMS
para el intercambio de información geográfica, y UBL11 para el intercambio de información de
negocios, son a su vez, sólo dos ejemplos de la infinidad de lenguajes que hacen posible la
interoperabilidad.
Asimilando experiencias como las del gobierno de Inglaterra, o el gobierno del Hong-Kong en
cuanto a creación de un marco de interoperabilidad, los programas de interoperabilidad de dichos
países adoptaron estándares de intercambio de información previamente creados, lo que permite
no comenzar desde cero y tener una base de lenguajes probada y utilizada para intercambio. En el
caso Colombiano, surge la necesidad de adoptar estándares previamente creados, por los
beneficios que se pueden tener como: una base sólida, el respaldo de organizaciones
internacionales que mantienen dichos estándares, la infraestructura y experiencia existente sobre el
uso de dichos estándares y sobre todo el camino recorrido en la creación de estándares de
intercambio de información.
11
Tomado de http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ubl el 27 de abril de 2008
Página 13 de 88
INTERNACIONALES
5.3
GENERALIDADES
Dentro de los estándares de XML existen muchos que han sido adoptados a nivel internacional de
una forma muy natural. Un ejemplo típico es el lenguaje XHTML, ampliamente utilizado por todos los
navegadores de internet.
En la adopción de un estándar internacional, se pueden presentar entre infinidades, los siguientes
escenarios:





Necesidad de intercambio de información entre entidades, organizaciones no
gubernamentales y organizaciones privadas que utilicen el estándar internacional.
Adopción previa del estándar internacional por par te de una entidad nacional.
Cobertura de las necesidades de intercambio de información de una entidad a través de un
estándar internacional previamente definido.
Adopción generalizada, aun cuando existan más estándares.
El operador del lenguaje propone un estándar inter nacional para su incorporación.
Las estrategias de adopción y adaptación para cada uno de los escenarios varían, de acuerdo a la
situación que puntualmente se afronte.
A continuación se presentan tres estándares de intercambio de información que son el conjunto de
estándares internacionales que se tuvieron en cuenta para la generación del procedimiento de
incorporación de estándares internacionales, de acuerdo al estado de arte de su uso en algunas entidades
del orden nacional y a las posibilidades de su adopción en el mediano plazo.
Página 14 de 88
INTERNACIONALES
6. XBRL
Nombre: XBRL (extensible Business Reporting Language) Lenguaje extensible para reportes de
negocios.
Origen: Es un lenguaje que nace de la propuesta lanzada en 1998 por Charles Hoffman, un
experto contable y auditor, para simplificar la automatización del intercambio de información
financiera mediante el uso del lenguaje XML -entonces emergente y hoy casi ubicuo en todo lo
relacionado con Internet12.
Estado del arte en Colombia: En el Ministerio de Hacienda y Crédito Público se está adelantando
el desarrollo del Proyecto de Interoperabilidad13 enmarcado en el uso del estándar XBRL para
reportar información de carácter financiero. El citado Ministerio utiliza XBRL, y además lidera la
adopción de XBRL en Colombia. Gracias al grupo de trabajo XBRL14 existente en Colombia, ya
existen taxonomías como la que muestra la Figura 3. Existen además proyectos en curso en la
Contaduría General de la Nación: XBRL para el reporte de estados financieros públicos (CHIP), en la
Superintendencia de Sociedades (Sistema de Insolvencia) y en la Superintendencia Financiera.
Estructura: XBRL está compuesto por taxonomías; ellas son los diccionarios del lenguaje XBRL.
Consisten en esquemas de clasificación que definen etiquetas específicas para cada concepto
específico de información (por ejemplo, "Beneficio Neto"), dichas taxonomías son publicadas en la
Web de XBRL International. Cada país tiene su propia normativa contable, por lo que cada una
puede tener su propia taxonomía para informes financieros.
Una taxonomía XBRL está compuesta por:
12
13
·
Un esquema: que define los conceptos que componen la taxonomía. El esquema contiene,
tipos de datos, periodos de tiempo para hacer los reportes de negocios, entre otros. Las
propiedades de los conceptos (elementos de datos) son definidos de acuerdo a la
especificación XBRL.
·
Cinco archivos llamados linkbase que contienen definiciones de relaciones entre los conceptos
definidos en el archivo de esquema. Los archivos son: a) label linkbase: permite a los
Tomado de http://www.xbrl.es/que_es/que_es.html el 28 de abril de 2008.
El Ministerio de Hacienda y Crédito Público viene adelantando tres proyectos por cuenta de dicha entidad con XBRL: El primero está
relacionado con la creación de varias taxonomías XBRL (unas para reporte consolidado y otras para reporte detallado) de reporte
presupuestal; otro está asociado con la creación de documentos instancia como reportes interoperables para el proyecto SIIF Nación; y el
último está relacionado con la publicación de informes presupuestales en el portal de Transparencia Financiera del estado Colombiano.
Tomado de http://www.transparenciafinanciera.gov.co el 19 de junio de 2008.
14
Internacionalmente conocido como Working Group. Corresponde a grupos de personas responsables de coordinar las actividades de una
jurisdicción XBRL (representación de países mediante una asociación que apoyan el desarrollo de XBRL) Se organizan según intereses o temas como
por
ejemplo:
mercadeo
y
educación,
creación
de
taxonomías,
estrategia,
etc.
Tomado
de
http://www.minhacienda.gov.co/portal/page/portal/MinHacienda/politicasapoyo/sectortecnologico/xbrl/iniciativacolombiana/
OrientacionesGruposDeTrabajo.pdf el 20 de Junio de 2008.
Página 15 de 88
INTERNACIONALES
usuarios adjuntar etiquetas con diferentes roles y lenguajes a un concepto dado, b) reference
linkbase permite al usuario adjuntar fuentes de información externa a los conceptos, c)
presentation linkbase define como anidar y ordenar los conceptos que van a ser incluidos en
un reporte, d) calculation linkbase define como los conceptos deben ser totalizados uno
dentro del otro, e). definition linkbase permite a los usuarios definir semántica adicional a los
conceptos y asociarla a los mismos.
Figura 3. Taxonomía de gastos de inversión XBRL en Colombia15
En Colombia la taxonomía creada está fundamentada en el Estatuto Orgánico del Presupuesto
General de la Nación de Colombia, en lo referente a los catálogos presupuestales para gastos e
ingresos según las leyes y decretos que rigen el presupuesto y la Ley de Presupuesto General de la
Nación de 2007. Dicha taxonomía contiene 4 esquemas principales que reúnen los elementos
definidos en los catálogos mencionados, junto con la definición de los linkbases: Calculation,
Presentation, Label y Reference, así16:

Taxonomía Gastos de Funcionamiento.

Taxonomía Gastos Servicio a la Deuda.

Taxonomía Gastos de Inversión:
15
Tomado de http://www.minhacienda.gov.co/images/sitiowww/xbrl/gf/gf_visor.html el 20 de Junio de 2008
Tomado de http://www.minhacienda.gov.co/portal/page?_pageid=1036,713460&_dad=portal30&_schema=PORTAL30 el
de abril de 2008
16
Página 16 de 88
INTERNACIONALES

o
Programas.
o
Subprograma.
Taxonomía de Ingresos.
Figura 4 ilustra la taxonomía de XBRL en Colombia.
Figura 4. Taxonomía de los esquemas XBRL en Colombia
17
Principales diferencias y similitudes con la arquitectura del lenguaje común de
intercambio de información: la primera es que el lenguaje común de intercambio de
información está organizado por capas y XBRL explícitamente está organizado por taxonomías
claramente definidas. XBRL además de permitir definir conceptos, permite enlazar dichos conceptos
con los linkbases, lo cual no está definido en el lenguaje común de intercambio de información.
Necesidades para hacer converger el estándar al lenguaje común de intercambio de
información: Para incluir los conceptos de la taxonomía XBRL Colombiana dentro del lenguaje
común de intercambio de información se DEBEN tener en cuenta:
Para los linkbases, se PODRÍAN definir elementos de dato dentro de lenguaje común de
intercambio de información que permitieran ligar instancias de otros elementos de datos.
Inicialmente los elementos de dato de XBRL, que sirven para definir los esquemas XBRL, deberían
someterse al proceso de inclusión de estándares internacionales del lenguaje común de intercambio
17
Tomado de http://www.minhacienda.gov.co/MinHacienda/politicasapoyo/sectortecnologico/xbrl/Taxonomias el 20 de junio de 2008.
Página 17 de 88
INTERNACIONALES
de información que se describe en la sección 5 de este documento.
Recomendación de Adopción: XBRL, por ser lenguaje estándar para reportes de información de
negocios, utiliza formulas dentro de sus elementos y otros lenguajes como XPATH y XLINK que
sirven para hacer referencias dinámicas y totalizaciones dentro de los documentos XBRL, dichos
lenguajes no serían soportados por el estándar, debido a que el lenguaje común de intercambio de
información fue concebido para representar conceptos por medio de estructuras de datos
(elementos) y no para representar referencias dinámicas y totalizaciones, por lo que esos
componentes de XBRL no serían adoptados ni adaptados. La adopción y adaptación (en parte ya
realizada con las taxonomías) de XBRL en el lenguaje común de intercambio de información se
realizará mediante la adopción directa de las taxonomías adoptadas para Colombia. Los elementos
base de XBRL (que soporten las taxonomías) deben ser documentados y adoptados directamente
por el lenguaje. El proceso de adopción está especificado en la sección 5 de este documento.
Página 18 de 88
INTERNACIONALES
7. HL7 (Health Level Seven) - CDA
En esta sección se dará una explicación general sobre HL7, sin embargo, el enfoque principal que
se dará hacía la conceptualización de HL7-CDA
Nombre: Health Level Seven (traducción literal: Salud Nivel Siete). "Nivel Siete" se refiere al más
alto nivel de la Organización Internacional de Normalización (ISO) para las comunicaciones del
modelo Open Systems Interconnection (OSI) (comúnmente llamado modelo OSI de la ISO) que es el
nivel de aplicación. El nivel de aplicación se ocupa de la definición de los datos que deben
intercambiar, el tiempo del intercambio, y la comunicación de ciertos errores de la aplicación. El
séptimo nivel del modelo OSI apoya funciones como controles de seguridad, identificación de los
participantes, chequeos de disponibilidad, mecanismo de intercambio de las negociaciones y, lo que
es más importante, estructurar el intercambio de datos.
Orígenes: Es una de las normas aprobadas por el Instituto Nacional Estadounidense de Estándares
(ANSI). El objeto de HL7 es la representación de datos clínicos y administrativos en el sector de la
salud. La misión de la organización que se encarga del estándar HL7 (que tiene su mismo nombre)
es proveer estándares para los dominios: clínico, asistencial, administrativo y logístico, con el fin de
lograr una interoperabilidad real entre los distintos sistemas de información en el área de la salud.
Estado del arte en Colombia: En Colombia existe la organización llamada Fundación HL7
Colombia18 que promociona el uso de éste estándar en el país. HL7 ayudaría con la creación de una
historia clínica digital, que permitiría la unificación de las historias clínicas y su consolidación y/o
intercambio entre las entidades de Salud.
Estructura: HL7 además de contar con un modelo de datos (para mensajes y datos per se), tiene
un modelo de interacción, uno de especificación (mediante casos de uso expresados con UML) y un
modelo técnico de implementación (ver Figura 5). HL7 puede ser expresado en varios formatos, uno
de ellos es XML. Existe también la posibilidad de expresarse en ER7, OLE, CORBA y EDIFACT.
A continuación se definen algunos conceptos relacionados con HL7. En cada uno se describe si es
parte constitutiva de HL7 o es un concepto externo. Los conceptos pertenecientes al modelo HL7
están incluidos dentro de la Figura 5.
18
Pablo Manzotti, “Un proyecto en el marco de la integración regional”, Diagnóstico VOLUMEN XVII - NUMERO 180 - ENERO 2008,
Disponible en:
http://www.diagnosticojournal.com/spa/diagnostico/dia180/d-hl180.php
Página 19 de 88
INTERNACIONALES
Figura 5. Modelo general de HL7 versión 3
19

RIM: La sigla RIM viene del término de la lengua inglesa Reference Information Model (su
traducción literal es Modelo de Referencia de Información). Como lo muestra la Figura 5, RIM
es la base del proceso de desarrollo de HL7 versión 3. Es un modelo de objetos creados como
parte de la metodología de desarrollo de HL7 versión 3. Cuenta con una representación
gráfica de datos clínicos, que identifica el ciclo de vida de eventos que un mensaje o grupo de
mensajes relacionados pueden transportar. RIM es un modelo compartido entre todos los
dominios de la salud. Permite expresar las conexiones existentes entre la información
trasportada en los campos de los mensajes HL7. RIM permite el incremento de la precisión de
los datos y reduce los costos de implementación.

CDA19: Es el acrónimo del término de la lengua inglesa Clinical Document Architecture
(Arquitectura de documento clínico). El CDA del HL7 es una estructura de meta-información
estandarizada que específica la estructura y la semántica de los documentos médicos para su
mejor intercambio entre sistemas informáticos, clínicas y hospitales diferentes. Anteriormente
se la conocía como la Patient Record Architecture (PRA). Los documentos instancias del CDA
son expresados en XML y deben cumplir con el esquema-XML-CDA. Los documentos CDA
deben cumplir con los lineamientos del RIM.

HMD: La sigla HMD proviene del término Hierarchical Message Definition que es la definición
de un mensaje abstracto en HL7 V3.

R-MIM: La sigla R-MIM viene del término de la lengua inglesa Refined Message Information
Model (su traducción literal es modelo refinado de información de mensajes). R-MIM es una
estructura de información que representa los requerimientos de un conjunto de mensajes.
Contiene las clases, atributos, asociaciones y tipos de datos que son necesarios para soportar
Tomado de Dolin R.H. et. al, HL7 Clinical Document Architecture, Release 2.0, 2004 Health Level Seven Inc. Ann Arbor, Michigan.
Página 20 de 88
INTERNACIONALES
uno o más HMD.

HMD: La sigla HMD proviene del término Hierarchical Message Definition que es la definición
de un mensaje abstracto en HL7 V3.

R-MIM: La sigla R-MIM viene del término de la lengua inglesa Refined Message Information
Model (su traducción literal es modelo refinado de información de mensajes). R-MIM es una
estructura de información que representa los requerimientos de un conjunto de mensajes.
Contiene las clases, atributos, asociaciones y tipos de datos que son necesarios para soportar
uno o más HMD.

D-MIM: Acrónimo del término Domain Message Information Model, que se refiere a un
subconjunto del modelo de información de HL7 referido a un dominio específico del área de la
salud.

DICOM & MEDICOM: Estas dos siglas provienen de los términos de la lengua inglesa Digital
Imaging and Communications in Medicine y Medical Image and Related Data Interchange
Format Standard, respectivamente. Los dos estándares permiten el intercambio de imágenes
médicas. Los anteriores estándares fueron desarrollados a la par con HL7 y hoy tienen
comités técnicos dentro de HL7.
intercambio de información: La estructura del estándar HL7 se asemeja más un árbol, la
estructura del lenguaje común de intercambio de información es por capas, que no cumple
estrictamente con la estructura de árbol. HL7 está compuesto por un número considerable de
catálogos de códigos, el lenguaje común de intercambio de información es más bien un conjunto de
conceptos. Aparte de la arquitectura HL7 presenta un modelo de interacción y un modelo de casos
de uso que no tiene el lenguaje común de intercambio de información.
Necesidades para hacer converger el estándar: En cuanto a los CDA no difieren mucho del
lenguaje, por lo que el proceso de inclusión de HL7, en lo referente a esquemas XML, dentro del
estándar sería un proceso sencillo debido a que los esquemas definidos en HL7 son similares a los
esquemas del estándar. Su similitud radica en que ambos estándares representan conceptos
mediante estructuras de información (elementos de dato) y dichas estructuras son su principal
componente. Los catálogos de códigos que tiene HL7 serán de fácil inclusión dentro del estándar
debido a que los valores de los códigos no cambian y utilizan enumeraciones de XML como las utiliza
el lenguaje común de intercambio de información.
Recomendación de adopción: Para el caso de HL7 se aplicaría el proceso de adopción referido en
la sección 5 de éste documento a los elementos constitutivos del CDA y que son expresados con
XML. Otras partes de HL7, como el RIM no se podría adoptar dentro del estándar debido a que
lenguaje común de intercambio de información fue concebido para representar conceptos por medio
de estructuras de datos (elementos) y no para representar modelos de interacción o modelos de
casos de uso como lo hace HL7.
Página 21 de 88
INTERNACIONALES
Actualmente ya se han adaptado algunos de los elementos de HL7 dentro del estándar. Conceptos
como el de grupo sanguíneo, y factor Rh de la sangre. La semántica contenida en HL7 es una de sus
fortalezas por lo que se podrían adaptar y adoptar muchos de los códigos y listas que son
mundialmente aceptadas en el sector de la salud. Se tiene una propuesta de iniciar la incorporación
del estándar HL7-CDA por parte del Ministerio de Salud y Protección Social el cual es el más
adecuado y compatible con el Lenguaje Común de Intercambio de Información.
ORGANIZACIÓN DE LOS ELEMENTOS INCORPORADOS
Los elementos incorporados (adoptados y adaptados) pertenecerán a la capa “Uso Internacional”. Se
propone que la organización dentro de esta capa se realice por cada estándar incluido (homologar
con proyectos) y dentro de ellos se creen módulos. Los nombres de los módulos serán consistentes
con la organización original del estándar, por ejemplo, presentando la forma de organizar los
elementos usando el formato de sistema de archivos que para el caso de HL7 sería:
·
UsoInternacional\HL7\CDA
Página 22 de 88
INTERNACIONALES
8. LEGAL-XML
Nombre: LegalXML
Orígenes: LegalXML es un estándar para el intercambio electrónico de información jurídica creado
en 1998. Sus creadores fueron un grupo formado por abogados, administradores de cortes y/o
juzgados, asesores de tecnología y académicos. Desde el año 2002, es uno de los estándares que
mantiene la organización OASIS.
Estructura: Legal XML a su vez se divide en siete (7) subcomités a saber:

LegalXML Court Filing TC20: Contiene vocabularios relacionados con documentos y

Legal XML eContracts: Subcomité encargado de desarrollar estándares XML de

Legal XML eNotary: Encargado de desarrollar un conjunto de requerimientos técnicos

Legal XML IntJustice: Encargado de crear estándares de interoperabilidad para sistemas

Legal XML Lawful Intercept: Encargado de creación de estándares de identificación en
formatos de intercambio para las aplicaciones informáticas propias de los tribunales de
justicia, como el LegalXML Court Filing 1.1 Proposed Standard, propuesto en julio de 2002
(aunque se está trabajando en la versión 2.0), o el XML Court Document 1.1 Draft Standard,
de mayo de 2002. Sin embargo, el Comité Técnico de Legal XML dedicado a los documentos
legislativos, LegalXML Legislative Documents, Citations, and Messaging TC21 no ofrece
ningún estándar en la actualidad. El des arrollo de este estándar permitirá la creación y
transmisión de documentos legales de un abogado, parte de un proceso judicial o un
litigante auto representado, hacia una corte o viceversa o entre cualquier otro usuario de
documentos legales.
documentos que representan contratos para habilitar la creación eficiente, administración y
publicación de contratos y de términos de contratos.
para administrar información legal electrónica que debe tratarse como original.
legado y nuevos sistemas que soporten Legal XML.
XML incluyendo la reutilización de otros estándares previamente creados que permitan la
autenticación.

21
21
Legal XML Legislative: Subcomité encargado de crear estándares para documentos
legislativos y estándares para citar documentos no legislativos.
http://e-archivo.uc3m.es:8080/dspace/bitstream/10016/867/1/2004RGID.pdf
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=legalxml-legislative
Página 23 de 88
INTERNACIONALES

Legal XML ODR: Encargado de promover el uso de XML para permitir el acceso público a la
justicia por medio de sistemas de resolución de disputas.
Estado del arte en Colombia: No se encontró información sobre el uso de Legal-XML en
Colombia, por lo que se supone que su uso es prácticamente nulo.
intercambio de información: La organización de Legal-XML por áreas dentro de la justicia es muy
similar a las capas que tiene el estándar. Sin embargo por tratarse de un estándar de intercambio de
información jurídica incluye elementos para cifrado de información, identificación y seguridad que la
arquitectura del estándar no contempla.
Necesidades para hacer converger el estándar: LegalXML intercambia documentos legales por
medio de canales electrónicos, por lo que sus necesidades técnicas de convergencia con el lenguaje
común de intercambio de información no son un gran escollo, por la similitud de los dos estándares.
Para la incorporación del estándar y en cuanto a las modificaciones que debe someterse al modelo
legal Colombiano se necesitará un grupo interdisciplinario que conozcan los temas técnicos y legales
y estén familiarizados con los cambios que continuamente sufre la legislación Colombiana.
Recomendación de Adopción: Existe un proceso de evolución de la rama judicial en Colombia,
mediante la modernización del Consejo Superior de la Judicatura (CSJ) y con los actores del medio.
El uso de Legal XML deberá consultarse al CSJ, por lo que no se recomienda su adopción por ahora,
sino hasta que dentro del proceso de adopción existan interlocutores válidos. Debido a que la judicial
es una de las ramas del poder en Colombia, se recomienda involucrar a los actores relacionados
como el CSJ, el Colegio de Abogados de Colombia, las altas Cortes Colombianas y Ministerio de
Interior Justicia Colombiano.
Página 24 de 88
INTERNACIONALES
9. ESTÁNDARES DEL OPEN GEOSPATIAL CONSORTIUM (OGC)
PARA INFORMACIÓN GEOGRÁFICA Y YNTC 4611 PARA
DESCRIPCIÓN DE METADATOS GEOGRÁFICOS
Las siguientes secciones describen un conjunto de estándares cuya adopción ha sido propuesta por el
Instituto Geográfico Agustín Codazzi (IGAC), como entidad que preside el Comité Coordinador de la
Infraestructura Colombiana de Datos Espaciales (ICDE), para la puesta en común de información
geográfica (IG) a través del entorno digital, buscando garantizar su uso masivo. Se muestra el estado
del arte de la adopción general de los estándares en Colombia y un análisis de los lenguaj es con el
formato de los anteriores en este capítulo.
Estado del arte de los estándares de la OGC en Colombia
Actualmente, la ICDE promueve la utilización a nivel nacional de los estándares tecnológicos de la
OGC: Web Map Service (WMS) y Web Feature Service (WFS); así como la Norma Técnica
Colombiana 4611 para metadatos geográficos, buscando con ello garantizar la interoperabilidad de la
información geográfica producida por las entidades del Estado y demás entidades productoras del
país, promoviendo su uso y el acceso de la misma.
En el marco de trabajo de adopción de los estándares propuestos, es necesario observar los
antecedentes de la ICDE, otorgando un marco de referencia que expone el papel preponderante de
ésta en la estandarización de procesos asociados a la gestión de información geográfica en las
entidades del Estado.
De acuerdo a lo anterior el documento CONPES 3585 de 200922, expone un contexto de la formación
de la infraestructura: “la ICDE comienza con la firma del Acuerdo No. 1 de 2000, en el cual un
conjunto de entidades asociadas, principalmente públicas23 , definieron los lineamientos generales y
la estructura marco de cooperación, coordinación y operación para el manejo e intercambio de la
información geográfica producida o de propiedad de cada una de las entidades vinculadas.
En 2003, la creación de COINFO24 fortalece los objetivos definidos en la ICDE, la cual se integra a
22
“Consolidación de la Política Nacional de Información Geográfica y la Infraestructura Colombiana de Datos Espaciales”
23
Departamento Administrativo Nacional de Estadística -DANE, Instituto Geográfico Agustín Codazzi -IGAC, Instituto de Hidrología,
Meteorología y Estudios Ambientales – IDEAM, ECOPETROL, Departamento Nacional de Planeación –DNP y la Federación Nacional de
Cafeteros.
24
Comisión Intersectorial de Políticas y de Gestiónde la Información para la Administración Pública (Decreto 3816 de 31 de
de 2003).
Página 25 de 88
diciembre
INTERNACIONALES
la Comisión como una política estatal enfocada a la definición de estrategias y programas relativos
a la producción, manejo, protección, intercambio, acceso y uso de la información geográfica de la
administración pública, así como a la fijación de lineamientos de racionalización de la inversión
pública en tecnologías de información y de comunicaciones sobre información geográfica.
Posteriormente, mediante el Decreto número 3851 de 2006 se conforma un sistema administrativo
de información oficial básica, denominado Infraestructura Colombiana de Datos ICD, en el cual, uno
de sus principales componentes lo constituye la ICDE presidida por el IGAC y que tiene como
funciones el diseño de estrategias para la consolidación, articulación y promoción del asegura
miento de la calidad de la información geográfica25, con el fin de incorporarla como una herramienta
de gestión de la administración pública”.
Posteriormente, en el 2006, a través del Decreto 2442, se creó la Comisión Colombiana de Espacio,
la cual a través del Acuerdo 6 le otorga un papel protagónico a la ICDE en los procesos de
mejoramiento de la organización institucional y del mayor y mejor uso de la IG como soporte a
proyectos en materia de telecomunicaciones, navegación satelital, observación de la tierra y demás
aplicaciones de la ciencia y la tecnología Geoespacial a escala nacional y regional.
Resultado de las acciones articuladas de las entidades participes, lideradas por el IGAC, en el 2009
se aprobó el Documento CONPES 3585, “Consolidación de la Política Nacional de Información
Geográfica y la Infraestructura Colombiana de Datos Espaciales”. Este documento de política
nacional expone la estructura de organización de la ICDE, conformada por un Comité Coordinador,
liderado por el IGAC y un conjunto de comités sectoriales, clasificados de acuerdo a temáticas
específicas. Adicionalmente define un conjunto de lineamientos que las entidades deben atender en
temas de IG para fortalecer y difundir la gestión de la misma, mejorando con ello, la producción,
actualización, custodia y protección económica, jurídica, técnica y tecnológica de los productos con
IG de las entidades.
De este conjunto de lineamientos se particularizan dos, el lineamiento D y el F, siendo estos:
Lineamiento D, Estandarizar y documentar la IG: “Todas las entidades del Estado y aquéllas de
carácter mixto o privado que ejerzan funciones públicas deberán seguir, en la producción o
adquisición de IG, los lineamientos y normas técnicas definidas en el marco del Comité Técnico de
Normalización de la Información Geográfica 028 de ICONTEC, en el cual participan instituciones que
integran la ICDE”.
Lineamientos F, Establecer mecanismos de acceso a la información geográfica. “Las entidades del
Estado y aquéllas de carácter mixto o privado que ejerzan funciones públicas deberán permitir, a
través de sus redes de servicios, el acceso a otras entidades y usuarios en general, de acuerdo a su
importancia estratégica para el desarrollo del País. Los servicios disponibles incluyen: a) servicios de
localización; b) servicios de visualización; c) servicios de descarga; d) servicios de transformación; y
25
En particular el Decreto 3851 de 2006 define como competencias de la ICDE lo “relativo a catastro, inventarios de infraestructura física,
recursos minerales, hídricos, vegetales y biodiversidad, geología, geomorfología, suelos, amenazas naturales, climatología, cobertura y uso
del suelo, oceanografía, batimetría, registro de propiedad inmobiliaria, listado de direcciones de edificaciones urbanas y rurales, conexiones
de servicios públicos domiciliares, y demás de la misma índole”.
Página 26 de 88
INTERNACIONALES
e) servicios de acceso a servicios de datos espaciales. Lo anterior incluye los servicios de catálogos
de búsqueda en Internet, cumpliendo con los estándares internacionales establecidos en el Comité
ISO TC211 y en el Open Geospatial Consortium, para lo cual las entidades deberán documentar los
datos, productos y servicios geográficos de conformidad con el estándar nacional de Metadatos
Geográficos, el cual debe responder a estándares ISO. El acceso podrá ser restringido de acuerdo
con la normatividad vigente.”
Complementariamente, el documento CONPES 3585 determina como objetivo central de la ICDE:
”Articular la producción, disponibilidad, acceso y u so de la IG a nivel de las entidades del estado”
La ICDE cuenta en la actualidad con 45 entidades26, las cuales desarrollan actividades relacionadas
con diversas temáticas (ambiental, de defensa, de educación, de planeación y ordenamiento
territorial, de minería, de energía, de infraestructura, entre otras) y que para el desarrollo de sus
procesos misionales utilizan la IG como insumo para la toma de decisiones.
Las instituciones vinculadas a la ICDE son:



























26
Aeronáutica Civil
Agencia Nacional de Hidrocarburos - ANH
Comando General de las Fuerzas Militares de Colombia
Comisión de Regulación de Agua Potable y Saneamiento Básico - CRA
Corporación Autónoma Regional de Cundinamarca - CAR
Corporación Autónoma Regional del Centro de Antioquia - CORANTIOQUIA
Corporación Colombiana de Investigación Agropecuaria - CORPOICA
Departamento Administrativo Nacional de Estadística - DANE
Departamento Nacional de Planeación - DNP
Dirección General Marítima - DIMAR
Ejército Nacional de Colombia
Empresa Colombiana de Petróleos - ECOPETROL
Federación Nacional de Cafeteros de Colombia
Fuerza Aérea Colombiana - FAC
Gobernación de Boyacá
Gobierno en Línea
Instituto Amazónico de Investigaciones Científicas - SINCHI
Instituto Colombiano de Geología y Minería - INGEOMINAS
Instituto de Hidrología, Meteorología y Estudios Ambientales - IDEAM
Instituto de Investigación de Recursos Biológicos Alexander Von Humboldt - IAvH
Instituto de Investigaciones Ambientales del Pacífico -IIAP
Instituto de Investigaciones Marinas y Costeras – INVEMAR
Instituto de Planificación y Promoción de Soluciones Energéticas - IPSE
Instituto Nacional de Vías - INVIAS
Ministerio de Ambiente, Vivienda y Desarrollo Territorial - MAVDT
Ministerio de Comercio, Industria y Turismo
Ministerio de Defensa
Total de entidades inscritas al momento de la elaboración del presente documento.
Página 27 de 88
INTERNACIONALES


















Ministerio de Educación Nacional
Ministerio de Minas y Energía
Ministerio de Transporte
Parques Nacionales Naturales de Colombia
Secretaría Distrital de Planeación
Red ALMA MATER
Sociedad Colombiana de Ingenieros
Unidad Administrativa Especial de Catastro Distrital - UAECD
Unidad de Planeación Minero Energética - UPME
Universidad Distrital Francisco José de Caldas
Universidad EAFIT
Ministerio de Relaciones Exteriores
Corporación Autónoma Regional de Boyacá - CORPOBOYACA
Corporación Autónoma Regional de Chivor - CORPOCHIVOR
Instituto Colombiano de Bienestar Familiar
Universidad de Manizales
Universidad Católica de Manizales
Ministerio de Agricultura
Es posible ver que la ICDE cuenta con una amplia participación de entidades del Estado colombiano,
las cuales han comprendió la importancia de la IG para la toma de decisiones y el desarrollo de sus
procesos internos, optando por implementar los lineamientos técnicos y tecnológicos que desde la
Infraestructura se han promulgado, garantizando con ello la interoperabilidad y un flujo constante de
la información en el entorno digital. Un ejemplo de ello es la adopción de los estándares tecnológicos
de la OGC, así como la implementación de normas técnicas de calidad, como la NTC 4611, para
garantizar la existencia de metadatos que brindan información de los productos con información
geográfica que producen las entidades adscritas.
9.1
WMS
Nombre: Web Map Service – WMS
Orígenes: El Open Geospatial Consortium (OGC) se involucró en el desarrollo de estándares para la
descripción de mapas por la Web después de la publicación de un artículo de Allan Doyle en 1997, en
el cual se daba la descripción general de un "Marco de trabajo para la descripción de mapas por la
WWW". El OGC estableció un equipo para la definición de una estrategia, y organizó la iniciativa
"Web Mapping Testbed", la cual involucró proyectos piloto que profundizaban en las ideas de Doyle y
el equipo del OGC. Los resultados de estos proyectos piloto se expusieron en septiembre de 1999, y
una segunda fase de estos terminó en abril de 2000.
La versión 1.0.0 de WMS se publicó en abril de 2000; la versión 1.1.0, en junio de 2001; la versión
1.1.1 en enero de 2002; y finalmente la versión 1.3.0 del estándar en enero de 2004. Esta versión se
encuentra estable.
Página 28 de 88
INTERNACIONALES
Estructura: WMS pretende servir como estándar específico para el intercambio de información de
mapas a través de sesiones HTTP. De esta manera, en el estándar se definen dos roles
fundamentales:

El cliente, encargado del envío de las peticiones, las cuales son tramas corrientes HTTP
GET o HTTP POST.

El servidor, encargado de su despacho en la forma de uno o varios documentos XML.
Cualquier servidor que implemente el estándar está obligado a suministrar los siguientes dos
servicios:

GetCapabilities. Describe sus capacidades, qué capas geográficas puede servir y qué
operaciones soporta en cada tipo de elemento. La trama de respuesta de esta operación
está definida por un esquema XSD.

GetMap. Retorna un mapa en un formato determinado. Al recibir la petición GetMap, el
servicio WMS podrá responder a la petición también con un problema o una excepción
como respuestas.
Una tercera operación, GetFeatureInfo, está incluida en el estándar como opcional. Está designada
para proporcionar a los clientes del servicio WMS más información sobre los objetos presentes en los
mapas que fueron retornados por peticiones GetMap previas. Solo es soportada por capas en las
cuales los atributos esta petición se encuentre habilitada, definida o heredada. Un servicio WMS
responderá con una excepción en formato XML si recibe una petición GetFeatureInfo pero no la
soporta.
Ver anexo de elementos de dato del estándar WMS en el capítulo 8.
intercambio de información: Dentro de las diferencias más evidentes se pueden contar:

Uso de XLink para referencias a elementos de dato y definición de atributos, estándar que
no se encuentra definido en el lenguaje común de intercambio de información.

Utilización extensiva de la palabra reservada ref de XSD, contrario a los lineamientos del
lenguaje común de intercambio de información.

Redefinición de conceptos elementales como nombres de personas, direcciones y otros ya
incluidos en las capas inferiores del lenguaje común de intercambio de información.
Sin embargo, las tramas XML que son validadas por el XSD del estándar WMS tienen una estructura
Página 29 de 88
INTERNACIONALES
corriente, sin hacer uso de espacios de nombres. En cualquier caso, es posible utilizar directamente
la mayoría de los elementos definidos en WMS en una trama de intercambio cualquiera, modificando
el esquema con el cual se validará efectivamente el intercambio para incluir el espacio de nombres
apropiado.
Adicionalmente a esto, se encontró que los metadatos utilizados en las tramas WMS no son
relevantes para el intercambio efectivo de información, por lo que no es necesario tenerlos en cuenta
para su eventual inclusión en el lenguaje común de intercambio de información.
Necesidades para hacer converger el estándar: La tarea de incluir los elementos de dato del
estándar WMS dentro del lenguaje común de intercambio de información se presupone sencilla dada
la baja complejidad de los elementos de dato definidos en el primero. Teniendo en cuenta la gran
estabilidad y nivel de adopción internacional del estándar WMS, se da por descontado que los
cambios que este sufra en el mediano plazo no impactarán grandemente la utilización que de él
hagan las entidades adoptantes en Colombia. Sin embargo, de ocurrir estos cambios será necesario
actualizar los elementos de forma manual.
Recomendación de adopción: Se recomienda seguir uno de dos cursos de acción para adoptar el
estándar WMS:
1. Adaptar los elementos constitutivos del estándar WMS al lenguaje común de intercambio de
información, de acuerdo con el procedimiento descrito en la sección 5 del presente
documento, y realizar pruebas piloto de su utilización por parte de las entidades involucradas,
en un esfuerzo coordinado entre Gobierno en Línea y la ICDE.
Adoptar esta estrategia implica poder definir con toda precisión catálogos que utilizan de
manera estricta el estándar internacional adaptado, equiparando el proceso de validación de
los documentos del lenguaje común de intercambio de información con el de los documentos
del estándar adaptado.
Esta gran ventaja se obtendría al costo de aumentar la carga de mantenimiento del lenguaje
común de intercambio de información y posibles errores de conceptualización como
consecuencia del uso descontextualizado de los elementos del estándar y de los conflictos
semánticos que se aceptarían para mantener la consistencia de ambos lenguajes.
2. Con el fin de permitir la evolución independiente del estándar WMS y el lenguaje común de
intercambio de información se propone la definición de un elemento de dato en el cual
puedan incluirse tramas completas de petición y respuesta WMS, delegando su validación a
los sistemas misionales.
Esta opción supone la mejor combinación de tiempo y complejidad de implementación,
mantiene la consistencia del lenguaje común de intercambio de información al evitar
conflictos semánticos entre elementos y otorga a los potenciales usuarios la flexibilidad
suficiente para definir intercambios de información basados en ambos lenguajes.
Página 30 de 88
INTERNACIONALES
Estas ventajas se obtendrían al costo de perder visibilidad hacia el estándar adoptado y, de
esta manera, coartar su reutilización en otros usos posibles dentro del lenguaje común de
Los elementos de estudio pertenecerán a la capa “Uso Internacional”. Se propone la siguiente
estructura para la incorporación de dicho estándar dentro de la arquitectura de Lenguaje Común de
Intercambio de Información:
·
UsoInternacional\GML\WMS
9.2
WFS
Nombre: Web Feature Service – WFS
Orígenes: El estándar WFS se desarrolló de manera paralela con WMS, para ofrecer una interfaz de
comunicación que permita interactuar con los mapas servidos por el estándar WMS, como por
ejemplo, editar la imagen que ofrece el servicio WMS o analizar la imagen siguiendo criterios
geográficos.
El estándar WFS ha sido renombrado como ISO 19142 y se encuentra en su versión 2.0 desde
noviembre de 2010.
Estructura: Al igual que WMS, en WFS se distinguen un cliente y un servidor, encargado de
producir las respuestas a las peticiones.
En su forma más simple, el WFS consta de tres operaciones básicas:

GetCapabilities: Describe sus capacidades, qué tipos de elementos o características
geográficas puede servir y qué operaciones soporta en cada tipo de elemento.

DescribeFeatureType: Describe la estructura del tipo de elemento o característica geográfica
pedida, típicamente en la forma de un documento XSD. Dependiendo de las características del
servidor WFS que ofrezca el servicio y de la información que maneje, los XSD devueltos por
los diferentes servidores pueden variar considerablemente.

GetFeature: Devuelve la característica geográfica en formato GML. El documento devuelto
puede ser validado utilizando el esquema XSD enviado por el servidor al invocar la operación
DescribeFeatureType. Aunque las partes constitutivas de cualquier mensaje de respuesta
están definidas en e l lenguaje GML, la manera en la que se utilizan puede ser muy diferente
entre características geográficas distintas.
Página 31 de 88
INTERNACIONALES
Es posible definir una versión transaccional (WFS-T) en la cual, además de permitirse operaciones de
consulta, se ofrecen servicios de modificación de características geográficas sobre los mapas
consultados.
Estas operaciones son ofrecidas típicamente por un servidor Web utilizando protocolos estándares
de servicios Web como SOAP. Por lo tanto, el estándar provee descripciones de las interfaces
utilizando WSDL.
Las peticiones a estos servicios pueden enviarse como una trama XML y como un conjunto de
parejas llave-valor enviado dentro de la cadena de consulta HTTP.
Ver anexo de elementos de dato del estándar WFS en el capítulo 8.
intercambio de información: Los esquemas de datos utilizados por WFS comparten una serie de
características con los pertenecientes al estándar WMS, a saber:

Uso de XLink para expresar relaciones entre elementos.

Uso de XPath para expresar referencias internas y externas con otros documentos y
recursos.

Requisito rígido de nombramiento para facilitar la validación de los documentos transmitidos.

En el caso de los elementos GML, el estándar utilizado define la gran mayoría de los
elementos básicos de un lenguaje. Esta definición entra en conflicto con la ya existente en el
lenguaje común de intercambio de in formación, al definir un mismo concepto con nombre,
propiedades y metadatos diferentes.
Adicionalmente a estas propiedades, WFS presenta una gran heterogeneidad en la definición de
características y su estructura como documentos XML.
Si bien la definición de los elementos GML utilizados para describir características geográficas no
cubre todos los aspectos del lenguaje común de intercambio de información, sí rivalizan con él en
gran medida. Ese hecho se suma a la enorme cantidad de elementos utilizados y a la potencial
complejidad de su administración, si fueran a incorporarse dentro del lenguaje común de intercambio
de información.
Necesidades para hacer converger el estándar: Es posible incorporar los elementos básicos de
exposición y respuesta de servicios WFS dentro del lenguaje común de intercambio de información,
utilizando una estrategia similar a la propuesta para WMS. Sin embargo, la inestabilidad que supone
la incorporación de GML y de todos los lenguajes posibles de descripción de características
geográficas hace que no sea recomendable la incorporación masiva al lenguaje común de
Página 32 de 88
INTERNACIONALES
intercambio de información de todos los elementos definidos en dichos estándar es.
Recomendación de adopción: Se recomienda seguir una estrategia diferenciada para los
lenguajes que forman parte del estándar WFS, de la siguiente forma:

Realizar una adaptación simple al lenguaje común de intercambio de información de los
elementos de dato que permiten definir la interfaz básica de servicios de WFS. De la misma
forma que con la adaptación de WMS, en este proceso no es necesario tener en cuenta la
información acompañante de los elementos, dada la simplicidad de los elementos en
cuestión.

No incorporar al lenguaje común de intercambio de información los elementos
correspondientes a lenguajes de descripción de características geográficas ni los elementos
del lenguaje GML, al suponer su incorporación a este una carga administrativa significativa,
dada su cantidad y complejidad y la inviabilidad de reemplazar los conceptos básicos del
lenguaje común de intercambio de información con los existentes en GML.

En lugar de esto, se propone crear y utilizar elementos genéricos en los cuales se encapsulen
las tramas correspondientes a tipos de características geográficas y respuestas GML a
peticiones especializadas, dejando el procesamiento de estos documentos a las aplicaciones
misionales. De esta forma, los intercambios de información que utilicen el estándar WFS
podrán describirse en términos de estos elementos del lenguaje común de intercambio de
información, asegurando la compatibilidad con ambos estándares.
·
UsoInternacional\GML\WFS
9.3
NTC 4611 – ISO 19115
Nombre: NTC 4611 – ISO 19115
Orígenes: El estándar ISO 19115:2003 define el esquema requerido para la descripción de
información y servicios geográficos. Provee información sobre la identificación, la extensión, la
calidad, los esquemas temporales y espaciales, la referencia especial y la distribución de datos
geográficos digitales. En 2003 fue declarado estándar internacional ISO.
La Norma Técnica Colombiana NTC 4611 - Metadatos Geográficos (primera actualización), fue
desarrollada entre los años 199 y 2002 dentro de las actividades del Comité Técnico de
Página 33 de 88
INTERNACIONALES
Normalización 028 de Información Geográfica. Da inicio con el objetivo de establecer un estándar de
metadatos geográficos que sirviera de referencia para la correcta documentación de la información
geográfica en el país.
Posteriormente, entre los años 2007 y 2009 se adelanta la segunda actualización de la norma, la cual
desarrolla no sólo
los
lineamientos para documentar la Información geográfica,
sino
adicionalmente aporta a la compatibilidad entre
estándares internacionales, en procura de
llegar a establecer sistemas, aplicativos y directorios de datos espaciales que permitan el intercambio
de información.
Define elementos del metadato geográfico obligatorios y condicionales que constituyen el núcleo
mínimo requerido27 para cumplir los propósitos de localizar datos, determinar su aptitud de uso,
forma de acceso y transferencia; y elementos opcionales que permiten una descripción más
detallada de los datos geográficos.
El anexo A de la norma presenta diagramas UML (Unified Modelling Languaje) que muestran una
vista del modelo total, definiendo las secciones del metadato (paquetes en UML) como entidades
relacionadas, así como sus elementos, tipos de dato y listas de código. Esta información ha sido
implementada en la estructuración y montaje de herramientas de gestión de metadatos como es el
caso del Sistema Web de Administración de Metadatos Institucional – SWAMI, la cual ha sido
desarrollada por el Instituto Geográfico Agustín Codazzi – IGAC y se presenta actualmente en su
tercera versión. De la misma forma, existen otras herramientas que han sido desarrolladas conforme
a la norma ISO 19115 entre las cuales se puede mencionar el software Geonetwork.
Estructura: La idea principal de la NTC 4611 (segunda actualización) conforme a ISO 19115 es
documentar y dotar de información de localización a cualquier objeto o producto geográfico 28. Para
tal fin, utiliza un conjunto de esquemas que definen los elementos a utilizar en tramas XML que
representen un metadato geográfico, es decir, la identificación, calidad del dato, localización
geográfica del objeto o conjunto de datos, entre otros. La figura muestra la estructura general que
contempla el estándar.
27
El núcleo mínimo corresponde al estándar Dublin C re que se ha implementado para facilitar el intercambio y consulta de información a
través de Internet.
28
Se debe entender objeto geográfico como una representación abstracta de un elemento o fenómeno del mundo real asociado a una
localización espacial y temporal, y producto geográfico como un conjunto de datos u objetos geográficos; de la misma forma, se debe
considerar como producto geográfico cualquier documento relacionado con la descripción de este tipo de información.
Página 34 de 88
INTERNACIONALES
Figura 6. Estructura general de NTC 4611 – ISO 19115 (Fuente: IGAC)
29
Al interior de cada una de las secciones se define un conjunto de elementos atómicos en los cuales
se incluye la información de los atributos que se desea asociar a la documentación del objeto o
producto geográfico.
En cada una de las secciones se reutilizan elementos que forman parte de un lenguaje común de
intercambio de información, definido para el estándar, entre los cuales se incluyen tipos básicos de
dato como cadenas y fecha s, junto con elementos básicos para su descripción-. Muchos de estos
elementos ya existen en el lenguaje común de intercambio de información con nombres diferentes.
El conjunto de esquemas cuenta con más de 200 elementos.
intercambio de información: Algunas de las diferencias entre los documentos que cumplen con
los esquemas definidos por NTC 4611 (segunda actualización) y los pertenecientes al lenguaje común
de intercambio de información se listan a continuación.

Uso de XLink para expresar relaciones entre elementos.
29
Tomado de: IGAC. Infraestructura de Datos Espaciales y Gestión de la Información – Metadatos Geográficos. 2011 (metadatos
geográficos.ppsx)
Página 35 de 88
INTERNACIONALES

Uso de XPath para expresar referencias internas y externas con otros documentos y
recursos.

Uso generalizado de espacios de nombres en los documentos, dados los múltiples esquemas
que componen el lenguaje. En el evento de adoptar el lenguaje, sería necesario importar
varios esquemas.

Los metadatos utilizados dentro del lenguaje definido por NTC 4611 (segunda actualización)
tienen una estructura diferente a la de los metadatos del lenguaje común de intercambio de
información, lo cual hace particularmente difícil la correspondencia entre unos y otros.

Todos los elementos con importancia semántica dent ro del lenguaje NTC 4611 (segunda
actualización) están definidos como compuestos. Sus documentos sólo registran información
directamente en elementos básicos.
Entre las semejanzas entre los dos lenguajes se pueden contar:

Todos los elementos complejos del lenguaje NTC 4611 (segunda actualización) se construyen
a partir de referencias a elementos más simples que también están definidos en el lenguaje.

Los diferentes esquemas del lenguaje son equiparables hasta cierto punto a capas, de una
forma similar al lenguaje común de intercambio de información. Sin embargo, la semántica de
las capas del lenguaje en cuestión es diferente.
Necesidades para hacer converger el estándar: Debido a las particularidades estructurales con
las cuales cuenta el lenguaje NTC 4611 (segunda actualización), su complejidad y tamaño, es difícil y
acaso innecesario hacerlo converger hacia el lenguaje común de intercambio de información. Sin
embargo, teniendo en cuenta la estabilidad del estándar es posible adaptar sus elementos e incluir
los en el lenguaje común de intercambio de información, para cuyo efecto se podrían dejar de lado
sus metadatos. Sólo queda el problema de la traducción de espacios de nombres, el cual puede
resolverse realizando ajustes a los esquemas utilizados por las entidades en sus intercambios
específicos, con el apoyo de la administración del lenguaje común de intercambio de información.
Recomendación de adopción: Se recomienda seguir uno de dos cursos de acción:
1. Adaptar los elementos del lenguaje NTC 4611 (segunda actualización), descartando la mayoría
de los metadatos y definiendo reglas de nombramiento en los documentos que vayan a utilizar
estos elementos. En esta estrategia se eliminarían los elementos relacionados con localización
ya existentes en el lenguaje común de intercambio de información y que entran en conflicto
con el estándar en cuestión, siempre y cuando no se encuentren en una capa inferior a la de
uso internacional.
2. Definir elementos del lenguaje común de intercambio de información para encapsular las
tramas correspondientes a NTC 4611 (segunda actualización) y delegar en las aplicaciones
Página 36 de 88
INTERNACIONALES
misionales de las entidades la responsabilidad de procesar estos documentos adecuadamente.
En este escenario, de rápida adopción, no es necesario incorporar al lenguaje común de
intercambio de información elementos de manera masiva, evitando conflictos semánticos, y se
mantiene su flexibilidad al permitir la adopción futura de porciones del lenguaje NTC 4611
(segunda actualización) cuando se estime conveniente.
Los escenarios presentados comparten las siguientes ventajas:

Sería posible homologar las certificaciones otorgadas a las entidades dentro del esquema de
ICDE con una certificación de nivel 1 de GEL, incorporándolas al estándar.

Sería posible la definición de documentos mixtos que incluyan información de localización y
elementos del lenguaje común de intercambio de información al mismo tiempo, con lo cual se
logra el efecto de borde de permitir la implementación de la idea de la ICDE de dotar a todo
objeto de una información de localización.
Dependiendo de las necesidades expresadas por el IGAC y las demás entidades de ICDE, es posible
definir un plan por fases, la primera de las cuales incorporaría los elementos encapsuladores al
lenguaje común de inter cambio de información. En fases subsiguientes podrían seguirse añadiendo
elementos cuya necesidad sea sentida por las entidades.
Página 37 de 88
INTERNACIONALES
10.
Dublin Core
Nombre: El Ministerio de Cultura, tiene como objetivo el aval en el uso de Lenguaje Común de
Intercambio de Información, con la incorporación y el uso del estándar internacional Dublin Core
(DC), como sistema bibliográfico para la publicación de las colecciones de la Biblioteca Nacional y el
Museo Nacional, tal como es definido por la Dublin Core Metadata Initiative (DCMI) como un sistema
de definiciones semánticas descriptivas que pretenden transmitir un significado semántico a las
mismas30.
Orígenes: La elaboración del estándar DublinCore, tiene su origen en 1995 cuando, se definieron en
Dublin (Ohio, USA) los estantaderes básicos de Web y Metadata. Más adelante en el 2003, el
estándar sería adoptado mediante norma ISO-15836; actualizada por la norma NISO-Z39.85-2007.
Actualmente existen diversas organizaciones de carácter internacional que usan el estándar, entre las
que se encuentran The national Library of Finland, Universe of Tsukuba y National Library Board of
Singapore.
Estado Del Dublin Core En Colombia: El Ministerio de Cultura, en cumplimiento de sus funciones
de vigía de la política del sector cultural colombiano, maneja, entre otras, una extensa red
bibliográfica entre las que se encuentran bibliotecas, museos, institutos y otros generadores de
información cultural o bibliográfica.
En el desarrollo de esta tarea, el citado Ministerio, utiliza como herramienta tecnológica, el estándar
Dublin Core.
De acuerdo a la Solicitud de Servicio, MinCultura, desea incorporar dicho estándar al lenguaje Común
de intercambio de información, y validar su uso en las entidades con las que se relaciona y cuya
naturaleza fue mencionada anteriormente.
Otras entidades que han incorporado el estándar DublinCore, han sido:
DANE: para la publicación de metadatos y microdatos de gestión estadística.
DNP: Para la gestión de Metadatos de Publicaciones de la entidad.
Estructura: El estándar se compone de elementos o definiciones, que a su vez contienen 5
propiedades o metadatos que proveen información acerca del elemento, más 10 características
opcionales:
Name:
30
Identificador del elemento definido por DCMI
Core Dublin ® Metadata Initiative, 1995 - 2012
Página 38 de 88
INTERNACIONALES
Label:
URI:
Definition:
Type of Term:
Etiqueta escrita en lenguaje humano comprensible, asignada al elemento
(Uniform Resource Identifier) identificador único para el uso del elemento.
Preposición que representa el concepto y esencia natural del elemento.
Tipo de elemento definido por DCMI.
Comment:
See:
References:
Refines:
Broader Than:
Narrower Than:
Has Domain:
Has Range:
Member Of:
Instance Of:
Version:
Equivalent
Property:
Comentario, información adicional del elemento.
Ver más, Autoridad documental relacionada con el término.
Referencia, recurso bibliográfico para la definición del elemento.
Propiedad que determina si existe una sub-propiedad.
Más amplio que, clase que describe si el elemento es una super-clase
Más estrecho que, clase que describe si el elemento es una sub-clase
Clase que determina si el recurso descrito por el elemento es una instancia
Clase que determina si el valor del elemento es una instancia
Numeración de recursos (Vocabulary Encoding Scheme) de la que el elemento hace parte.
Clase que define si el elemento es una instancia.
Descripción histórica y específica del elemento.
Propiedad que determina una equivalente.
Tabla 1 -Propiedades o Metadatos básicos31
Tabla 2 Propiedades o Metadatos adicionales. 32
10.1 Elementos del DC33.
De acuerdo a la estructura de los elementos del DC, señalada en el punto anterior, los elementos con
sus características correspondientes son las siguientes:
Title
Etiqueta: Título
Descripción del elemento: El nombre dado al recurso. Por lo general, un título será un nombre con el
que se conoce formalmente el recurso.
Directrices para la creación de contenido:
En caso de duda acerca de lo que constituye el título, repetir el elemento Título e incluir las variantes
en iteraciones Título segundo y siguientes. Si el artículo está en HTML, ver el documento de origen y
asegúrese de que el título identificados en el encabezamiento del título (si lo hay) también se incluye
como un título.
Ejemplos:
31
Adaptado, Core Dublin ® Metadata Initiative, 1995 - 2012
Adaptado, Core Dublin ® Metadata Initiative, 1995 – 2012
33
La totalidad de la sección fue adaptada y traducida
http://dublincore.org/documents/usageguide/elements.shtml
32
Página 39 de 88
de
la
Core
Dublin
Metadata
Initiative,
INTERNACIONALES
Title = "Guía para aseguradoras de vuelo"
Title = "El sonido de la música"
Title = "Verde sobre verde"
Subject
Etiqueta: Objetivo o palabras clave.
Descripción Elemento: El tema del contenido del recurso. Por lo general, un tema se expresará como
palabras clave o frases clave o códigos de clasificación que describen el tema de los recursos. La
práctica recomendada es seleccionar un valor de un vocabulario controlado o sistema de clasificación
formal.
Seleccione palabras clave del asunto del Título o Descripción Información, o desde un recurso de
texto. Si el tema del artículo es una persona o una organización, utilizar el mismo formulario del
nombre que lo haría si la persona u organización fuera un Creador o Colaborador.
En general, elegir las palabras más importantes y únicas para palabras clave, evitando los demasiado
general para describir un elemento determinado. Asunto podría incluir datos de clasificación, si está
disponible (por ejemplo, la Biblioteca del Congreso Números de clasificación Dewey o números
decimales) o vocabularios controlados (tales como Medical Subject Headings o Arte Arquitectura y
descriptores Tesauro), así como las palabras clave.
Al incluir los términos de vocabularios múltiples, utilice iteraciones independientes de los elementos.
Si varios términos de vocabulario o palabras clave se utilizan, ya sea en términos separados con
punto y coma o utilizar iteraciones separadas del elemento de sujeción.
Ejemplos:
Subject = "Accidentes aéreos"
Subject = "Perros"
Subject = "esquí olímpico"
Description
Etiqueta: Descripción
Descripción del elemento: Una cuenta del contenido del recurso. Descripción puede incluir, pero no
se limitan a: un resumen, tabla de contenidos, la referencia a una representación gráfica del
contenido o una cuenta de texto libre del contenido.
Página 40 de 88
INTERNACIONALES
Dado que el campo Descripción es una fuente potencialmente rica de términos intercambiables, se
debe tener cuidado para proporcionar este elemento cuando sea posible. La mejor recomendación
para la práctica de este elemento es el uso de oraciones completas, como la descripción a menudo se
utiliza para presentar información a los usuarios para ayudar en la selección de los recursos
adecuados a partir de un conjunto de resultados de búsqueda.
La información descriptiva se no puede copiar ni extraer de forma automática desde el punto si hay
descripción disponible abstracto o de otro tipo estructurado. Aunque la fuente de la descripción
puede ser una página web o texto estructurado a otros con etiquetas de presentación, no es
generalmente una buena práctica incluir las etiquetas HTML estructurales o de otro tipo en el
Descripción del elemento. Las aplicaciones varían considerablemente en su capacidad de interpretar
esas etiquetas, y su inclusión podría afectar negativamente a la interoperabilidad de los metadatos.
Ejemplos:
Descripción = "Guía Ilustrada de marcas y señales de iluminación de aeropuertos, con especial
referencia a SMGCS (Guía de movimiento en superficie y Sistema de Control) para los aeropuertos
con condiciones de baja visibilidad."
Descripción = "Dominio de Maestros es una biblioteca multimedia para educadores K-12, desarrollado
por la ciencia a través de WGBH financiamiento de la Fundación Nacional de la Ciencia, como parte
de su iniciativa National Science Digital Library. El sitio ofrece una gran cantidad de listas aula de
recursos didácticos, así como materiales de desarrollo profesional en línea y un conjunto de
herramientas que permite a los profesores gestionar, anotar y compartir los materiales que utilizan
en la enseñanza en el aula. "
Type
Etiqueta: Tipo de recurso
Descripción Elemento: La naturaleza o género del contenido del recurso. Tipo incluye términos que
describen categorías generales, funciones, géneros o niveles de agregación de contenidos. La
práctica recomendada es seleccionar un valor de un vocabulario controlado (por ejemplo, el
vocabulario DCMIType). Para describir la manifestación física o digital del recurso, utilice el elemento
FORMAT.
Si el recurso se compone de múltiples tipos mixtos entonces elementos de tipo múltiple o repetida
debe ser usado para describir los componentes principales.
Debido a las diferentes comunidades o dominios que se espera utilizar una variedad de vocabularios
tipo, las mejores prácticas para garantizar la interoperabilidad es incluir al menos un término tipo
general del vocabulario DCMIType además del término dominio tipo específico (s), en diferentes
iteraciones tipo de elemento.
Página 41 de 88
INTERNACIONALES
Ejemplos:
Tipo = "Imagen"
Tipo = "Sonido"
Type = "texto"
Tipo = "simulación"
Nota: Los tres primeros valores se toman del vocabulario Tipo DCMI y siga las convenciones de
capitalización para ese vocabulario. El último valor es un término procedente de una fuente no
especificada.
El artículo descrito es un catálogo de exposiciones de arte electrónico:
Tipo = "Imagen"
Tipo = "texto"
Tipo = "Catálogo de la exposición"
Nota: Los dos primeros valores se toman del vocabulario Tipo DCMI y siga las convenciones de
capitalización para ese vocabulario. El último valor es un término procedente de una fuente no
especificada.
El artículo describe un programa educativo multimedia con las tareas interactivas:
Tipo = "Imagen"
Type = "texto"
Tipo = "Software"
Tipo = "Recursos Interactivos"
Nota: Todos los valores de este ejemplo se toman del vocabulario Tipo DCMI y siga las convenciones
de capitalización para ese vocabulario.
Source
Etiqueta: fuente
Descripción del elemento: Una referencia a un recurso del que se deriva el recurso actual. El recurso
actual se puede derivar de la Fuente de recursos en todo o en parte. La práctica recomendada es
hacer referencia al recurso por medio de una cadena o un número conforme a un sistema de
identificación formal.
Pautas para la creación de contenido:
En general, se incluyen en esta área de información acerca de un recurso que se relaciona
intelectualmente al recurso descrito pero no encaja fácilmente en un elemento de relación.
Ejemplos:
Página 42 de 88
INTERNACIONALES
Source = "RC607.A26W574 1996" [donde "RC607.A26W574 1996" es el número de llamada de la
versión impresa del recurso, de la que se examinó la versión actual]
Fuente = "Imagen de la página 54 de la edición 1922 de Romeo y Julieta"
Relation
Etiqueta: Relación
Descripción del elemento: Una referencia a un recurso relacionado. La práctica recomendada es
hacer referencia al recurso por medio de una cadena o un número conforme a un sistema de
identificación formal.
Las relaciones pueden ser expresadas recíprocamente (si los recursos en ambos extremos de la
relación se describen) o en una dirección solamente, incluso cuando hay un refinamiento disponibles
para permitir la reciprocidad. Si se utilizan cadenas de texto en lugar de números de identificación, la
referencia debe ser adecuadamente determinada. Por ejemplo, una cita bibliográfica formal puede
ser utilizada para indicar a los usuarios a un recurso particular.
Debido a que los términos utilizados con relación refinados proporcionar mucha más información que
un usuario que el uso irrestricto de relación, los ejecutores que se describan los recursos fuertemente
interrelacionados puede optar por utilizar Dublin Core cualificado.
Ejemplos:
Title = "La lectura Turgenev"
Relación = "Dos Vidas" [Recurso es un conjunto de dos novelas, una de ellas es "Lectura" Turgenev]
[Relación descrito es IsPartOf.
[Relaciones parte / todo aquellas en las que un recurso es una parte física o lógica de otro]
Title = "Candle in the Wind"
Subject = "Diana, princesa de Gales"
Date = "1997"
Creador = "John, Elton"
Tipo = "sonido"
Descripción = "Homenaje a una princesa muerta".
Relación = "Elton John 1976 canción Candle in the Wind"
[Relación descrito es IsVersionOf.
[Versión relaciones son aquellas en las que un recurso es un estado histórico o edición de otro
recurso por el mismo creador]
Title = "Electronic AACR2"
Relación = "Anglo-American Cataloging Rules, 2 ª edición"
Página 43 de 88
INTERNACIONALES
[Relación descrito es IsFormatOf]
Title = "Landsat TM conjunto de datos de Arnhemland, NT, Australia"
Relación = "arnhem.gif"
[Relación descrito es hasFormat]
[Relaciones de transformación de formato son aquellos en los que ha sido un recurso derivado de
otro por una tecnología de reproducción o cambio de formato que no es fundamentalmente una
interpretación pero pretende ser una representación.]
Title = "Ancient Society de Morgan"
Relación = "Engels El origen de la familia, la propiedad privada y el Estado"
[Relación descrito es IsReferencedBy]
Title = "Nymphet Mania"
Relación = "Referencias Adrian Lyne 'Lolita'"
[Relación descrito es Referencias]
[Las relaciones de referencia son aquellos en los que el autor de un recurso cita, reconoce, las
disputas o hacer afirmaciones acerca de otro recurso.]
Title = "novela de Peter Carey, Oscar y Lucinda"
Relación = "1998 película Oscar y Lucinda"
[Relación descrito es IsBasisFor]
Title = "La película My Fair Lady"
Relación = "juego de Shaw Pigmalión"
[Relación descrito es IsBasedOn]
[Relaciones creativas son aquellas en las que un recurso es un rendimiento, producción, derivación,
la adaptación o la interpretación de otro recurso.]
Title = "Dead Ringer"
Relación = "Gemstar e-book"
[Relación descrito se requiere]
[Relaciones de dependencia son aquellos en los que uno de los recursos requiere otro recurso para
su funcionamiento, la entrega, o el contenido y no se puede utilizar sin el recurso relacionado estar
presente.]
Coverage
Etiqueta: Cobertura
Descripción del elemento: La extensión o alcance del contenido del recurso. La cobertura incluirá
típicamente ubicación espacial (nombre de un lugar o coordenadas geográficas), periodo temporal
(etiqueta de período, fecha o rango de fechas) o jurisdicción (como una entidad administrativa). La
práctica recomendada es seleccionar un valor de un vocabulario controlado (por ejemplo, el Tesauro
de Nombres Geográficos [Tesauro Getty de nombres geográficos, http://www. Getty.edu /
investigación / tools / vocabulario / tgn /]). Donde lugares apropiados, con nombre o períodos de
tiempo se debe utilizar con preferencia a los identificadores numéricos como conjuntos de
coordenadas o rangos de fecha.
Página 44 de 88
INTERNACIONALES
Si se usa este elemento de información espacial o temporal, se debe tener cuidado de proporcionar
información consistente, que puede ser interpretada por usuarios humanos, en particular con el fin
de proporcionar interoperabilidad en situaciones en las búsquedas sofisticadas geográfica o tiempo
específico, no es compatible. Para las aplicaciones más simples, nombres de lugares o fechas de
cobertura podría ser más útil. Para aplicaciones más complejas, se debe considerar la posibilidad de
utilizar un esquema de codificación que soporta la especificación adecuada de la información, como el
período DCMI, Caja DCMI o Punto de DCMI.
Ejemplos:
Cobertura
Cobertura
Cobertura
Cobertura
=
=
=
=
"1995-1996"
"Boston, MA"
"siglo 17"
"Upstate New York"
Creator
Etiqueta: creador
Descripción del elemento: Una entidad principal responsable de crear el contenido del recurso.
Ejemplos de un Creador incluir a una persona, una organización o un servicio. Típicamente, el
nombre del Creador se debe utilizar para indicar la entidad.
Los creadores deben enumerarse por separado, preferiblemente en el mismo orden en que aparecen
en la publicación. Los nombres personales deben figurar apellido o apellido primero, seguido por el
nombre o nombre de pila. En caso de duda, dar el nombre tal como aparece, y no invertir.
En el caso de las organizaciones donde existe una clara jerarquía actual, enumerar las partes de la
jerarquía de mayor a menor, separados por puntos y un espacio. Si no está claro si hay una jerarquía
presente, o poco claro que es la porción más grande o más pequeña del cuerpo, dar el nombre tal
como aparece en el artículo.
Si el Creador y editor son los mismos, no repita el nombre en el área de Publisher. Si la naturaleza de
la responsabilidad es ambigua, la práctica recomendada es utilizar Publisher para las organizaciones,
y el Creador de las personas. En los casos de responsabilidad menor o ambigua, que no sea la
creación, utilice Colaborador.
Ejemplos:
Creador = "Shakespeare, William"
Página 45 de 88
INTERNACIONALES
Creador = "Wen Lee"
Creador = "Hubble Telescope"
Creador = "Internal Revenue Service. Cliente Quejas Unidad"
Publisher
Etiqueta: Editor
Descripción del elemento: La entidad responsable de los recursos disponibles. Los ejemplos de un
editorial incluyen a una persona, una organización o un servicio. Normalmente, el nombre de un
editor debe utilizarse para indicar la entidad.
La intención de especificar este campo es la identificación de la entidad que proporciona el acceso al
recurso. Si el Creador y editor son los mismos, no repita el nombre en el área de Publisher. Si la
naturaleza de la responsabilidad es ambigua, la práctica recomendada es utilizar Publisher para las
organizaciones, y el Creador de las personas. En los casos de responsabilidad ambigua, utilice
Colaborador.
Ejemplos:
Editor = "Universidad del Sur de donde"
Editor = "Sitios web Funky, Inc."
Editor = "Carmen Miranda"
Contributor
Etiqueta: Contribuyente
Descripción del elemento: La entidad responsable de hacer contribuciones al contenido del recurso.
Ejemplos de un colaborador incluir a una persona, una organización o un servicio. Típicamente, el
nombre de un colaborador se debe utilizar para indicar la entidad.
Guía para la creación de contenido:
Las mismas pautas generales para el uso de nombres de personas u organizaciones como creadores
se aplican aquí. Colaborador es el más general de los elementos utilizados por "agentes"
responsables del recurso, por lo que se debe utilizar cuando la responsabilidad primaria es
desconocida o irrelevante.
Rights
Etiqueta: Gestión de Derechos
Página 46 de 88
INTERNACIONALES
Descripción del Elemento: Información sobre los derechos en y sobre el recurso. Normalmente, un
elemento Derechos contendrá una declaración de gestión de derechos para el recurso, o hacer
referencia a un servicio que proporciona dicha información. Información sobre los derechos a
menudo abarca derechos de propiedad intelectual (DPI) y derechos de autor, de propiedad distintos.
Si el elemento de derechos está ausente, no se pueden hacer suposiciones acerca de la situación de
estos y otros derechos con respecto a los recursos.
El elemento de derechos se pueden utilizar ya sea para una declaración textual o un URL que apunta
a una declaración de derechos, o una combinación, cuando una instrucción breve y una más larga
uno están disponibles.
Ejemplos:
Derechos = "Acceso limitado a los miembros"
Derechos = "http://cs-tr.cs.cornell.edu/Dienst/Repository/2.0/Terms & quot;
Date
Etiqueta: Fecha
Descripción de elementos: Una fecha asociada con un evento en el ciclo de vida del recurso.
Típicamente, la fecha se asocia con la creación o la disponibilidad del recurso. La práctica
recomendada para codificar el valor de fecha se define en un perfil de ISO 8601 [Formatos de fecha
y hora, Nota del W3C, http://www.w3.org/TR/NOTE- datetime] y sigue el formato AAAA-MM-DD .
Si la fecha es mes completo desconocido, y el año (AAAA-MM) o sólo el año (AAAA) pueden ser
utilizados. Muchos otros sistemas son posibles, pero si se utiliza, no puede ser fácilmente
interpretada por los usuarios o software.
Ejemplos:
Date = "16/02/1998"
Date = "1998-02"
Date = "1998"
Format
Etiqueta: Formato
Descripción del elemento: La manifestación física o digital del recurso. Típicamente, el formato puede
incluir medios de comunicación de tipo o dimensiones del recurso. Ejemplos de dimensiones incluyen
Página 47 de 88
INTERNACIONALES
el tamaño y la duración. El formato puede ser utilizado para determinar el software, hardware o
cualquier otro equipo necesario para mostrar u operar el recurso.
La práctica recomendada es seleccionar un valor de un vocabulario controlado (por ejemplo, la lista
de los tipos de medios de Internet [http://www.iana.org/ assignments / media-types /] definen los
formatos de medios informáticos).
Además del formato de medios específica física o electrónica, la información relativa al tamaño de un
recurso puede ser incluido en el contenido del elemento Formato si está disponible. En recurso
tamaño descubrimiento, medida o medio del recurso podría ser usado como un criterio para
seleccionar recursos de interés, ya que un usuario puede tener que evaluar si se puede hacer uso de
los recursos dentro de la infraestructura disponible para ellos.
Cuando más de una categoría de información de formato se incluye en un solo registro, deben ir en
iteraciones separadas del elemento.
Ejemplos:
Title = "Dublin Core icono"
Identificador = "http://purl.org/metadata/dublin_core/images/dc2.gif & quot;
Tipo = "Imagen"
Formato = "image / gif"
Formato = "4 kB"
Subject = "Saturn"
Tipo = "Imagen"
Formato = "image / gif 6"
Format = "40" x 512 píxeles
Identificador = "http://www.not.iac.es/newwww/photos/images/satnot.gif"
Title = "El Bronco Buster"
Creador = "Frederic Remington"
Tipo = "objeto físico"
Formato = "bronce"
Formato = "22 pulgadas"
Identifier
Etiqueta: Identificador de Recursos
Elemento Descripción: Una referencia clara al recurso en un contexto dado. La práctica recomendada
es identificar el recurso mediante una cadena o un número conforme a un sistema de identificación
formal. Ejemplos de sistemas de identificación formales incluyen el identificador uniforme de recursos
(URI) (incluyendo el Uniform Resource Locator (URL), el Identificador de Objetos Digitales (DOI) y el
Número Internacional Normalizado para Libros (ISBN).
Página 48 de 88
INTERNACIONALES
Este elemento también se puede utilizar para los identificadores locales (por ejemplo, números de
identificación o números de llamada) asignados por el creador del recurso que se aplican a un
elemento determinado. No debe ser utilizado para la identificación del registro de metadatos en sí.
Ejemplos:
Identificador = "http://purl.oclc.org/metadata/dublin_core/ & quot;
Identificador = "ISBN: 0385424728"
Identificador = "H-A-5690B X" [número de editor]
Language
Etiqueta: Idioma
Descripción del elemento: Un idioma del contenido intelectual del recurso. La práctica recomendada
para los valores del elemento de lenguaje se define en el RFC 3066 [RFC 3066,
http://www.ietf.org/rfc/ rfc3066.txt] que, en conjunto con ISO 639 [ISO 639, http:// www.oasisopen.org/cover/iso639a.html]), define de dos y tres letras las etiquetas de idioma primarias con subetiquetas opcionales. Por ejemplo, "en" o "eng" para inglés, "akk" para acadio, y "es-ES" para Inglés
utilizado en el Reino Unido.
Ya sea un valor codificado o cadena de texto se pueden representar aquí. Si el contenido se
encuentra en más de un idioma, el elemento puede repetirse.
Ejemplos:
Language = "en"
Language = "fr"
Language = "Principalmente Inglés, con algunos resúmenes también en francés."
Language = "en-US"
NOTA: Audiencia, procedencia y titulares de derechos son elementos, pero no forman parte del
Dublin Core simple quince elementos. Utilice Audiencia, procedencia y titular de derechos sólo
cuando se utiliza Qualified Dublin Core.
Audience
Etiqueta: Audiencia
Página 49 de 88
INTERNACIONALES
Descripción del elemento: Una clase de entidad para la que el recurso tiene por objeto o útil. Una
clase de entidad puede ser determinada por el creador o el editor o por un tercero.
Términos de audiencia son los más utilizados en el contexto de los vocabularios controlados formales
o informales. No se recomienda en la actualidad o registrados por DCMI, pero varias comunidades de
interés se dedican a la creación de vocabularios audiencia. En ausencia de recomendaciones de
vocabularios controlados, los ejecutores se les animan a desarrollar listas locales de valores y usarlos
constantemente.
Ejemplos:
Audiencia = "estudiantes de primaria"
Audiencia = "ESL maestros"
Audiencia = "adultos sordos"
Provenance
Etiqueta: Procedencia
Descripción del elemento: Una declaración de cualquier cambio en la propiedad y custodia de los
recursos desde su creación, que son importantes para su autenticidad, integridad e interpretación. La
declaración puede incluir una descripción de los custodios sucesivos cambios realizados en el recurso.
Ejemplos:
Procedencia = "Esta copia fue propiedad de Benjamin Spock".
Procedencia = "Propiedades de Hunter Thompson."
Procedencia = "Robado en 1999, recuperada por el Museo en 2003."
RightsHolder
Etiqueta: Propietario de los derechos
Descripción del elemento: Una persona u organización de tenencia o gestión de los derechos sobre el
recurso. La práctica recomendada es utilizar el URI o nombre del titular de los derechos para indicar
la entidad.
Página 50 de 88
INTERNACIONALES
Dado que, en su mayor parte, las personas y organizaciones que no se suelen asignar URIs, una
persona o una organización que posee los derechos sobre un recurso sería nombrado mediante una
cadena de texto. Las personas y las organizaciones a veces tienen sitios web, pero URLs para estos
generalmente no son apropiados para su uso en este contexto, ya que no se identifique claramente a
la persona u organización, sino más bien la ubicación de un sitio web acerca de ellos.
Ejemplos:
Titular de Derechos = "Stuart Weibel"
Titular de Derechos = "University of Bath"
InstructionalMethod
Etiqueta: Método de Instrucción
Descripción del Elemento: Un proceso, que se utiliza para generar conocimientos, actitudes y
habilidades, que el recurso está diseñado para soportar. Método de Instrucción suelen incluir formas
de presentar los materiales de instrucción o la realización de actividades de enseñanza, los patrones
de alumno a alumno-alumno y la interacción a los instructores y los mecanismos mediante los cuales
los niveles de grupo e individuales de aprendizaje se miden. Los métodos de instrucción incluyen
todos los aspectos de la enseñanza y procesos de aprendizaje, desde la planificación y puesta en
práctica a través de la evaluación y la retroalimentación.
La mejor práctica es utilizar términos de vocabularios controlados, desarrollados para el uso de un
determinado proyecto o de uso general en un contexto educativo.
Ejemplos:
InstructionalMethod = "aprendizaje por experiencia"
InstructionalMethod = "Observación"
InstructionalMethod = "instrucción Grupo grande"
AccrualMethod
Etiqueta: Método en valores devengados
Descripción del elemento: El método por el cual se agregan elementos a una colección. La práctica
recomendada es utilizar un valor de un vocabulario controlado.
Página 51 de 88
INTERNACIONALES
Condiciones de vocabularios controlados pueden ser desarrolladas para el uso de un determinado
proyecto o de uso general en un contexto material cultural.
Ejemplos:
AccrualMethod = "Depósito"
AccrualMethod = "Compra"
AccrualPeriodicity
Etiqueta: Acumulación Periódica
Elemento Descripción: La frecuencia con la que se agregan elementos a una colección. La práctica
Condiciones de vocabularios controlados pueden ser desarrollados para el uso de un determinado
Ejemplos:
AccrualPeriodicity = "Anual"
AccrualPeriodicity = "Irregular"
AccrualPolicy
Etiqueta: Política de Acumulación
Descripción del elemento: La política que rige la adición de elementos a una colección. La práctica
Condiciones de vocabularios controlados pueden ser desarrolladas para el uso de un determinado
Ejemplos:
AccrualPolicy = "Activo"
AccrualPolicy = "Cerrado"
Página 52 de 88
INTERNACIONALES
Principales diferencias y similitudes con el Lenguaje Común de intercambio de
información:
Similitudes: El estándar DublinCore, es un metalenguaje de gran complejidad al igual que el
estándar de Lenguaje Común de Intercambio de Información. Se pueden resaltar las siguientes
similitudes:
Metadato: En ambos estándares se cuentan con metadatos tanto semánticos como técnicos,
que son compatibles entre sí.
Elemento de dato: En ambos estándares, la unidad mínima de es el elemento de dato, que
pude definirse como un concepto o una unidad de información.
Componente Técnico: Para ambos estándares se utiliza el XML W3C Schema.
Jerarquía: La jerarquía en ambos estándares es horizontal; se resalta que el DublinCore,
únicamente posee una capa de información, versus las siete capas del Lenguaje Común de
Intercambio de Información, sin que esto signifique problemas de compatibilidad.
Niveles de interoperabilidad: Ambos estándares, durante el proceso de incorporación, utilizan
diferentes niveles de interoperabilidad.
Un primer nivel en el que se comparten los
elementos comunes y se conceptualiza la información a intercambiar. Un segundo nivel,
donde se define un modelo claro de interoperabilidad.
Diferencias: Aunque los estándares presentan algunas diferencias en cuanto a las definiciones
conceptuales, estas deben ser discutidas en las implicaciones técnicas –capítulo 10 del documento.
Conclusión: Entre los estándares, son más significativas las similitudes conceptuales, por tanto se
concluye que la incorporación del estándar DublinCore al estándar de Lenguaje Común de
Intercambio de Información, no debería presentar problemas de incompatibilidad.
Necesidad Para Hacer Converger El Lenguaje: Es meta del Lenguaje Común de
Intercambio de Información, estar presente en todas las transacciones de las entidades
nacionales, que se realicen en el Marco de Interoperabilidad.
Entendiendo que el estándar Dublin Core, cubre un sector importante de intercambio de
información, como el de referencias bibliográficas, y potencialmente, las necesidades de
intercambio de información documental y archivo en el país, el estándar de lenguaje, debe
realizar la incorporación mediante la adopción del estándar DC.
Recomendación De Incorporación Estándar Dublin Core: El Equipo de
Acompañamiento del Lenguaje Común de Intercambio de Información, considerando que:
Página 53 de 88
INTERNACIONALES
Corresponde al Equipo, brindar servicios de consultoría y acompañamiento continuo a las
entidades que adelantan procesos para la incorporación del estándar Lenguaje Común de
Intercambio de Información.
El estándar Dublin Core, contiene definiciones aplicadas únicamente a su campo de acción.
La adopción del estándar Dublin Core, se traduce en el mejor escenario para la aplicación
por parte de las entidades del Dominio Semántico de interoperabilidad con el Lenguaje
Común de Intercambio de Información.
La arquitectura de datos del estándar permite la inclusión de estándares internacionales en
la capa Uso Internacional, que a su vez facilitaría el uso y mantenimiento de dicho estándar
por los usuarios del lenguaje y por el operador del mismo.34
Recomienda, que sea incorporado el estándar en su totalidad en la Capa de Uso
Internacional, con la creación de dichos elementos según lo definido en el presente
documento, bajo la modalidad de adopción definida en el documento Ministerio de
Tecnologías de la Información y las Comunicaciones, Lenguaje Común de Intercambio de
Información-Evaluación de Estándares Internacionales, octubre-2011.
Con lo aquí expuesto, se procede de acuerdo a lo establecido para la adopción de estándares
internacionales, Sin embargo deben realizarse las acciones requeridas en las consideraciones
técnicas del presente documento.
34
Ministerio de Tecnologías de la Información y las Comunicaciones, Lenguaje Común de Intercambio de InformaciónEvaluación de Estándares Internacionales, octubre-2011
Página 54 de 88
INTERNACIONALES
Consideraciones Técnicas: Los elementos de datos ofrecidos por la DCMI para el
estándar DublinCore, tienen definiciones muy amplias y aplicables a cualquier contexto de
negocio. Se realiza un cruce con los elementos de dato existentes en el diccionario,
(REGLA DE VALIDACIÓN #4: ELEMENTOS DE DATO NUEVOS) encontrando que se
realizarían las siguientes modificaciones
Listado de
Elementos
Título
Fecha
Formato
Identificador
de Recursos
Audiencia
Identificador
Resultados
Regla de
Validación
Observaciones a
la Validación
Acción a Adelantar
Title
1 title
El
identificador del
Elemento
Title
elemento
de
utilizado por WMS
dato "title" a
crear ya existe
No establecer acción de
crear, y añadir metadato
del elemento según dublin
core
date
12 Fecha
El
nombre
del
elemento
de
dato "Fecha" a
crear ya existe
El elemento Fecha
capa de uso Común,
área de información
temporal. Se solicita
reconceptualización
del elemento de
dato, teniendo en
cuenta que el ISO
8601, define tipos
de fecha extendido.
del elemento según dublin
core
format
13 format
El
identificador del
Elemento
format crear, y añadir metadato
elemento
de
utilizado por WMS
del elemento según Dublín
dato "format" a
Core
crear ya existe
identifier
14 identifier El
identificador del
Elemento identifier
elemento
de
utilizado por WMS
dato "identifier"
a crear ya existe
del elemento según Dublín
Core
audience
16 Audiencia
El nombre del
elemento
de
dato "Audiencia"
a crear ya existe
Se solicita caducar del
elemento de dato, puesto
que
la
definición
propuesta por DCMI es
más amplia y obedece a
Elemento
compuesto, (cod y
nom) que define el
publico o caracteriza
la población usuaria
Página 55 de 88
Justificación
La definición dada
por la DCMI abarca
la
ofrecida
por
WMS.
Los
elementos de datos
tienen el mismo tipo
y no hay problemas
de compatibilidad.
Con el fin de
ampliar el campo de
acción del elemento
de dato, se solicita
modificar
el
elemento actual y
conceptualizarlo a
las
convenciones
del estándar ISO8601
a fin de
concordar
las
definiciones
del
DublinCore
La definición dada
por la DCMI abarca
la
ofrecida
por
WMS.
Los
elementos de datos
y no hay problemas
de compatibilidad.
La definición dada
por la DCMI abarca
la
ofrecida
por
WMS.
Los
elementos de datos
y no hay problemas
de compatibilidad.
Con el fin de
ampliar el campo de
Actualizar
el
INTERNACIONALES
Listado de
Elementos
Resultados
Regla de
Validación
Identificador
Observaciones a
la Validación
Acción a Adelantar
del PEC. Capa de un estándar internacional
uso proyectos PEC
módulo Core
Cobertura
coverage
7 Cobertura El
nombre
del
elemento
de
dato "Cobertura"
a crear ya existe
Elemento
compuesto, (cod y
nom) que define si
el campo de acción
es: internacional o
nacional. Definición
tomada
por
adaptación de la
RAE.
Se solicita caducar el
elemento de dato, puesto
que
la
definición
propuesta por DCMI es
más amplia y obedece a
un estándar internacional
Justificación
elemento actual a
fin de establecer las
definiciones
del
DublinCore
Con el fin de
ampliar el campo de
Actualizar
el
elemento actual a
fin de establecer las
definiciones
del
DublinCore
Estas modificaciones, se deberán adelantar para garantizar las integridad de los estándares Lenguaje
Común de Intercambio de Información y Dublin Core.
Frente a los elementos de datos utilizados por el estándar WMS, se deberá evaluar el estado actual
del mismo; no obstante, se debe tener en cuenta que los elementos en conflicto Identifier, audience
y format, tienen definiciones y metadatos no excluyentes en ambos estándares. Por lo que no se
debería presentar incidencias de tipo técnico en la generación de esquemas y de tipo conceptual en
las definiciones y uso.
En el elemento fecha, entendiendo que la ISO 8601, incluye diferentes tipos de representación, a
saber:
representación
completa
representación
de
precisión reducida
representación
expandida
formato básico (ejemplo)
YYYYMMDD (20071103)
formato extendido (ejemplo)
YYYY-MM-DD (2007-11-03)
YYYYMM (200711)
YYYY (2007)
YY (07)
YYYY-MM (2007-11)
±YYYYYYMMDD (+0020071103)
±YYYYYYMM (+00200711)
±YYYYYY (+002007)
±YYY (+0020)
±YYYYYY-MM-DD (+002007-11-03)
±YYYYYY-MM (+002007-11)
no se aplica
no se aplica
no se aplica
no se aplica
Y que la citada norma, es aplicable por definición tanto al estándar Dublin Core como al Lenguaje
Común de Intercambio de Información, se solicita modificar el elemento actual fecha, ubicado en la
capa de uso común y área de información temporal, de forma que se incluyan éstas nuevas
representaciones.
Página 56 de 88
INTERNACIONALES
Las entidades que se encuentren en uso de la representación completa, formato extendido yyyy-mmdd no se verán afectadas por la inclusión de las nuevas representaciones, por ser la última la más
amplia.
Por último las entidades que utilicen las diferentes representaciones, deberán acordar la forma en
que se interpretaran estos datos, para lo que será necesario el desarrollo de adaptadores; aspecto
considerado igualmente en la norma técnica 8601.
·
UsoInternacional\DCMI\DublinCore
Página 57 de 88
INTERNACIONALES
11.
Servicios Terminológicos en Salud
Nombre: Los Servicios Terminológicos en Salud corresponden a los estándares de clasificaciones
ofrecidos en diferentes organizaciones internacionales, a fin de establecer estándares semánticos en
cuanto a Tecnologías en Salud: Procedimientos en salud, Medicamentos de uso humano, Dispositivos
médicos, que articulados con Diagnósticos, alinean el momento en la prestación de servicios (acto
médico o asistencial) como el core del sistema y fuente esencial de información.
Articulación componentes en salud para proceso asistencial
Fuente:Minsalud 2013
Su principal función será la de alimentar de forma organizada y estandarizada cada uno de los
servicios, trámites o procesos que se presentan en el sector salud colombiano, como parte
fundamental de la estandarización de lo relacionado con eSalud y registros electrónicos.
Orígenes: El actual Sistema de Seguridad Social en Salud ha utilizado, desde su origen, diferentes
catálogos o listados tabulares para identificar las circunstancias que hacen que un ciudadano se
acerque a una institución en uso de su derecho a la salud, en su entendido más amplio.
Estos catálogos o listados tabulares, en el transcurso del tiempo, y a consecuencia de las complejas
circunstancias que rodean la atención de un ciudadano, estos se han hecho más complejos y se han
adaptado de forma irregular a cada circunstancia específica.
El Ministerio de Salud y Protección Social, ha realizado grandes esfuerzos normativos y conceptuales
para lograr una estandarización en los listados tabulares que se usan en el Sistema y que se traducen
en servicios terminológicos en salud.
Página 58 de 88
INTERNACIONALES
Estándares como CIE-10, CUPS, CUM y CIF, tienen una importante presencia en Colombia, gracias al
esfuerzo mencionado.
Por su puesto, el uso de estos estándares en Colombia, tienen su origen en organizaciones
internacionales de las que Colombia hace parte.
Puede concluirse que el origen de los servicios de terminología en salud, son de origen internacional.
Estado de los Servicios Terminológicos en Salud en Colombia
Los Servicios de terminología en salud, son utilizados en Colombia en diferentes trámites y servicios
del Sistema General en Seguridad Social, tales como:









RIPS
Recobros
Atención en Salud
Referencia
Facturación
Estadística
Promoción y Prevención
Estudios en Salud
Definición de Planes de Salud
Adicionalmente, existen aplicaciones variadas que son utilizadas por diversos actores del sistema y
que hacen uso de tales estándares.
Estructura
Los servicios terminológicos, son listas tabulares ordenadas y estructuradas utilizadas en los
siguientes componentes:
Diagnóstico
Listados tabulares o clasificaciones tendientes a registrar o anotar una situación particular, en
relación con el bienestar de una persona. Se tomarán clasificaciones para los siguientes
subcomponentes:



Enfermedades
Atención Primaria en Salud
Funcionalidad
Tecnologías en Salud
Página 59 de 88
INTERNACIONALES
“(…) Concepto amplio que incluye todas las actividades, intervenciones, insumos, medicamentos,
dispositivos, servicios y procedimientos usados en la prestación de servicios de salud, así como los
sistemas organizativos y de soporte con los que se presta esta atención en salud.(…)”35
Se tomarán clasificaciones para los siguientes componentes.



Procedimientos en Salud.
Medicamentos.
Dispositivos Médicos.
11.1 Clasificaciones Internacionales para los Servicios Terminológicos en
Salud.
Para cada uno de los componentes de los Servicios terminológicos en salud, se incorporará en el
Lenguaje Común, un estándar internacional. De forma que no solo se alcancen los logros y beneficios
de la Plataforma de Interoperabilidad, sino que también, se logre el suministro de información de
forma ordenada a los diferentes organismos internacionales a los que el Estado Colombiano
pertenece.
Diagnóstico
Para el diagnóstico médico se utilizará el siguiente estándar internacional:
Enfermedades - CIE-10
Es la principal clasificación basada en los parámetros básicos de Salud. Esta clasificación ha sido
preparada por la OMS y aprobada por los miembros rectores de la misma para uso internacional.
los Servicios Terminológicos de Salud
Consideraciones Técnicas
El listado tabular consta de 3 elementos de datos o campos:
Código: (En proceso de definición con el Ministerio de Salud y Protección Social).
Descripción: (En proceso de definición con el Ministerio de Salud y Protección Social).
Reglas de Validación: (En proceso de definición con el Ministerio de Salud y Protección Social).
35
Numeral 24, Art 4, Acuerdo 029 de 2011
Página 60 de 88
INTERNACIONALES
Atención Primaria en Salud - ICPC
(En proceso de definición con el Ministerio de Salud y Protección Social.)
Funcionalidad - CIF
Corresponde a la clasificación internacional de Funcionalidad, Discapacidad y Salud.
Consideraciones Técnicas
(En proceso de definición con el Ministerio de Salud y Protección Social).
11.2 Tecnologías en salud
Para las tecnologías en salud se tendrán en cuenta las siguientes clasificaciones:
Procedimientos en Salud - CUPS
Son las Clasificaciones Únicas de Procedimientos de Salud que “corresponde a un ordenamiento
lógico y detallado de los procedimientos e intervenciones que se realizan en Colombia,
identificados por un código y descritos por una nomenclatura validada por los expertos del país,
independientemente de la profesión o disciplina del sector salud que los realice así como del
ámbito de realización de los mismos36.”
El listado tabular consta de 31 elementos de datos o campos:
Elemento de Dato
Clasificación Única de
Procedimiento en
Salud
Código CUPS
Grupo Código CUPS
Subgrupo Código
CUPS
Categoría Código
CUPS
Subcategoria Código
36
Descripción del elemento de dato
La CLASIFICACIÓN ÚNICA DE PROCEDIMIENTOS EN SALUD (C.U.P.S.) corresponde a
un ordenamiento lógico y detallado de los procedimientos e intervenciones que se
realizan en Colombia, identificados por un código y descritos por una nomenclatura
validada por los expertos del país, independientemente de la profesión o disciplina
del sector salud que los realice así como del ámbito de realización de los mismos.
Identificación de cada uno de las diferentes jerarquías que tiene la Clasificación Única de
Representado por los dos primeros caracteres, del código de la Clasificación Única de
Definido por el tercer carácter del código de la Clasificación Única de Procedimientos en
Salud.
Identificado por el cuarto carácter del código de la Clasificación Única de Procedimientos
en Salud.
Señalado por los dos últimos caracteres del código de la Clasificación Única de
Resolución 1986 de 2001.
Página 61 de 88
INTERNACIONALES
CUPS
Descripción CUPS
Notas de Instrucción
Su contenido aplica tanto al nivel jerárquico (grupo, subgrupo, categoría o
subcategoría) donde se ubique la nota de instrucción como a los que se deriven del
mismo. Es decir si se encuentra en un subgrupo también se aplicará a sus
correspondientes categorías y subcategorías. Están identificadas en letra cursiva y con
un recuadro en el nombre de la nota respectiva.
Esta anotación aparece inmediatamente debajo de un nivel jerárquico para definir
MAS ampliamente, o para dar ejemplos del contenido del nivel, así como citar
algunas causas patológicas por las cuales se realiza el procedimiento.
Incluye
Aclaración Incluye
Código CUPS
Grupo Código CUPS
Subgrupo Código
CUPS
Categoría Código
CUPS
Subcategoría Código
CUPS
Excluye
Aclaración Excluye
Código CUPS
Grupo Código CUPS
Subgrupo Código
CUPS
Categoría Código
CUPS
CUPS
Simultáneo
Aclaración Simultáneo
Código CUPS
Grupo Código CUPS
Subgrupo Código
CUPS
Categoría Código
CUPS
CUPS
Identificación de cada uno de las diferentes jerárquias que tiene la Clasificación Única de
Salud.
en Salud.
Los términos que siguen a la palabra «Excluye» deben codificarse en otra parte (código de
referencia) u omitirse de acuerdo con lo que se indique en cada caso.
Salud.
en Salud.
Esta instrucción se utiliza en la Lista Tabular con dos fines: 1) Como una instrucción para
codificar un procedimiento que se puede realizar de manera independiente (sólo) o
como componente de otro procedimiento cuando ell os se realizan al mismo tiempo.
Salud.
en Salud.
Página 62 de 88
INTERNACIONALES
Con la anterior lista tabular se pretende brindar desde los lineamientos de Lenguaje Común de
intercambio de Información, el mayor soporte técnico a la incorporación de la Clasificación Única de
De igual forma, el anterior listado tabular, no presenta ningún problema de incompatibilidad
conceptual o técnica, que impida un proceso de incorporación mediante adopción.
Medicamentos
Frente a las clasificaciones disponibles para el uso de Medicamentos, aún se encuentra pendiente la
validación de la clasificación que cumpla de forma satisfactoria los requerimientos del Ministerio de
Salud y Protección Social.
Dispositivos Médicos
Frente a las clasificaciones disponibles para el uso de dispositivos médicos, aún se encuentra
pendiente la validación de la clasificación que cumpla de forma satisfactoria los requerimientos
del Ministerio de Salud y Protección Social.
Página 63 de 88
INTERNACIONALES
12.
LINEAMIENTOS PARA LA SELECCIÓN DE ESTÁNDARES
INTERNACIONALES DE INTERCAMBIO DE INFORMACIÓN
S
egún lo expresado anteriormente, la incorporación de estándares internacionales depende de
varios factores ligados a ciertos escenarios. Debido a la flexibilidad que tienen los aspectos
técnicos para incluir un estándar internacional no serían un impedimento y la decisión es
más de carácter administrativo o político.
Las consideraciones más importantes a tener en cuenta son:

Una entidad que ya utiliza el estándar desea que sea incluido en el lenguaje común de

Al hacer un análisis comparativo de algunos de los estándares internacionales, se concluye
que el estándar cumple con las necesidades (tienen una gran cobertura) de un sector o
entidad y en vez de desarrollar un conjunto de elementos, se decide utilizar un estándar
internacional.

Una variación de la primera consideración ocurre cuando una entidad desea intercambiar
información con otra que utiliza el estándar internacional.

El operador del estándar, en su proceso de investigación, propone un estándar internacional
para su incorporación.
Aunque las razones anteriores son válidas para utilizar un estándar internacional, también es
necesario tener en cuenta criterios que en principio garantizarían que el estándar no está en desuso
o será obsoleto en el corto plazo, d ichos aspectos son:

Madurez del estándar internacional: La madurez se puede determinar por medio de la edad
del estándar internacional, un estándar maduro (incluidos los estándares de facto) debe tener
alrededor de un año de revisiones/edad realizadas por el grupo que utiliza o administra el
estándar independientemente vez se tiene un estándar estable, el estándar tiene través del
tiempo.

Actividad del grupo que mantiene el estándar DEBE existir un trabajo de mantenimiento y
evolución del estándar (comprobarse que realmente el estándar es mantenido).

Implementaciones del estándar en el mercado. Si un estándar es implementado y usado en el
mercado, garantiza temporalmente su permanencia y la validez de adopción y adaptación.

Aceptación de la entidad encargada del tipo de información dentro del Estado Colombiano.
Aunque otras entidades utilicen el estándar, si la entidad responsable por la información o
procesos no utiliza el estándar, es recomendable no adoptarlo.
Página 64 de 88
INTERNACIONALES
13.
PROCESO PARA INCLUSIÓN DE ESTÁNDARES
INTERNACIONALES EN LENGUAJE COMÚN DE INTERCAMBIO
DE INFORMACIÓN
Los elementos de los estándares internacionales DEBERÁN ser tratados como elementos de dato del
lenguaje, evitando así un proceso de administración doble.
Para la inclusión de un estándar nuevo, se DEBERÁ llevar el proceso37 de incorporación de
estándares internacionales. A continuación se explicará globalmente las etapas del proceso.


Recepción
validación
: La entidad DEBE
solicitar
operador
de incorporary un
estándar internacional
de forma
total oalparcial
al del estándar la necesidad
Recepción y validación: La entidad DEBE solicitar al operador del estándar la necesidad de
incorporar un estándar internacional de forma total o parcial al lenguaje común de
intercambio de información. A continuación el operador del estándar DEBERÁ proceder a
realizar la revisión de viabilidad como consecuencia de una reunión de levantamiento de
requerimientos con la entidad.
En caso de ser viable la solicitud, el operador DEBE analizar y emitir un concepto de
incorporación, según los lineamientos antes mencionados de selección de estándares en el
capítulo 4 de este documento.
El concepto DEBE ser presentado ante los actores involucrados y de ésta reunión se aprobará
si se incorpora o no el estándar al lenguaje.

Cierre: En esta etapa se procede a realizar las tareas de finalización de la solicitud y
notificación a la entidad del resultado de la aprobación de la incorporación. En caso de que se
incorpore el estándar internacional, el operador lo publicará en el portal del lenguaje y de ésta
manera, los usuario del lenguaje puedan hacer uso de la nueva incorporación del lenguaje.
14.
TERMINOLOGÍA
A lo largo de este documento se utilizan las siguientes definiciones:
Adopción: Se define que un estándar internacional es adoptado cuando se incluye dentro del
lenguaje. La adopción es directa, es decir, sin ningún cambio en su implementación técnica. La
37
GEL-ME-PR-006_Incorp_Estandares_Internacionales_4.1.xls
Página 65 de 88
INTERNACIONALES
adopción puede ser de uno o más elementos de dato del estándar internacional.
Adaptación: Se define que un estándar internacional es adaptado cuando se integra al estándar,
previa la realización de cambios en su especificación. La adaptación puede ser de uno o más
elementos de dato del estándar internacional.
Adaptador: Definición que indica cómo transformar una instancia de un elemento de dato del
estándar a una instancia de elemento de dato de un estándar internacional y viceversa.
Inclusión, Incorporación: Las palabras inclusión e incorporación son indistintamente utilizadas en
este documento. Se define que un estándar internacional es incluido o incorporado dentro del
lenguaje cuando uno o varios de los elementos de dato, de dicho estándar internacional, son
utilizados dentro del lenguaje para el intercambio de información. La inclusión puede ser de uno o
más elementos de dato del estándar internacional.
Localización: Se define localización como las actividades de modificación que se deben realizar a un
elemento de dato de un estándar inter nacional para poder utilizarlo en Colombia. La localización
puede ir desde la creación de la documentación en español del elemento de dato que se desea
localizar hasta una revisión legal pasando por una revisión funcional.
Página 66 de 88
INTERNACIONALES
15.
CONCLUSIONES
L
a principal razón para tomar la decisión de incorporación de un estándar internacional en el
lenguaje para el intercambio de información es que exista un interés real de una entidad en
utilizar dicho están dar y que ese interés cause un efecto de halo que motive a otras entidades a
utilizar el estándar.
La arquitectura de datos del estándar permite la inclusión de estándares internacionales en la capa
Uso Internacional, que a su vez facilitaría el uso y mantenimiento de dicho estándar por los usuarios
del lenguaje y por el operador del mismo.
No necesariamente es posible adaptar o adoptar un estándar internacional en su totalidad, debido a
que algunos estándares internacionales además de definir datos de intercambio definen otros
aspectos del intercambio de datos. En el caso del estándar de WFS, además de los elementos
mínimos para el intercambio de información, se definen otro grupo de elementos asociados al
componente transaccional del estándar, los cuales no serán incluidos, debido al escaso uso de los
mismos, en Colombia. Adicionalmente, la incorporación completa del estándar WFS transaccional,
implicaría la incorporación de métodos para protocolos http, los cuales por ahora no son
conceptualizables dentro del Lenguaje Común de Intercambio de Información.
Al revisar el estándar LegalXML, se observó su incipiente y prácticamente nulo uso en Colombia a
diferencia de los otros dos estándares estudiados (i.e. XBRL y WMS). Por lo que se hace necesario
que exista un actor que impulse el uso y la adopción de dicho estándar internacional. Sin embargo, el
uso de medios electrónicos dentro de la rama Judicial en Colombia no es nuevo, lo cual implica un
menor choque en la apropiación de estándares de intercambio.
Para crear nuevos elementos de dato dentro del lenguaje desde cero, se debe recorrer un camino,
invirtiendo recursos y tiempo en la ejecución de dicho proceso. Los estándares internacionales ya
tienen un camino recorrido y una base sólida probada que al adoptarlos o adaptarlos permitiría el
enriquecimiento del lenguaje común para el intercambio de información, por lo que se hace necesario
el estudio y adopción de los mismos.
Página 67 de 88
INTERNACIONALES
16.
TRABAJO FUTURO
Los cambios en los estándares se están dando permanentemente, debido a esto es importante
analizar continuamente las nuevas tendencias para incorporarlas dentro del lenguaje.
La estructura de XBRL, que relaciona la información de conceptos con la forma de representarla es
un ejemplo palpable del aprovechamiento de las capacidades de XML que podría utilizarse en el
lenguaje.
En cuanto a los Servicios Terminológicos en Salud una vez aprobados por parte del Ministerio de
Salud los elementos de dato conceptualizados, se incorporaran los elementos al estándar para
ponerlos a disposición a las entidades del sector. Se tiene planeado incluir dentro de los Servicios
Terminológicos el ICPC (International Classification of Primary Care) el cual está enfocado a la
atención primaria en Salud.
Además del enfoque tecnológico del intercambio de información, se deben tener en cuenta los
aspectos administrativos y políticos, en donde se toman las decisiones de intercambiar la
información y donde nace la necesidad del intercambio. Se deberían analizar los convenios
internacionales que Colombia tiene, en donde aplique el intercambio de información, y analizar qué
estándares de intercambio se podrían utilizar, incorporarlos al lenguaje común de intercambio de
información y así facilitar el uso y darle mayor visibilidad al lenguaje común para el intercambio de
información.
Página 68 de 88
INTERNACIONALES
17.
APENDICES
17.1 APÉNDICE A: PALABRAS CLAVES A UTILIZAR PARA INDICAR NIVELES
DE REQUERIMIENTO (RFC 2119).
Palabras clave a utilizar para indicar niveles de requerimiento (RFC 2119). Versión original en Inglés
en http://www.faqs.org/rfcs/rfc2119.html.
Network Working Group
Request for Comments: 2119
BCP: 14
Categoría:
S.Bradner
Harvard University
Marzo 1997
Mejor Práctica Actual
ESTATUS DE ESTE MEMORANDUM:
Este documento especifica una Mejor Práctica Actual de Internet para la comunidad
Internet, y solicita su discusión y sugerencias para posibles mejoras. La distribución de este
memorándum es ilimitada.
RESUMEN:
En muchos documentos de seguimiento estándar se usa n varias palabras para indicar los
requerimientos de la especificación. Estas palabras a menudo están en mayúsculas. Este
documento define cómo deberían ser interpretadas estas palabras en documentos IETF.
Los autores que sigan estas instrucciones deberían incorporar esta frase cerca del principio
de sus documentos:
Las palabras claves "DEBE", "NO DEBE", "REQUERIDO" |"OBLIGATORIO", "DEBERÁ", "NO
DEBERÁ", "DEBERÍA", "NO DEBERÍA", "RECOMENDADO", "PUEDE" y "OPCIONAL" en este
documento serán interpretadas como se describe en RFC 2119.
Nótese que la contundencia de estas palabras está modificada por el nivel de requerimiento
del documento en el que son usadas.
1. DEBE: Esta palabra, o los términos "REQUERIDO"|"OBLIGATORIO" o "DEBERÁ", significa
que la definición es un requerimiento insoslayable de la especificación.
2. NO DEBE: Esta frase, o la frase "NO DEBERÁ", significa que la definición es una prohibición
insoslayable de la especificación.
3. DEBERÁ: Esta palabra, o el adjetivo "RECOMENDADO ", significa que pueden existir razones
válidas en determinadas circunstancias para ignorar un elemento determinado, pero que la
totalidad de las consecuencias deben ser comprendidas y cuidadosamente sopesadas antes
Página 69 de 88
INTERNACIONALES
de elegir otros derroteros.
4. NO DEBERÁ: Esta frase, o la frase "NO RECOMENDAD O", significa que pueden existir razones
válidas en determinadas circunstancias en las que el comportamiento en particular sea útil o
incluso aconsejable, pero que la totalidad de las consecuencias deben ser comprendidas y
cuidadosamente sopesadas antes de implementar cualquier comportamiento descrito bajo
esta etiqueta.
5. PUEDE: Esta palabra, o el adjetivo "OPCIONAL", significa que un elemento es realmente
opcional. Un proveedor puede elegir incluir el elemento porque un mercado en particular lo
necesite o porque el proveedor sienta que realza el producto aunque otro proveedor pueda
omitir el mismo elemento. Una implementación que no incluya una opción determinada DEBE
estar preparada para interoperar con otra implementación que incluya la opción, aunque quizá
con reducida funcionalidad. En el mismo orden de cosas, una implementación que incluya una
opción en particular DEBE estar preparada para interoperar con otra implementación que no
incluya la opción (excepto, por supuesto, para la característica que aporte la opción).
6. Guía de uso de estos Imperativos: Los imperativos del tipo definido en este memorando
deben ser usados con cuidado y con mesura. En particular, sólo DEBEN ser utilizados donde
sea realmente necesario para la interoperación o para limitar un comportamiento
potencialmente dañino (p.ej., limitando retransmisiones). Por ejemplo, no deben ser usados
para intentar imponer un método concreto a los implementadores cuando el método no sea
necesario para la interoperabilidad.
7. Consideraciones de seguridad: Estos términos se utilizan normalmente para especificar
comportamientos con implicaciones de seguridad. Los efectos sobre la seguridad de no
implementar un DEBE o DEBERÍA, o hacer algo que la especificación dice NO DEBE o NO
DEBERÍA ser hecho, pueden ser muy sutiles. Los autores de documentos deberían tomarse su
tiempo para elaborar las implicaciones de seguridad respecto a no seguir recomendaciones o
requerimientos, ya que la mayoría de los implementadores no tienen el beneficio de la
experiencia y de la discusión que produjo la especificación.
8. Agradecimientos: Las definiciones de estos términos son una amalgama de las definiciones
tomadas de numerosos documentos RFC. Además, se han incorporado sugerencias de
numerosas personas incluyendo a Robert Ullmann, Thomas Nartenm Neal McBurnett, y
Robert Elz.
DIRECCIÓN DEL AUTOR:
Scott Bradner Harvard University 1350 Mass. Ave. Cambridge, MA 02138 phone - +1
617 495 3864
email - [email protected]
Traducción: José M. Cainzos [email protected] SEVILLA –SPAIN
Página 70 de 88
INTERNACIONALES
17.2 EXTRACTO DE LEGAL-XML
El siguiente extracto de LEGAL-XML corresponde a un documento de tipo
SignatureProfileIdentifier.
CoreFilingMessage
xmlns="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:CoreFilingMessage-3.0"
xmlns:nullsig="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:NullSignature-1.0"
xmlns:document="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:DocumentType-3.0">
... (content removed for brevity)
<FilingLeadDocument>
<document:ExtendedDocumentDescriptiveMetadata>
<document:DocumentSignature>
<document:SignatureProfileIdentifier> urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:NullSignature-1.0
</document:SignatureProfileIdentifier>
<document:Signature>
<nullsig:Signatures/>
</document:Signature>
</document:DocumentSignature>
</document:ExtendedDocumentDescriptiveMetadata>
</FilingLeadDocument>
</CoreFilingMessage>
17.3 EXTRACTO DE HL7
Ejemplo de un documento clínico (CDA) en HL7.
Página 71 de 88
INTERNACIONALES
<?xml version="1.0"?>
<!DOCTYPE levelone PUBLIC "-//HL7//DTD CDA Level One 1.0//EN" "levelone_1.0.dtd">
<levelone>
<clinical_document_header>
<id EX="a123" RT="2.16.840.1.113883.3.933"/>
<set_id EX="B" RT="2.16.840.1.113883.3.933"/>
<version_nbr V="2"/>
<document_type_cd V="11488-4" S="2.16.840.1.113883.6.1" DN="Consultation note"/>
<origination_dttm V="2000-04-07"/>
<confidentiality_cd ID="CONF1" V="N" S="2.16.840.1.113883.5.1xxx"/>
<confidentiality_cd ID="CONF2" V="R" S="2.16.840.1.113883.5.1xxx"/>
<document_relationship>
<document_relationship.type_cd V="RPLC"/>
<related_document>
<id EX="a234" RT="2.16.840.1.113883.3.933"/>
<set_id EX="B" RT="2.16.840.1.113883.3.933"/>
<version_nbr V="1"/>
</related_document>
</document_relationship>
<fulfills_order>
<fulfills_order.type_cd V="FLFS"/>
<order><id EX="x23ABC" RT="2.16.840.1.113883.3.933"/></order>
<order><id EX="x42CDE" RT="2.16.840.1.113883.3.933"/></order>
</fulfills_order>
<patient_encounter>
<id EX="KPENC1332" RT="2.16.840.1.113883.3.933"/>
<practice_setting_cd V="GIM" S="2.16.840.1.113883.5.1xxx" DN="General internal medicine clinic"/>
<encounter_tmr V="2000-04-07"/>
<service_location>
<id EX="KXLPa123" RT="2.16.840.1.113883.3.933"/>
<addr>
<HNR V="970"/>
<STR V="Post St"/>
<DIR V="NE"/>
<CTY V="Alameda"/>
<STA V="CA"/>
<ZIP V="94501"/>
</addr>
</service_location>
</patient_encounter>
(…)
<item>
<content>Decrease prednisone to 20qOD alternating with 18qOD.</content>
</item>
<item><content>Hydrocortisone cream to finger BID.</content></item>
<item><content>RTC 1 week.</content></item>
</list>
</section>
</body>
</levelone>
17.4
EXTRACTO DE XBRL
Ejemplo de un esquema de XBRL.
Página 72 de 88
INTERNACIONALES
<numericContext id="rg.cy00.hkd" cwa="false" precision="4">
<entity>
<identifier scheme='http://www.gov.hk'>rg</identifier>
</entity>
<period>
<startDate>2000-01-01</startDate>
<endDate>2000-12-31</endDate>
</period>
<unit>
<measure>iso4217:hkd</measure>
</unit>
</numericContext>
Instancia de un elemento del esquema anterior
<?xml version="1.0" encoding="UTF-8"?>
<gaap:opc numericContext="rg.cy01.hkd">-3583000000.</gaap:opc>
Página 73 de 88
INTERNACIONALES
18.
ANEXOS
18.1 ELEMENTOS DE DATO DE WMS
Elemento de Dato
WMS_Capabilities
Service
Tipo de Dato
Compuesto
Compuesto
Name
Simple
Title
Simple
Abstract
Simple
KeywordList
Simple
OnlineResource
Simple
ContactInformation
Simple
Fees
Simple
Descripción
Provee
información
de las posibilidades
que un servicio ofrece
a un usuario a través
de un conjunto de
interfaces.
Incluye
versión del tipo de
servicio
Ejemplo:
1.1.1
Computación
realizada por una
entidad software en
un lado de una
interfaz en respuesta
a una petición hecha
por
otra
entidad
software en el otro
lado de la interfaz.
Cadena
de
texto
usada
para
la
comunicación
máquina-máquina.
Nombre con el cual
se
conoce
el
producto.
Descripción
corta
sobre el contenido del
producto.
Lista de palabra(s) o
frase(s)
usada(s)
para
describir
aspectos del conjunto
de datos.
Dirección electrónica
de donde se puede
obtener el conjunto
de datos con la
trayectoria, nombre y
extensión del archivo
servicio, p.e un URL
Identificación sobre el
individuo
u
organización,
asociados al servicio.
Información
sobre
costos. Se usa la
palabra
reservada
"none" si no existen
costos asociados al
uso del servicio.
Página 74 de 88
Fuente
NTC 4611 SA
Traducción ISO 19119
Traducción WMS 1.3.0 spec. sec. 7.2.4.2
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
Traducción WMS 1.1.1 spec. sec 7.1.4.2
INTERNACIONALES
AccessConstraints
Simple
LayerLimit
Simple
MaxWidth
Simple
MaxHeight
Simple
Capability
Compuesto
Request
Compuesto
GetCapabilities
Format
Simple
Simple
Restricciones
que
aseguran
la
protección
de
la
privacidad
o
propiedad intelectual
o
limitaciones
especiales
en
el
acceso al servicio.
Máximo número de
capas que un cliente
WMS puede solicitar
al servicio en una
petición GetMap.
Entero positivo que
indica el máximo
valor de anchura que
un cliente se permite
incluir en una sola
petición GetMap.
Entero positivo que
indica el máximo
valor de altura que un
cliente se permite
incluir en una sola
petición GetMap.
El
elemento
<Capability>
del
metadato del servicio
nombra
las
operaciones
soportadas por el
mismo, los formatos
de salida ofrecidos
por
dichas
operaciones, y el
prefijo URL para cada
operación.
Invocación de una
operación por medio
de un cliente.
El propósito de la
operación obligatoria
GetCapabilities
es
obtener el metadato
del servicio, el cual es
una descripción del
contenido
de
la
información
del
servicio, legible para
una máquina (y para
una persona), y con
valores
aceptables
para la solicitud de
parámetros.
Descripción
del
formato
que
especifica
la
distribución de los
datos en un registro,
archivo,
mensaje,
dispositivo
de
almacenamiento
o
canal de transmisión.
Página 75 de 88
NTC 4611 SA
Traducción WMS 1.3.0 spec. sec 4.10
Traducción WMS 1.3.0 spec. sec 7.2.1
NTC 4611 SA
INTERNACIONALES
DCPType
HTTP
Get
OnlineResource
Post
OnlineResource
GetMap
Simple
Tipo de Plataforma de Glosario
OGC
Computación
http://www.opengeospatial.org/ogc/glossary/
Distribuida
d
Simple
Protocolo
de
Transferencia
de
Hipertexto (Hypertext
Transfer Protocol). Es
un protocolo utilizado
para la transferencia
de datos a través de
Internet, y que está
basado
en
operaciones sencillas
de
solicitud
y
respuesta.
Un
servicio
WMS
soportará el método
"GET" del protocolo
HTTP. (IETF RFC
2616).
de donde se puede
obtener el conjunto
de datos con la
Un
servicio
WMS
"POST" del protocolo
HTTP. (IETF RFC
2616).
de donde se puede
obtener el conjunto
de datos con la
La operación GetMap
devuelve
como
respuesta un mapa.
Al recibir una petición
GetMap, un servicio
WMS deberá generar
una respuesta o una
excepción de servicio.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
Tipo de Plataforma de
Computación
Distribuida
Compuesto
Simple
Compuesto
Simple
Compuesto
Format
Simple
DCPType
Simple
Página 76 de 88
Glosario
http://www.w3c.es/divulgacion/a-z/#h
W3C
NTC 4611 SA
NTC 4611 SA
Traducción WMS 1.3.0 spec. sec 7.3.1.
NTC 4611 SA
Glosario
OGC
d
INTERNACIONALES
HTTP
Get
OnlineResource
Post
OnlineResource
GetFeatureInfo
Simple
Compuesto
Simple
Compuesto
Simple
Compuesto
Format
Simple
DCPType
Simple
Protocolo
de
Transferencia
de
basado
en
de
solicitud
y
respuesta.
Un
servicio
WMS
"GET" del protocolo
HTTP. (IETF RFC
2616).
de donde se puede
obtener el conjunto
de datos con la
Un
servicio
WMS
HTTP. (IETF RFC
2616).
de donde se puede
obtener el conjunto
de datos con la
GetFeatureInfo
es
una
operación
opcional. Solo es
soportada en aquellas
capas en las cuales el
atributo "queryable"
ha sido definido o
heredado, y aparece
como queryable="1"
(verdadero).
Devuelve
datos
asociados a la capa
solicitada
en
la
petición.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
Tipo de Plataforma de
Computación
Distribuida
Página 77 de 88
Glosario
W3C
NTC 4611 SA
NTC 4611 SA
Traducción WMS 1.3.0 spec. sec 7.4.1.
NTC 4611 SA
Glosario
OGC
d
INTERNACIONALES
HTTP
Get
OnlineResource
Post
OnlineResource
Exception
Format
Simple
Compuesto
Simple
Compuesto
Simple
Compuesto
Simple
_ExtendedCapabilities
Simple
Layer
Compuesto
Protocolo
de
Transferencia
de
basado
en
de
solicitud
y
respuesta.
Un
servicio
WMS
"GET" del protocolo
HTTP. (IETF RFC
2616).
de donde se puede
obtener el conjunto
de datos con la
Un
servicio
WMS
HTTP. (IETF RFC
2616).
de donde se puede
obtener el conjunto
de datos con la
Establece el (los)
formato(s) en el (los)
cual(es) se reportan
los errores.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
Las
extensiones
pueden ser definidas
dentro
de
una
comunidad
de
información cuando
se necesitan para
proporcionar
funcionalidades
o
especializaciones
adicionales.
Unidad básica de
información
geográfica que se
puede solicitar como
Página 78 de 88
Glosario
W3C
NTC 4611 SA
NTC 4611 SA
Traducción WMS 1.3.0 spec. sec 6.9.4 y 6.11
NTC 4611 SA
INTERNACIONALES
un
mapa
servidor.
Name
Simple
Title
Simple
Abstract
Simple
KeywordList
Simple
CRS
Simple
EX_GeographicBoundingBox
Compuesto
a
un
Cadena
de
texto
usada
para
la
comunicación
máquina-máquina.
Nombre con el cual
se
conoce
el
producto.
Descripción
corta
sobre el contenido del
producto.
Lista de palabra(s) o
frase(s)
usada(s)
para
describir
aspectos del conjunto
de datos.
Sistema
de
coordenadas
relacionado con el
mundo real por medio
de un dátum.
Define a través de los
elementos
westBoundLongitude,
eastBoundLongitude,
southBoundLatitude,
y
northBoundLatitude,
el mínimo rectángulo
delimitador en grados
decimales del área
cubierta por la capa
geográfica.
Representa
la
longitud occidental de
la capa.
Representa
la
longitud oriental de la
capa.
Representa la latitud
sur de la capa.
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
Traducción WMS 1.3.0 spec. sec 7.2.4.6.6
westBoundLongitude
Simple
eastBoundLongitude
Simple
southBoundLatitude
Simple
northBoundLatitude
Simple
Representa la latitud Traducción WMS 1.3.0 spec. sec 7.2.4.6.6
norte de la capa.
BoundingBox
Simple
Style
Simple
Name
Simple
Title
Simple
Especifica el área de
la capa que será
dibujada.
Los
estilos
porporcionan a la
cartografía, a partir
de tipos, propiedades
y restricciones de
objetos
Cadena
de
texto
usada
para
la
comunicación
máquina-máquina.
Nombre con el cual
se
conoce
el
producto.
Página 79 de 88
Glosario
OGC
http://www.opengeospatial.org/ogc/glossary/s
NTC 4611 SA
INTERNACIONALES
LegendURL
Compuesto
Format
Simple
OnlineResource
Simple
StyleSheetURL
Compuesto
Format
Simple
OnlineResource
Simple
StyleURL
Compuesto
Format
Simple
OnlineResource
Simple
Contiene la ubicación
de la imagen de la
simbología apropiada
para
el
estilo
asociado.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
de donde se puede
obtener el conjunto
de datos con la
Proporciona
información de la
simbología para cada
estilo de la capa.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
de donde se puede
obtener el conjunto
de datos con la
Un servidor de mapas
puede
usar
el
elemento
StyleURL
para ofrecer más
información sobre el
dato o la simbología
asociada a un estilo
particular.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
de donde se puede
obtener el conjunto
de datos con la
Página 80 de 88
Traducción WMS 1.3.0 spec. sec. 7.2.4.6.5
NTC 4611 SA
NTC 4611 SA
Traducción WMS 1.3.0 spec. Annex E
NTC 4611 SA
NTC 4611 SA
Traducción WMS 1.3.0 spec. Annex E
NTC 4611 SA
NTC 4611 SA
INTERNACIONALES
MinScaleDenominator
Simple
MaxScaleDenominator
Simple
Dimension
Simple
MetadataURL
Compuesto
Format
Simple
OnlineResource
Simple
Define el rango de
escalas para el cual
es apropiado generar
el mapa de la capa.
La
ausencia
del
elemento
MinScaleDenominator
significa que no existe
un término de escala
mínimo
para
establecer
la
condición,
o
lógicamente, que el
valor por defecto es
cero.
Define el rango de
escalas para el cual
es apropiado generar
el mapa de la capa.
La
ausencia
del
elemenro
MaxScaleDenominato
r significa que no
existe un término de
escala máximo para
establecer
la
condición,
o,
lógicamente, que el
valor por defecto es
infinito.
Especifica elementos
propios
de
un
metadato para datos
multidimensionales.
Un servidor usa uno o
más
elementos
<MetadataURL> para
ofrecer un metadato
detallado
y
estandarizado sobre
el
dato
correspondiente
a
una capa particular.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
de donde se puede
obtener el conjunto
de datos con la
Página 81 de 88
NTC 4611 SA
NTC 4611 SA
INTERNACIONALES
Attribution
Simple
Title
Simple
OnlineResource
Simple
LogoURL
Compuesto
Format
Simple
OnlineResource
Simple
Identifier
Simple
Authority URL
Compuesto
OnlineResource
Simple
Proporciona
una
forma de identificar la
fuente de información
geográfica usada en
una capa.
Nombre con el cual
se
conoce
el
producto.
de donde se puede
obtener el conjunto
de datos con la
URL de la imagen
logo que representa
la
fuente
de
información
geográfica.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
de donde se puede
obtener el conjunto
de datos con la
Lista los números o
etiquetas ID definidos
para una autoridad
particular.
El
contenido de texto
del
elemento
Identifier es el valor
ID.
El
atributo
de
autoridad
del
elemento
Identificador
corresponde
al
atributo de nombre
de un sólo elemento
<AuthorityURL>.
AuthorityURL incluye
un
elemento
<OnlineResource>, el
cual define la URL de
un documento que
define el significado
de los valores del
elemento Identifier.
de donde se puede
obtener el conjunto
Página 82 de 88
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
INTERNACIONALES
FeatureListURL
Compuesto
Format
Simple
OnlineResource
Simple
DataURL
Compuesto
Format
Simple
OnlineResource
Simple
de datos con la
Hace referencia a una
lista
de
objetos
geográficos
representados en una
capa.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
de donde se puede
obtener el conjunto
de datos con la
Ofrece un enlace a
los datos que son
representados
por
una capa particular.
Descripción
del
formato
que
especifica
la
archivo,
mensaje,
dispositivo
de
almacenamiento
o
de donde se puede
obtener el conjunto
de datos con la
Página 83 de 88
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
INTERNACIONALES
18.2 ELEMENTOS DE DATO DE WFS
Elemento de dato
WFS Capabilities
ServiceIdentification
Tipo de Dato
Compuesto
Compuesto
Title
Simple
Abstract
Simple
Keywords
Keyword
Type
Compuesto
Simple
Compuesto
ServiceType
Simple
ServiceTypeVersion
Simple
Descripcion
Fuente
Provee información
de las posibilidades
que
un
servicio
ofrece a un usuario a
través
de
un
conjunto
de
interfaces.
Incluye
versión del tipo de
servicio
Ejemplo:
1.1.0
La
sección
de
identificación
del
servicio poporciona
información
del
servicio WFS como
tal,
como
está
definido
en
la
Especificación
de
Implementación
Común
OWS,
cláusula 7.4.3
Título de fácil lectura
para
identificar
brevemente
un
elemento (servicio,
objeto, objeto GML)
Narrativa descriptiva
para
más
información sobre el
elemento (servicio,
objeto, objeto GML)
Lista de palabras
cortas para ayudar
en búsquedas de
catálogo.
Palabra corta para
ayudar
en
búsquedas
de
catálogo.
Palabra(s) o frase(s)
usada(s)
para
describir
aspectos
del
conjunto
de
datos.
Nombre con el cual
se conoce el tipo de
servicio desde un
servicio de registro.
Versión del tipo de
servicio
Ejemplo:
OGC WFS 1.1.0
NTC 4611 SA
Página 84 de 88
Traducción WFS 1.1.0 spec. sec.
13.3.2
13.3.3
13.3.3
13.3.3
13.3.3
NTC 4611 SA
NTC 4611 SA
NTC 4611 SA
INTERNACIONALES
Fees
Simple
AccessConstraints
Simple
ServiceProvider
Compuesto
ProviderName
Simple
ServiceContact
Simple
OperationsMetadata
Operation
DCP
Compuesto
Compuesto
Compuesto
Precio y términos
para
obtener
el
conjunto de datos.
Restricciones
que
aseguran
la
protección de la
privacidad
o
propiedad intelectual
o
limitaciones
especiales
en
el
acceso al servicio.
La
sección
de
proveedor
del
servicio proporciona
el metadato de la
organización
que
opera el servicio
WFS tal y como se
define
en
la
Especificación
de
Implementación
Común
OWS,
cláusula 7.4.4.
Identificador único
para la organización
proveedora
del
servicio.
Información
para
contactar
al
proveedor
del
servicio.
La
sección
OperationsMetadata
proporciona
metadatos sobre las
operaciones
definidas
en
la
especificación
e
implementación de
un servicio WFS
particular.
El
contenido
de
la
sección está definido
en la Especificación
de Implementación
Común OWS 7.4.5.
Este
metadato
incluye
DCP,
parámetros
y
restricciones
para
cada operación.
Identificador único
para la operación.
Soportadas por el
sevicio o por el
objeto.
Tipo de Plataforma
de
Computación
Distribuida
Página 85 de 88
NTC 4611 SA
NTC 4611 SA
13.3.2
Esquema ows.xsd
Esquema ows.xsd
13.3.2
NTC 4611 SA
Glosario
OGC
http://www.opengeospatial.org/ogc/gl
ossary/d
INTERNACIONALES
HTTP
Simple
Get
Simple
Post
Simple
Parameter
Simple
Value
Simple
FeatureTypeList
Compuesto
Protocolo
de
Transferencia
de
Hipertexto
(Hypertext Transfer
Protocol).
Es
un
protocolo
utilizado
basado
en
de
solicitud
y
respuesta.
Un servicio WMS
"GET" del protocolo
HTTP. (IETF RFC
2616).
de donde se puede
obtener el conjunto
de datos con la
trayectoria, nombre
y
extensión
del
archivo servicio, p.e
un URL
Lista en desorden de
dominios válidos de
parámetros
para
cada
petición
u
operación.
Lista de valores para
determinado
servicio, operación o
parámetro.
Esta sección define
una lista de tipos de
objeto
(y
operaciones
para
cada tipo de objeto)
que se encuentran
disponibles en el
servicio de objetos
geográficos.
Información
adicional como el
sistema
de
referencia espacial,
otros sistemas de
referencia
soportados, o la no
existencia
de
sistemas
de
referencia
para
peticiones WFS son
proporcionadas para
cada tipo de objeto.
Página 86 de 88
Glosario
W3C
http://www.w3c.es/divulgacion/az/#h
NTC 4611 SA
Esquema ows.xsd
Esquema ows.xsd
13.3.2
INTERNACIONALES
FeatureType
Compuesto
Name
Simple
DefaultSRS
Simple
OutputFormats
Simple
WGS84BoundingBox
Simple
Abstracción
simplificada de un
fenómeno
o
elemento del mundo
real asociado a una
localización relativa
sobre la superficie
terrestre y a un
tiempo determinado.
El nombre del tipo
de elemento (objeto,
objeto
GML)
presente
en
el
espacio
de
nombres.Elemento
obligatorio.
Este elemento indica
cual
sistema
de
referencia
debe
usarse por el WFS
para expresar el
estado el objeto
espacial, si no se
identifica
explícitamente
dentro
de
una
petición de consulta
o
transacción….El
SRS puede indicarse
usando el formato
EPSG, o el formato
URL definido en la
subcláusula 4.3.2 de
referencia.
Lista de tipos MIME
que
indican
los
formatos de salida
en los que puede
generarse un tipo de
objeto. Si no se
especifica
aquí
ningún
parámetro,
los
formatos
se
asumen de la lista de
la
operación
GetFeature.
Usado para indicar
los
límites
del
rectángulo
que
engloba una zona,
en grados decimales
de latitud y longitud
en
WGS84.
Su
propósito es facilitar
las
búsquedas
geográficas,
indicando dónde se
encuentran
las
instancias específicas
del tipo de objeto.
(…)
Página 87 de 88
NTC 4611 SA
13.3.3
13.3.3
13.3.3
13.3.3
INTERNACIONALES
ServesGMLObjectTypeList
Simple
SupportsGMLObjectTypeList
Simple
Filter Capabilities
Simple
Objeto
GML,
no
derivados
de
gml:AbstractFeature
Type, que están
disponibles en un
servicio de objetos
geográficos
que
soportan
la
operación
GetGMLObject. Estos
tipos pueden estár
definidos
en
un
esquema GML, o en
un
esquema
de
aplicación,
usando
su propio espacio de
nombres.
objetos GML que un
servidor WFS sería
capaz de disponer si
fueran desplegados
para servir datos tal
y como se describen
en un esquema de
aplicación que, o
bien
utiliza
esos
tipos de objetos GML
directamente (para
tipos no abstractos),
o tipos definidos
derivados
basados
en esos tipos.
El esquema de la
sección
Filter
Capabilities
está
definido
en
la
Especificación para
la
Implementación
Filter Encoding. Esta
es
una
sección
opcional. Si existe,
entonces el servicio
WFS soportará las
operaciones
descritas
en
el
mismo.Si la sección
no está definida,
entonces el cliente
deberá asumir que el
servidor sólo soporta
el
mínimo
de
operaciones
por
defecto, tal y como
están definidas en la
Especificación
de
Implementación
Filter Encoding.
Página 88 de 88
13.3.2
13.3.2
13.3.2

1.309,2k - Lenguaje común para intercambio de información

Transcripción

Documentos relacionados

Instrucciones para visualizar mapas WMS en Google Earth

Haz crecer tu negocio con nuestro rentable, eficiente e

Tabla de Contenido

• Vea el reverso para la traducción española •