NORMA ISO 19135

Resumen

RESUMEN DE NORMA ISO 19135 INFORMACIN GEOGRFICA - PROCEDIMIENTOS PARA EL REGISTRO DE TEMS

Esta norma internacional especifica los procedimientos para el registro de tems de informacin geogrfica. Para proveer de identificacin y significado a los tems registrados, y para gestionar el registro de estos tems, especifica los elementos de informacin que son indispensables. El registro de los tems de informacin geogrfica, favorece a los usuarios de informacin geogrfica, ya que provee un reconocimiento internacional al hecho de que tales tems se ajusten a una norma ISO. Los tems de informacin geogrfica que se pueden registrar son tems de clases de objetos especificados en normas tcnicas tales como las desarrolladas por ISO/TC 211. Una organizacin autorizada por ISO para mantener un registro es la autoridad registradora, a la cual esta norma reconoce, desde que est orientada a lograr un equilibrio entre minimizar el nmero de registros de tems de informacin geogrfica y minimizar la carga sobre las autoridades registradoras. La norma de referencia define los roles y las responsabilidades en la gestin del registro llevada a cabo por diversas organizaciones, distinguiendo principalmente los correspondientes al propietario del registro, administrador del registro, organizaciones remitentes, organismos de control y usuarios. Adems, presenta diversas alternativas para estructurar los registros y subregistros de tems, y la informacin que deben presentar las propuestas para el registro de dichos tems.

Octubre de 2009

Interpretacin de lo establecido en

NORMA ISO 19135 Procedimientos para el Registro de tems

ISO 19135
Informacin Geogrfica - Procedimientos para el registro de tems
NDICE

Contenido 1. Alcance ... 2. Conformidad 3. Normas de referencia .. 4. Trminos, definiciones y abreviaturas .. 5. Roles y responsabilidades en la gestin de registros .. 5.1. Introduccin .. 5.2. Propietario del registro 5.3. Administrador del registro .. 5.4. Organizaciones remitentes . 5.5. Organismo de control .. 5.6. Administrador del sistema del registro . 5.7. Usuario del registro . 6. Gestin de registros .. 6.1. Establecimiento de registros . 6.2. Procesamiento de propuestas 6.3. Lista de organizaciones remitentes .. 6.4. Publicacin 6.5. Integridad .. 6.6. Propuestas de registro 7. Algunos principios de registro .. 7.1. Estructuras alternativas de registro ... 7.2. Identificacin de tems del registro 7.3. Definicin de los tems de un registro ... 7.4. Adaptabilidad cultural y lingstica .... 7.5. Estado de los tems del registro . 7.6. Estado del registro ... 8. Esquema del registro ...... 8.1. Introduccin ...... 8.2. RE_Register (registro) .... 8.3. RE_RegisterOwner (propietario del registro) .. 8.4. RE_RegisterManager (Administrador del registro)

Pgina 4 4 4 5 8 8 8 9 10 10 11 11 12 12 12 19 19 20 20 20 20 22 23 25 25 26 27 27 28 31 32

Octubre de 2009

Contenido 8.5. RE_SubmittingOrganization (organizacin remitente) 8.6. RE_ItemClass (clase de tem) .. 8.7. RE_ReferenceSource (fuente de referencia) 8.8. RE_RegisterItem (tem del registro) .. 8.9. RE_ProposalManagementInformation (informacin de gestin de propuesta) 8.10. RE_AdditionInformation (informacin de adicin) .. 8.11. RE_ClarificationInformation (informacin de aclaracin) .. 8.12. RE_AmendmentInformation (informacin de correccin) . 8.13. RE_Reference (referencia) . 8.14. RE_SubregisterDescription . 8.15. RE_AlternativeExpression (expresin alternativa) . 8.16. RE_AlternativeName (nombre alternativo) 8.17. RE_Locale (escenario) 8.18. RE_Version (versin) 8.19. RE_FieldOfApplication (campo de aplicacin) 8.20. RE_ItemStatus (estado del tem) .. 8.21. RE_DecisionStatus (estado de la decisin) .. 8.22. RE_Disposition (situacin) ... 8.23. RE_AmendmentType (tipo de modificacin) . 8.24. RE_SimilarityToSource (similitud con la fuente) .. Anexo A (Normativo) Conjunto de pruebas genricas .. A.1. Conformidad general... A.2. Registros jerrquicos A.3. Registros establecidos por ISO/TC 211 .. Anexo B (Informativo) Notacin UML B.1. Introduccin B.2. Clase.. B.3. Estereotipo B.4. Atributo.. B.5. Asociacin. B.6. Nombre del rol . B.7. Navegabilidad.. B.8. Agregacin .. B.9. Composicin B.10. Multiplicidad .. B.11. Generalizacin .. B.12. Elementos derivados

Pgina 34 36 37 38 44 47 47 48 48 51 52 54 54 55 56 57 57 57 58 58 60 60 61 62 63 63 63 63 64 65 66 66 66 66 67 67 68

Octubre de 2009

Contenido B.13. Nota ..... B.14. Restriccin .. Anexo C (Normativo) Establecimiento de registros por parte del Comit Tcnico de ISO/TC 211 .. C.1. Introduccin .. C.2. Designacin de un administrador del registro ISO/TC 211.. C.3. Calificacin de un administrador de registro ISO/TC 211.... C.4. Responsabilidades de un administrador de registro ISO/TC 211 ... C.5. Contrato .... C.6. Organizaciones remitentes C.7. Organismos de control C.8. Apelaciones Anexo D (Normativo) Informacin que debe incluirse en las propuestas para el registro de tems . D.1. Elementos de informacin requeridos para todas las propuestas D.2. Elementos de informacin adicional para propuestas de aadir tems nuevos al registro .. D.3. Elementos de informacin requeridos en las propuestas para reemplazar un tem registrado .. D.4. Elementos de informacin adicionales de propuestas para retirar un tem registrado . Bibliografa.

Pgina 68 68 70 70 70 70 71 71 72 73 73 74 74 74 75 75 78

Octubre de 2009

Informacin Geogrfica - Procedimientos para el registro de tems

1. Alcance La presente norma especifica los procedimientos a seguir para establecer, mantener y publicar registros de identificadores nicos, inequvocos y permanentes, y los significados asignados a los tems geogrficos. A los efectos de cumplir con dicho objetivo, esta norma especifica los elementos de informacin imprescindibles para proveer identificacin y significado a los tems registrados, y adems, para gestionar el registro de estos tems. 2. Conformidad 2.1. Introduccin Para concordar con esta norma, un registro de tems geogrficos debe satisfacer todas las condiciones definidas para una de las clases de conformidad que se detallan a continuacin. 2.2. Conformidad general Cualquier registro que requiera la conformidad con esta norma internacional debe cumplir con todas las condiciones del conjunto de pruebas genricas especificadas para la conformidad general (apartado A.1.). 2.3. Registros jerrquicos Cualquier registro jerrquico que declare concordar con esta norma debe cumplir con todas las condiciones del conjunto de pruebas genricas especificadas para la conformidad general (apartado A.1) y debe, adems, satisfacer los requerimientos del conjunto de pruebas genricas especificadas para registros jerrquicos (apartado A.2). 2.4. Registros establecidos por ISO/TC 211 Un registro establecido por ISO/TC 211 debe cumplir con la totalidad de las condiciones del conjunto de pruebas genricas especificadas para la conformidad general (apartado A.1) y adems, debe satisfacer todas las condiciones del conjunto de pruebas genricas especificadas para registros establecidos por ISO/TC 211 (apartado A.3). 3. Normas de referencia Las normas que se detallan a continuacin, resultan indispensables para la aplicacin de esta norma. Para las referencias con fecha, slo se aplica la edicin citada.

Octubre de 2009

Para las referencias sin fecha se aplica la ltima edicin de la norma (incluyendo cualquier modificacin de sta). ISO 639-2 Cdigos para la representacin de nombres de idiomas. Parte 2: Cdigo Alfanumrico-3. ISO 3166-1 Cdigos para la representacin de los nombres de pases y sus subdivisiones. Parte 1: Cdigos de pases. ISO 19103:2005 Informacin Geogrfica. Esquema del lenguaje conceptual. ISO 19115:2003 Informacin Geogrfica. Metadatos. 4. Trminos, definiciones y abreviaturas 4.1. Trminos y definiciones A los fines de este documento, se aplicarn los siguientes trminos y definiciones: 4.1.1. Aclaracin Cambio no esencial de un elemento del registro.
Nota: Un cambio no esencial no modifica la semntica ni el significado tcnico del tem. Una aclaracin no implica un cambio en el status del registro del tem registrado.

4.1.2. Organismo de control Grupo tcnico de expertos que deciden el contenido de un registro. 4.1.3. Informacin geogrfica Informacin referida a fenmenos asociados implcita o explcitamente con una posicin relativa a la Tierra. (ISO 19101:2002) 4.1.4. Registro jerrquico Conjunto estructurado de registros para un dominio de tems de registro, compuestos de un registro principal y un conjunto de subregistros.
Ejemplo: La Norma ISO 6523 se relaciona con un registro jerrquico. El registro principal contiene esquemas identificadores de organizacin y cada subregistro contiene un conjunto de identificadores de organizacin que se ajustan a un esquema identificador de organizacin.

4.1.5. Identificador Secuencia de caracteres lingsticamente independiente, capaz de identificar univoca y permanentemente aquello con lo que est asociado. (adaptado de la Norma ISO/IEC 11179-3:2003) 4.1.6. Clase de tem Conjunto de tems con propiedades comunes.
Octubre de 2009 5

Nota: Una clase se utiliza en este contexto para referirse slo a un conjunto de instancias, no al concepto genrico de ese conjunto de instancias.

4.1.7. Escenario Marco cultural y lingstico aplicable a la interpretacin de una cadena de caracteres. 4.1.8. Registro principal Registro que contiene una descripcin de cada subregistro en un registro jerrquico. 4.1.9. Registro (1) Conjunto de archivos que contienen identificadores asignados a tems con descripciones de los tems asociados.
NOTA Adaptado del anexo E de ISO/IEC JTC 1, Procedimientos.

4.1.10. Administrador del registro Organizacin a la que el propietario del registro ha delegado la gestin de un registro.
Nota: En el caso de un registro ISO, el administrador del registro desarrolla las funciones de la autoridad registradora especificadas en las disposiciones de ISO/IEC.

4.1.11. Propietario del registro Organizacin que establece un registro. 4.1.12. Registro (2) Asignacin a un tem de un identificador permanente, nico e inequvoco.
Nota: Adaptado del Anexo E de ISO/IEC JTC 1, Procedimientos.

4.1.13. Sistema del registro Sistema de informacin en el que se mantiene un registro.

(adaptado de la Norma ISO/IEC 11179-3:2003)

4.1.14. Retirada Declaracin que un tem del registro es inadecuado para usarlo en la elaboracin de nuevos datos.
Nota: El status de los tems retirados cambia de valid ("vlido") a retired ("retirado"). Un tem retirado se almacena en el registro para coadyuvar en la interpretacin de los datos generados antes de su retirada.

4.1.15. Referencia de la fuente Referencia a la procedencia de un tem que se ha tomado de una fuente externa al registro.

Octubre de 2009

4.1.16. Organizacin remitente Organizacin que est autorizada por el propietario del registro para proponer modificaciones a su contenido. 4.1.17. Subregistro Parte de un registro jerrquico que contiene tems de una particin del campo de informacin. 4.1.18. Reemplazo Sustitucin de un tem del registro por uno o ms tems nuevos.
Nota: El status del tem reemplazado cambia de valid ("vlido") a superseded ("reemplazado").

4.1.19. norma tcnica Norma que contiene las definiciones de las clases de tems que requieren registro.
Nota: Adaptado del anexo E de ISO/IEC JTC 1, Procedimientos.

4.2. Abreviaturas IEC Comisin Electrotcnica Internacional (International Electrotechnical Commission)

JTC 1 Comit Tcnico Conjunto 1 (Joint Technical Committee 1) NWIP Propuesta de nuevo tem de trabajo (New Work Item Proposal) TC TMB Comit Tcnico (Technical Committee) Consejo de Gestin Tcnica (Technical Management Board)

UML Lenguaje Unificado de Modelado (Unified Modeling Language) 4.3. Notacin En esta norma, el esquema conceptual se describe utilizando el Lenguaje Unificado de Modelado (UML) (Norma ISO/IEC 19501), siguiendo las especificaciones de la Norma ISO/TS 19103:2005. La notacin UML se describe en Anexo B. Conforme a lo acordado por el Comit ISO/TC 211, los nombres de las clases UML, incluyen un prefijo de dos letras que identifica la norma y el paquete UML en el que se especifica la clase, a excepcin de las clases de tipos de datos bsicos. Las clases UML especificadas en esta norma internacional, tienen el prefijo de dos letras: RE. Varios elementos del modelo utilizados en este esquema se especifican en los paquetes establecidos en la Norma ISO 19115, tal como se puede observar en la Tabla 1.

Octubre de 2009

Tabla 1. Paquetes UML de la Norma ISO 19115:2003

Prefijo CI EX MD

Paquete Mencin Extensin Metadatos

5. Roles y responsabilidades en la gestin de registros 5.1. Introduccin Las diversas organizaciones desempean un determinado rol en la gestin de un registro (Figura 1). Los roles y sus relaciones se ilustran como un modelo conceptual, utilizando la notacin UML, que solo intenta representar un conjunto de organizaciones y sus interacciones.
Nota: El registro y el sistema del registro se incluyen en la Figura 1, aunque no sean organizaciones, ya que son la base de los roles de las organizaciones incluidas.

5.2. Propietario del registro El propietario de un registro es una organizacin que: a) ha establecido uno o ms registros; y b) tiene la responsabilidad principal de la gestin, difusin y contenido intelectual de esos registros. El propietario de un registro puede ser el administrador del registro para cualquier registro que haya establecido, o puede designar a otra organizacin para ello (apartado 5.3). El propietario de un registro debe especificar los criterios que establecen cuales organizaciones pueden actuar como organizaciones remitentes (apartado 5.4) que propongan cambios al contenido del registro. El propietario de un registro puede actuar como organismo de control (apartado 5.5) para cualquier registro que haya establecido, o puede delegar ese rol a un subgrupo dentro de la organizacin, o en el administrador del registro que previamente ha sido nombrado para gestionar el registro. El propietario del registro debe establecer un procedimiento para procesar las apelaciones de las organizaciones remitentes, y las decisiones tomadas por el organismo de control. La especificacin de este procedimiento debe incluir los lmites de tiempo adecuados para completar el proceso. El propietario del registro debe establecer el intervalo de tiempo que se tomar

Octubre de 2009

entre los informes del administrador del registro que describen las propuestas recibidas, y las decisiones tomadas desde el ltimo informe; y establecer los trminos y condiciones para publicar el contenido del registro. Cuando se trate de un registro jerrquico (apartado 7.1.4), el propietario del registro debe coordinar el establecimiento de subregistros por parte de otras organizaciones.

Figura 1. Relaciones organizativas

5.3. Administrador del registro 5.3.1. Designacin del administrador del registro El propietario de un registro puede delegar el rol de administrador del registro a otra organizacin. Esto ocurre habitualmente para los registros establecidos por los Comits Tcnicos de ISO o IEC.

Octubre de 2009

5.3.2. Responsabilidades de un administrador de registro Un administrador de registro Dentro de las clases de tems de las que es responsable, el administrador de registro debe gestionar un registro de tems, de acuerdo con lo estipulado en el apartado 6 de esta norma. Asimismo, puede gestionar mltiples registros; puede administrar y operar sobre el sistema del registro que contiene un registro que gestiona, o delegar la operacin del sistema del registro a un administrador del sistema del registro (apartado 5.6.). Ante una solicitud, el administrador del registro debe distribuir un paquete de informacin que contenga la descripcin del registro y la forma de remitir las propuestas de modificacin del contenido del mismo. Adems, debe aceptar las propuestas de las organizaciones remitentes y gestionarlas como se estipula en el apartado 6.2. El administrador del registro debe remitir las propuestas al organismo de control (apartado 5.5) para que ste decida sobre su aceptacin, y debe servir de nexo entre el organismo de control y las organizaciones remitentes en las tratativas relacionadas con los cambios de la propuesta. Tambin debe proporcionar informes al propietario del registro sobre los periodos especificados por ste. Cada informe debe describir las propuestas recibidas y las decisiones tomadas desde el ltimo informe. El propietario del registro define los trminos y condiciones bajo las cuales debe ponerse a disposicin del pblico, el contenido del registro. 5.4. Organizaciones remitentes 5.4.1. Organizaciones remitentes habilitadas Una organizacin remitente es una organizacin calificada bajo ciertos criterios establecidos por el propietario del registro, para proponer cambios en el contenido del mismo. El administrador del registro debe determinar si una organizacin remitente est calificada segn los criterios estipulados por la propiedad del registro. Una potencial organizacin remitente puede apelar la resolucin al propietario del registro. 5.4.2. Responsabilidades de las organizaciones remitentes Las organizaciones remitentes deben gestionar la presentacin de propuestas al administrador del registro o las apelaciones al propietario del registro, que se inicien desde sus respectivos pases u organizaciones, de la forma que se establece en el apartado 6.2. 5.5. Organismo de control El organismo de control est constituido por un grupo de expertos tcnicos designado por el propietario del registro para decidir sobre la aceptacin de propuestas

Octubre de 2009

10

de modificacin del contenido de un registro (apartado 6.2.7). El organismo de control debe aceptar las propuestas del administrador del registro y decidir sobre cada propuesta dentro del plazo estipulado por el propietario del registro. 5.6. Administrador del sistema del registro Un administrador del sistema del registro es una persona o una organizacin responsable de la gestin diaria del sistema del registro; y puede contratar a un tercero como proveedor de servicios, para realizar dicha tarea. Adems, debe asegurar la integridad de cualquier registro que est en el sistema del registro (apartado 6.5), y ofrecer los medios para acceder electrnicamente al sistema del registro (apartado 6.4) a los administradores de registro, organismos de control y usuarios del registro. 5.7. Usuario del registro Los usuarios del registro acceden al sistema del registro para utilizar uno o ms registros que estn en el mismo. Un usuario puede ser cualquier persona u organizacin interesada en acceder o intervenir en el contenido de un registro. Hay varias condiciones que deben cumplir los usuarios, para acreditarse: redactores de normas y especificaciones que quieren reutilizar tems establecidos en un registro; productores de datos que quieren usar en sus productos, tems establecidos en un registro; usuarios de datos que quieren entender el significado de los tems de un registro empleados por un productor de datos; y desarrolladores de sistemas que quieren habilitar el empleo de tems del registro para la elaboracin, intercambio o consumo de datos. Para satisfacer los requerimientos de las distintas categoras de usuarios, el propietario de un registro puede establecer los trminos y condiciones para los diferentes niveles de acceso al registro. Los usuarios del registro necesitan establecer diferentes frecuencias de acceso, desde los usuarios ocasionales de datos (que pueden necesitar determinar el significado de un tem del registro con muy poca frecuencia), hasta los productores de datos (que pueden necesitar usar valores de un registro varias veces al da). Los administradores del registro deben considerar las exigencias de las distintas categoras de usuarios al seleccionar los procedimientos para que el contenido de un registro sea publicado (apartado 6.4).

Octubre de 2009

11

6. Gestin de registros 6.1. Establecimiento de registros Un registro puede ser establecido por cualquier organizacin. Un registro ISO es un registro establecido por un Comit Tcnico (TC) o Subcomit Tcnico de ISO. Aunque esta norma internacional regula principalmente los registros establecidos por ISO/TC 211, otros Comits Tcnicos ISO o IEC pueden establecer registros de acuerdo con esta norma internacional. Adems de los Comits o Subcomits Tcnicos ISO o IEC, otras organizaciones, pueden decidir establecer registros conformes con esta norma internacional. Se exige a los Comits Tcnicos de ISO que al establecer registros, sigan las reglas generales establecidas en las disposiciones ISO/IEC, pero pueden definir pautas y procedimientos detallados para satisfacer sus propios requisitos. Las disposiciones ISO/IEC exigen a un Comit Tcnico (TC), que cuando se est desarrollando una norma internacional que pueda necesitar un registro, informe en una primera etapa al Consejero Delegado, para permitir cualquier negociacin necesaria y permitir al ISO/TMB o al Consejo de Direccin de IEC tomar una decisin antes de publicar la norma internacional. Los procedimientos ISO/IEC JTC 1 determinan las pautas a seguir para el establecimiento de registros JTC 1. En el Anexo C de esta norma se detallan las pautas y procedimientos para el establecimiento y la gestin de registros por ISO/TC 211. Por otra parte, otras organizaciones pueden especificar sus propias pautas y procedimientos para establecer registros. Cada registro precisa una norma tcnica que especifique las clases de tems que se requieren registrar. Para establecer un registro de acuerdo a esta norma internacional, una organizacin debe: a) ser la organizacin que redact la norma tcnica que define las clases de tems que va a contener un registro; o b) Contar con la aprobacin de esa organizacin. 6.2. Procesamiento de propuestas 6.2.1. Introduccin Las organizaciones remitentes pueden presentar solicitudes para agregar, modificar o retirar tems de un registro. Las modificaciones pueden ser de dos tipos: simples aclaraciones que no producen cambios fundamentales a un tem (apartado 6.2.3), o cambios sustanciales que se realizan mediante un proceso de reemplazo (apartado 6.2.4). El organismo de control ser quien determine si la modificacin propuesta debe realizarse como una aclaracin o un reemplazo.

Octubre de 2009

12

6.2.2. Adicin La adicin es la insercin de un tem en un registro que describe un concepto an no descripto en l. 6.2.3. Aclaracin Las aclaraciones corrigen errores de ortografa, de puntuacin o de gramtica. En un tem registrado, una aclaracin no debe implicar cambios sustanciales, semnticos o tcnicos. 6.2.4. Reemplazo La modificacin de un tem registrado que signifique un cambio sustancial, semntico o tcnico, se debe realizar incluyendo un nuevo tem en el registro con un identificador nuevo y la fecha en que se reemplaza al tem original (apartado 8.9.6). El tem original permanecer en el registro, incluyendo la fecha de su reemplazo, y una referencia al tem que lo reemplaz. 6.2.5. Retirada Cuando los tems registrados ya no son tiles para la elaboracin de datos, las organizaciones remitentes pueden presentar solicitudes para su retirada. La retirada debe realizarse dejando al tem en el registro, etiquetndolo como retirado e incluyendo la fecha de su retirada (apartado 8.9.6). 6.2.6. Presentacin de propuestas 6.2.6.1. En la Figura 2, se ilustra el proceso para la presentacin de propuestas para el registro de tems de informacin geogrfica. 6.2.6.2. Las organizaciones remitentes deben: a) recepcionar las propuestas para el registro de tems que den inicio en sus pases u organizaciones respectivas; b) controlar que todas las propuestas estn completas (apartado 6.6); c) coordinar propuestas con otras organizaciones remitentes que as lo decidan; d) elevar al administrador del registro correspondiente, las propuestas que tengan el apoyo de la organizacin remitente; y e) presentar las propuestas al administrador del registro o al propietario del registro, si fuese necesario. 6.2.6.3. El administrador del registro debe: a) recepcionar las propuestas de las organizaciones remitentes calificadas y/o acreditadas;

Octubre de 2009

13

b) controlar que las propuestas estn completas, si las propuestas estuvieran incompletas o si la organizacin remitente no est calificada y/o acreditada, devolverlas a las organizaciones remitentes; c) generar un registro de gestin de propuestas (apartado 8.9), con el atributo status (apartado 8.9.4) indicando pendiente; d) iniciar el proceso de aprobacin (apartado 6.2.7).
Organizacin Remitente Administrador del Registro

Desarrolla una propuesta

Coordinado con otras organizaciones remitentes Revisa la propuesta

[No] Propuesta completa? [Si]

Genera un registro de gestin de la propuesta

Figura 2. Presentacin de propuestas para registrar

Octubre de 2009

14

6.2.7. Proceso de aprobacin 6.2.7.1. El proceso para determinar la aceptacin de las propuestas se muestra en la Figura 3, el que debe completarse en el plazo establecido por el propietario del registro.
Organizacin Remitente Administrador del Registro Organismo de Control

[No]

Aclaracin o retirada?

[Si]

Insertar nuevo Item en el registro

Evaluar Propuesta

[No]

Cambio propuesto?

[Si] Negociar Cambio Negociar Cambio

Actualizar status y contenido

Difusin de resultado

Figura 3. Proceso de aprobacin

Octubre de 2009

15

6.2.7.2. El administrador del registro debe. a) si la propuesta es de aclaracin o de retirada de un tem del registro, enviar la propuesta al organismo de control; b) si la propuesta es para el registro de un nuevo tem o la modificacin de un tem de registro existente: 1) insertar un nuevo tem, o uno que reemplace a otro en el registro; 2) asignar un itemIdentifier (apartado 8.8.2) al nuevo tem o al tem que reemplaza, como se estipula en el apartado 7.2; 3) fijar el status (apartado 8.8.4) a notValid; y 4) enviar la propuesta al organismo de control. 6.2.7.3. El organismo de control debe: a) resolver aceptar la propuesta sin cambios, aceptarla con los cambios acordados con la organizacin remitente, o no aceptarla. Los criterios para no aceptar una propuesta pueden ser: 1) porque la especificacin del tem est incompleta o es incomprensible; 2) porque ya existe un tem idntico en el registro;
NOTA: Un tem idntico puede existir en ms de un subregistro, en el caso de un registro jerrquico

3) el tem propuesto no est incluido en la clase de tems que pertenecen a ese registro; o 4) No es apropiada la justificacin de la propuesta; b) comunicar al administrador del registro, dentro del tiempo lmite determinado por el propietario del registro, la decisin y su justificacin. 6.2.7.4. El administrador del registro debe: a) Servir de nexo entre la organizacin remitente y el organismo de control, si existe la necesidad de negociaciones con relacin a los cambios en la propuesta, que defina el organismo de control como condicin de aceptacin; y b) Comunicar los resultados del proceso de la propuesta a la organizacin remitente. Si la disposicin del organismo de control es positiva, el administrador del registro debe: a) completar el registro de gestin de la propuesta con status (apartado 8.9.4) fijado a final, disposition (apartado 8.9.5) fijada a accepted, y dateDisposed (apartado 8.9.6) fijada en la fecha actual; b) efectuar los cambios que fueron aprobados en el contenido del tem del registro; y

Octubre de 2009

16

c) fijar el status (8.8.4) del tem del registro a valid, superseded o retired, segn corresponda. Si la disposicin del organismo de control es negativa, el administrador del registro debe: a) actualizar el registro de gestin de propuestas fijando el status (8.9.4) a tentative, disposition (8.9.5) a notAccepted, y dateDisposed (apartado 8.9.6) a la fecha actual; b) comunicar a la organizacin remitente la fecha lmite de apelacin de la decisin del organismo de control. El administrador del registro deber divulgar los resultados del proceso de aprobacin. 6.2.7.5. Las organizaciones remitentes deben: a) negociar con el organismo de control las modificaciones de su propuesta como condicin de aceptacin; y b) publicitar las decisiones tomadas por el organismo de control sobre las propuestas, en cada uno de sus pases u organizaciones respectivas, segn las remita el administrador del registro. 6.2.8. Retirada Las organizaciones remitentes pueden resolver retirar una propuesta en cualquier momento durante el proceso de aprobacin. El administrador del registro debe: a) cambiar el status (apartado 8.9.4) del registro de gestin de propuestas, de pending a final; y b) cambiar el valor de disposition (8.9.5) a withdrawn y el valor de dateDisposed (apartado 8.9.6) a la fecha actual. 6.2.9. Apelacin 6.2.9.1. Si no est de acuerdo con la decisin del rechazo de una propuesta por parte del organismo de control, una organizacin remitente puede apelar al propietario del registro. La presentacin de una apelacin deber contener como mnimo la descripcin de la situacin, la justificacin para la apelacin, y la declaracin del impacto si se rechaza la misma. En la Figura 4 se ilustra el proceso de apelacin.

Octubre de 2009

17

Organizacin Remitente

Administrador del Registro

Propietario del Registro

[Si]

Resultado Aceptable?

[No]

Presentacin de la Apelacin

Envo de la apelacin Decisin sobre la Apelacin

Analizar el Status

Difundir el resultado final

Figura 4. Proceso de apelacin 6.2.9.2. La organizacin remitente debe: a) definir si es aceptable, la decisin tomada sobre la propuesta para el registro; y b) si considera que sta no es aceptable, presentar una apelacin al administrador del registro. Si no hay apelacin, al concluir el plazo estipulado de presentacin de apelaciones, el

Octubre de 2009

18

administrador del registro deber cambiar el status (apartado 8.9.4) del registro de gestin de propuestas a final y cambiar dateDisposed (apartado 8.9.6) a la fecha actual. 6.2.9.3. El administrador del registro debe enviar la apelacin al propietario del registro. 6.2.9.4. El propietario del registro debe: a) procesar la apelacin siguiendo los procedimientos establecidos (apartado 5.2); b) resolver si acepta o rechaza la apelacin; y c) proporcionar el resultado al administrador del registro. 6.2.9.5. El administrador del registro debe: a) actualizar disposition (apartado 8.9.5.) y dateDisposed (apartado 8.9.6.) del registro de gestin de propuestas; b) actualizar status (apartado 8.8.4.) del tem de registro; y c) proveer al organismo de control y a la organizacin remitente, los resultados de la decisin. 6.2.9.6. La organizacin remitente debe: a) publicar los resultados de la apelacin en su pas u organizacin. 6.3. Lista de organizaciones remitentes El administrador del sistema del registro deber mantener y difundir una lista precisa de registros, con todas las organizaciones remitentes calificadas y/o acreditadas (apartado 5.4.1.) que hayan remitido propuestas para solicitar cambios en el contenido de cada registro que gestione. Cada lista incluir para cada organizacin remitente, el nombre y los datos del contacto (apartado 8.5.3.). 6.4. Publicacin El administrador del sistema del registro deber garantizar a los usuarios que la informacin de tems vlidos, reemplazados o retirados del registro, est fcilmente disponible. La forma de suministrar esa informacin depender de los requerimientos de usuarios (apartado 5.7.) Se sugiere usar un mtodo transaccional para apoyar a los usuarios con requerimientos ocasionales de informacin sobre tems de registro especficos. El registro debera estar accesible a los usuarios (con restricciones de acceso) a travs de un sitio web de Internet u otra forma de proceso electrnico. Los servicios del registro deberan permitir consultas basadas en los nombres de los tems o bsquedas por palabras clave dadas en las definiciones o en otros elementos de informacin sobre el tem del registro. Se sugiere un mtodo de transferencia para aquellos usuarios con requisitos de acceso frecuente a mltiples tems en un registro. El administrador del registro debera

Octubre de 2009

19

poder proveer de copias del conjunto de los tems vlidos contenidos en el registro, tales como datos digitales en un medio fsico, o en papel. El administrador del registro debera arbitrar los medios para actualizar las copias distribuidas, adems, puede cobrar por la reproduccin y distribucin de las copias. 6.5. Integridad Para cada registro que administre, el administrador de registro deber asegurar que: a) el proceso del registro se efecte de acuerdo a correctas prcticas empresariales; b) el contenido del registro sea exacto; c) slo personas autorizadas puedan realizar modificaciones en el registro; d) el registro est asegurado frente a prdidas causadas por daos al sistema en el que se conserva el registro; e) se enve al propietario del registro una copia del mismo, al menos una vez al ao; y f) la informacin confidencial est protegida. 6.6. Propuestas de registro La informacin mnima necesaria para elevar una propuesta a un administrador de un registro, se especifica en Anexo D. Los requerimientos de informacin adicional se pueden establecer para una clase de tems en una norma tcnica que especifique esa clase de tems. Se puede obtener detalles del administrador del registro correspondiente. 7. Algunos principios de registro 7.1. Estructuras alternativas de registro 7.1.1. Generalidades Existen distintas alternativas para estructurar registros: un registro simple que contiene tems de una sola clase (apartado 7.1.2); un registro multiparte, en el que diferentes partes contienen tems de diferentes clases (apartado 7.1.3); o un registro jerrquico, cuyo nivel ms alto contiene una lista de los registros de nivel inferior (apartado 7.1.4). 7.1.2. Registro simple Un registro simple contiene tems de una sola clase. Esta es la estructura ms simple de gestionar, ya que los mismos elementos de informacin se graban para todos los tems del registro, y requiere un mnimo costo para cualquier administrador de

Octubre de 2009

20

registro. Como desventaja, una organizacin que quiera establecer registros para mltiples clases de tems, puede disgregar tales registros entre varios administradores de registro.
Ejemplo: Un registro de terminologa ISO/TC 211 podra contener solo tems de una clase especificada en la Norma ISO 19104.

7.1.3. Registro multiparte Un registro multiparte contiene tems de diferentes clases. Se organiza en secciones que se basan en los distintos elementos de informacin almacenados para cada clase. Ejemplo: Un catlogo de fenmenos conforme a la Norma ISO 19110 puede constituirse como un registro multiparte. Tal registro incluira diferentes clases de tems segn los tipos, los atributos, asociaciones y operaciones de fenmenos. 7.1.4. Registro jerrquico Un registro jerrquico es un conjunto estructurado de registros compuesto de un registro principal y de uno o ms subregistros. Este tipo de registro se asocia a un dominio dividido de informacin geogrfica, como se muestra en la Figura 5. Segn sean los criterios empleados para dividir el dominio, las particiones pueden ser excluyentes entre s, pero no necesariamente deben serlo. Aunque la mayora de los tems en cada divisin deberan ser nicos, los tems idnticos pueden estar en ms de una particin. El registro principal puede ser multiparte, o parte de un registro multiparte, y contiene un conjunto de tems que describen los subregistros. Cada subregistro contiene un conjunto de tems registrados de una particin del dominio de la informacin. Un registro principal puede ser un registro ISO, aunque sus subregistros son establecidos y mantenidos generalmente por organizaciones distintas a los Comits Tcnicos ISO o IEC.

Octubre de 2009

21

Registro Principal

Subregistros

Descripcin de la particin Descripcin de la particin Descripcin de la particin Descripcin de la particin Descripcin de la particin

tems registrados

tems registrados

tems registrados

tems registrados

tems registrados

Figura 5. Un registro jerrquico

Ejemplo: Las disposiciones de ISO/IEC JTC 1 mencionan el registro para la Norma ISO 6523 como un ejemplo de un registro jerrquico. Este registro jerrquico consiste en un registro principal de esquemas identificadores de organizacin, con un subregistro para cada esquema que contiene identificadores de organizacin que cumplen con ese esquema. Los registros para los esquemas individuales de identificadores de organizacin son administrados por organizaciones emisoras que no necesariamente deben ser autoridades registradoras designadas por ISO. Un registro ISO/TC 211 de catlogos de fenmenos podra establecerse como registro jerrquico en el que cada catlogo de fenmenos est establecido como un subregistro, propiedad de la organizacin que elabora el catlogo.

7.2. Identificacin de tems del registro 7.2.1. Introduccin Todos los tems deberan incluir, un identificador que proporcione los requisitos para una notacin eficiente para el proceso de informacin, y un nombre que provea los requisitos para una notacin accesible para el ser humano (Figura 6).

Octubre de 2009

22

Identificacin

Representacin

Identificado r <<276>> Norma ISO 3166-1

Imagen

Lenguaje Humano

Cdigo

Allemagne Deutschland Germany

<<DE>> Norma ISO 3166-1

Figura 6. Ejemplo de la diferencia entre identificadores empleados en una interfaz de tecnologa de informacin y las representaciones empleadas en la interfaz del usuario 7.2.2. Identificadores de tems Los identificadores de tems deben utilizarse como mtodo para identificar en forma univoca un tem dentro de un registro. 7.2.3. Nombres de tems Para facilitar la bsqueda de tems de inters para un usuario del registro, se necesitan los nombres de tems. Un tem del registro debe tener asignado un nombre en el lenguaje de operacin del registro en el que aparece. La sintaxis del dominio de nombres debe estar especificada en la norma tcnica que establece la clase de tem. Los nombres no deben ser nicos, y por ello solo pueden emplearse como identificadores secundarios de tems dentro de un registro. 7.3. Definicin de los tems de un registro 7.3.1. Caractersticas de una definicin La Norma ISO 704 provee pautas para definir trminos; algunas de ellas tambin pueden ser tiles para definir otros tipos de tems. Una definicin debe: a) ser una expresin precisa de la naturaleza del concepto que comprende el tem; b) identificar las caractersticas esenciales de un tem que lo diferencian de otros tems; c) describir slo lo que es el tem, y no lo que no es; d) describir un tem, y no las palabras que forman la denominacin; y

Octubre de 2009

23

e) ser tan breve como sea posible y tan compleja como sea necesario. Las definiciones complejas pueden contener varias condiciones dependientes, pero si las definiciones estn escritas minuciosamente, slo contienen informacin que hace nico al tem. 7.3.2. Referencias a fuentes externas 7.3.2.1. Uso de tems especificados externamente Pueden utilizarse distintos registros para permitir diferentes reas de aplicacin, pero esas reas pueden necesitar compartir informacin. Una organizacin puede reconocer formalmente a otra como fuente adecuada para la especificacin de un determinado tipo tem. El propietario de un registro tambin puede adoptar tems de otras organizaciones que los hayan especificado en documentos o en registros. Cuando esto sucede, el registro que adopta el tem debe proveer una referencia (apartado 8.13) a la fuente del tem adoptado. Las especificaciones adoptadas de normas son un caso especial (apartado 7.3.2.2).
Ejemplo: Si un organismo de normalizacin reconoce el catlogo de fenmenos IHO S-57 como la fuente autorizada para informacin hidrogrfica, entonces los tipos de fenmenos hidrogrficos especificados en dicho catlogo, se pueden referenciar individualmente (por ejemplo, nombre y definicin) en un registro separado mantenido por el organismo de normalizacin adoptante.

Una definicin adoptada no debe ser modificada, salvo para arreglar diferencias de estilo entre el registro fuente y el registro usuario, o para aadir informacin de contexto que est implcita en la fuente (apartado 8.24).
Nota: Antes de reutilizar un trmino y una definicin de una fuente que no es la original, deberan confrontarse con la correspondiente a la fuente original, ya que al repetir las modificaciones de estilo, pueden modificar inadvertidamente su significado.

Las organizaciones pueden pactar un proceso comn para mantener las especificaciones compartidas. Estos acuerdos de cooperacin bilateral deben contener disposiciones para mantener informadas a las otras organizaciones de la modificacin de la norma o registro fuente de los tems compartidos. Tambin pueden utilizarse referencias para proveer la informacin sobre el linaje que detalla el desarrollo histrico de una especificacin. Puede haber, en este caso, ms de una referencia, y los cambios involucrados con las definiciones referenciadas pueden ser ms relevantes. 7.3.2.2. tems especificados en normas El registro de un tem provee la identificacin, pero esto no es un proceso de estandarizacin. Los tems contenidos en un registro pueden estar especificados en una norma internacional, nacional u otra, antes o despus de registrarse. Entonces, el registro

Octubre de 2009

24

deber hacer referencia a la norma que se aplic. Cuando esa norma es posterior al registro del tem, el identificador del tem debe ser indicado en la norma.
Nota: En este caso la referencia se hace a la norma en la que se especifica el tem, y no a la norma tcnica en la que se especifica la clase del tem. Ejemplo: ISO/TC 211 puede establecer un registro de elementos de metadatos. La clase del tem elemento de metadatos se especifica en la Norma ISO 19115:2003. El registro de elementos de metadatos podra contener los elementos de metadatos de servicios especificados en la Norma ISO 19119 como tems registrados. La informacin sobre cada uno de estos tems registrados debera incluir una referencia a la Norma ISO 19119 como la norma en la que se especifica el tem individual, y en la que se encuentra una identificacin exacta del tem referenciado.

7.4. Adaptabilidad cultural y lingstica Un registro debe administrarse de manera que cumpla con los requisitos culturales y lingsticos (ISO/IEC TR 19764). Los elementos de datos que describen un registro o su contenido deben: a) usar identificadores en lugar de nombres o abreviaturas; b) emplear una lista de cdigos en lugar de un texto libre, cuando se propone una lista de los valores permitidos; y c) estructurar los elementos de datos de texto libre, de manera que acepten mltiples idiomas. Los nombres y especificaciones de tems en un registro pueden tener significado slo en el contexto de ciertos idiomas o culturas (escenarios). Para definir un contexto cultural y lingstico sin ambigedad para un registro, es fundamental especificar el idioma, el pas y la codificacin de caracteres y de cadenas de caracteres en ese registro. Para facilitar la adaptabilidad cultural y lingstica, los tems individuales de un registro pueden describir adems nombres y definiciones alternativos. stos podran definirse en idiomas y culturas alternativos distintos a los del registro. Se estimula a las organizaciones remitentes a proponer especificaciones de tems alternativas en otros idiomas diferentes al utilizado en el registro. Para administrar temas culturales y lingsticos, los propietarios del registro pueden adems optar por el uso de mltiples registros, donde los tems en un registro que se caracteriza por ser homogneo respecto a un escenario, hacen referencia a otros registros que se encuentran en otros escenarios. 7.5. Estado de los tems del registro El contenido de un registro es siempre dinmico. Cuando se proponen nuevos tems, ellos podrn ser aceptados o no. Si son aceptados, pueden luego aclararse, reemplazarse o retirarse. Se necesitan elementos de informacin para apoyar la

Octubre de 2009

25

administracin de tems a lo largo de su historia, incluyendo a la organizacin patrocinadora, estado, fechas de adopcin de estados concretos, y el posible reemplazo por otros tems en el registro. Los tems individuales debern administrarse individualmente, movindose a travs de un conjunto de estados bien definidos. La informacin relativa a la historia temporal de cada tem debe guardarse. Generalmente slo se muestran los tems vlidos, reemplazados o retirados cuando los contenidos de un registro se hacen pblicos. Los tems propuestos y no aceptados son parte del procedimiento de aprobacin y son necesarios slo para la gestin del registro. Las organizaciones remitentes deben tener acceso a los tems propuestos no aceptados, ya que la informacin sobre estos puede resultar de utilidad para el desarrollo de nuevas propuestas. Un tem en un registro tiene un tiempo de validez, que corre a partir de la fecha en la que ha sido aceptada la propuesta para registrar el tem, hasta la fecha en que se reemplaza o retira el tem. Los tems retirados y reemplazados, se guardan en el registro para ayudar a la interpretacin de datos producidos antes de su retirada o reemplazo, aunque ya no son vlidos para la confeccin de nuevos datos.
Nota: Esto no significa que el uso de un tem no registrado, especificado en una norma, sea no vlido hasta que el tem se registre. Sin embargo, una referencia que utilice un identificador de tem puede aplicarse slo a la especificacin de un tem registrado.

Los conceptos de informacin geogrfica descriptos en un registro pueden modificarse con el transcurso del tiempo, ya sea por cambios en los requisitos o en la tecnologa, o por otras razones. Al especificar una serie de tems de la misma clase, cada una con fechas asociadas de validez, un registro puede identificar cmo un determinaod concepto ha cambiado en un periodo de tiempo. Si un tem es reemplazado por otro, la fecha de sucesin debe guardarse, as como las referencias al tem que lo ha reemplazado. En un momento determinado, slo un tem de la serie debe ser valid (apartado 8.8.4.). 7.6. Estado del registro Es preciso poder especificar un estado nico en el desarrollo de los contenidos de un registro, ya que esos contenidos evolucionarn con el tiempo. Esta norma establece dos procedimientos alternativos, que se diferencian por la velocidad de cambio en los contenidos del registro, para especificar ese estado nico. a) Para registros que cambian de manera lenta, por ejemplo aquellos diseminados como documentos fsicos, puede especificarse una versin.

Octubre de 2009

26

b) Para registros que cambian rpidamente, por ejemplo aquellos que se encuentran disponibles en bases de datos interactivas en lnea, puede especificarse la fecha del ltimo cambio. 8. Esquema del registro 8.1. Introduccin El esquema mostrado en este apartado define la estructura del registro. El esquema consta de un nico paquete (Figura 7) formado por 13 clases que presentan la informacin contenida en el registro, y 9 tipos de datos que son utilizados por atributos de estas clases, cada uno se documenta en un subcaptulo ms adelante. La informacin sobre el registro y los tems del registro debe ser: a) de fcil acceso a travs de cualquier interfaz en lnea del registro (apartado 6.4); b) contenida en cualquier copia del registro (apartado 6.4); y c) incluida en cualquier paquete de informacin sobre el registro (apartado 5.3.2). El registro principal de un registro jerrquico debe mantener esa informacin para cada uno de sus subregistros.

Figura 7. El esquema del registro

Octubre de 2009

27

8.2. RE_Register (registro) 8.2.1. Introduccin La clase RE_Register (Figura 8) define la informacin sobre el registro. El mismo tiene 6 atributos y 6 asociaciones. 8.2.2. name (nombre) El atributo name debe representarse como un CharacterString que incluye un identificador compacto y entendible por un ser humano, que es utilizado para identificar exclusivamente a ese registro dentro del conjunto de registros mantenidos por el propietario del registro. En el caso de un registro jerrquico, el name de un subregistro debe identificar de manera nica ese subregistro dentro del campo de aplicacin de todos los registros determinados por el propietario del registro principal.
Ejemplo: El registro de los diccionarios de datos de fenmenos y catlogos de fenmenos ISO/TC 211 puede ser el nombre de un registro principal de un registro jerrquico. El Diccionario de datos DGIWG FACC y el Diccionario de objetos IHO S-57 pueden ser los nombres de subregistros en la jerarqua.

Figura 8. RE_Register

Octubre de 2009

28

8.2.3. contentSummary (resumen de contenido) El atributo contentSummary debe representarse como un CharacterString que incluye una declaracin general del propsito por el que los tems del registro estn disponibles a los usuarios potenciales. Adems, se debera definir cualquier lmite en el campo de aplicacin del registro e identificar los tipos de aplicaciones para los cuales estn destinados los tems.
Nota: El campo de aplicacin de un registro puede limitarse por temas, por regiones, por idioma u otros criterios. Ejemplo: El campo de aplicacin de un registro de terminologa puede limitarse a trminos en espaol utilizados para describir el relieve en Amrica Latina.

8.2.4. uniformResourceIdentifier (identificador uniforme del recurso) El atributo uniformResourceIdentifier debe tomar como valor un conjunto de instancias de CI_OnLineResource [Norma ISO 19115:2003, B. 3.2.5, fila 396], cada una de las cuales contiene informacin sobre los recursos en lnea asociados con el registro. El conjunto debe incluir al menos una instancia de CI_OnLineResource para la que el atributo OnLineResource.function tiene el valor de information (002) [Norma ISO 19115:2003, B.5.3, fila 3] y el correspondiente valor del atributo OnLineResource.linkage determina un recurso que brinda acceso a todo el contenido del registro.
Ejemplo: Las direcciones http://www.digest.org/Navigate2.htm de y http://www.epa.gov/opppmsd1/PPISdata/index.html son valores de muestra OnLineResource.linkage.

8.2.5. operatingLanguage (idioma operativo) El atributo operatingLanguage debe representarse como una instancia de la clase RE_Locale (apartado 8.17) que es empleada para definir el idioma, la informacin del pas y la codificacin de caracteres, para la adecuada interpretacin del contenido de las cadenas de caracteres del registro. Los valores de todas las cadenas de caracteres del registro deben estar conformes al valor del operatingLanguage, a menos que se indique lo contrario. 8.2.6. alternativeLanguages (idiomas alternativos) Los tems individuales de un registro pueden proveer elementos de informacin en otros idiomas distintos al lenguaje operativo del registro, con el objeto de poder mantener la adaptabilidad cultural y lingstica, El atributo alternativeLanguages debe representarse como un conjunto de

Octubre de 2009

29

instancias de RE_Locale (apartado 8.17), cada una de las cuales define un escenario nico utilizado por los tems del registro. Cada miembro del conjunto debe ser empleado por al menos un tem del registro. El locale de todas las alternativeExpression (apartado 8.8.10) utilizado por cualquier tem del registro, debe incluirse en este conjunto de RE_Locales. Este atributo suministra un resumen de escenarios alternativos utilizados por los tems de un registro. Los propietarios del registro deben especificar y publicar sus criterios respecto a si todos o slo algunos tems del registro deben disponer de expresiones alternativas (apartado 8.15). 8.2.7. version (versin) El atributo condicional version debe presentarse como una instancia de la clase RE_Version (8.18) que define un estado nico en la vida del registro. Se debe suministrar un valor para este atributo si no se facilita un valor de dateOfLastChange (apartado 8.2.8). 8.2.8. dateOfLastChange (fecha del ltimo cambio) El atributo condicional dateOfLastChange debe representarse como una instancia de la clase <<Date>> (Especificacin Tcnica ISO/TS 19103:2005, apartado 6.5.2.7) y especifica la fecha en que se ha producido la modificacin ms actual del status (apartado 8.8.4) de un tem. Se debe proporcionar un valor para este atributo si no se facilita un valor para la version (apartado 8.2.7). 8.2.9. Ownership (propiedad) La asociacin Ownership conecta el RE_Register con la instancia de RE_RegisterOwner (apartado 8.3.) que provee informacin sobre el propietario del registro que lo posee. La asociacin debe ser navegable desde el register al owner, pero no necesariamente en el sentido contrario. 8.2.10. Management (administracin) La asociacin Management conecta el RE_Register con la instancia de RE_RegisterManager (apartado 8.4.) que suministra informacin sobre el administrador del registro que lo administra. La asociacin debe ser navegable desde el register al manager, pero no necesariamente en el sentido contrario. 8.2.11. ContentDescription (descripcin del contenido) La asociacin ContentDescription conecta el RE_Register con una o ms instancias de RE_ItemClass (8.6), cada una de las cuales detalla las caractersticas de

Octubre de 2009

30

una clase de tems mantenidos en el registro. La asociacin debe ser navegable desde el register a containedItemClass, pero no necesariamente en el sentido contrario. 8.2.12. Content (contenido) La asociacin de agregacin Content conecta el RE_Register con el conjunto de RE_RegisterItem (8.8.) mantenidos en el registro. La asociacin debe ser navegable desde el register al containedItem, pero no necesariamente en el sentido contrario. 8.2.13. Sponsorship (patrocinador) La asociacin Sponsorship conecta el RE_Register con las instancias de RE_SubmittingOrganization (apartado 8.5.) que hayan enviado propuestas de modificacin del contenido del registro. La asociacin debe ser navegable desde el register al submitter, pero no necesariamente en el sentido contrario. 8.2.14. Reference (referencia) La asociacin condicional Reference conecta el RE_Register con un conjunto de RE_ReferenceSource (apartado 8.7.) que detalla las fuentes (documentos o registros) de las que se han tomado los tems del RE_Register. Esta asociacin es obligatoria para cualquier registro que incluya referencias a fuentes externas para especificaciones de tems incluidos en el registro. Todas las referencias para cada tem del registro deben listarse en el conjunto de los RE_ReferenceSource asociado. Cada miembro de ese conjunto debe referenciarse al menos por un tem del registro. La asociacin debe ser navegable desde el register a citation, pero no necesariamente en el sentido contrario. 8.3. RE_RegisterOwner (propietario del registro) 8.3.1. Introduccin La clase RE_RegisterOwner (Figura 9) especifica informacin sobre el propietario del registro. Tiene 2 atributos y 1 asociacin.
Re_RegisterOwner + nane : CharacterString + contact : CI_ResponsibleParty 1 Ownership 1..* +register +owner

Re_Register

Figura 9. RE_RegisterOwner
Octubre de 2009 31

8.3.2. name (nombre) El atributo name debe representarse como un CharacterString que contenga un denominador compacto y legible para el ser humano, que se utiliza para indicar el propietario de ese registro.
Ejemplo: ISO/TC 211, Grupo de trabajo de informacin geogrfica digital, y Agencia Hidrogrfica Internacional. Nota: Esta norma internacional no necesita que el nombre del propietario sea nico, ya que en general una organizacin tendrun nombre antes de encargarse del establecimiento de un registro.

8.3.3. contact (contacto) El atributo contact debe representarse como fila 374). una instancia de

CI_ResponsibleParty (Norma ISO 19115:2003, B.3.2.1,

El atributo CI_ResponsibleParty.individualName o CI_ ResponsibleParty.positionName deben identificar, por el nombre o el cargo respectivamente, a una persona que se utiliza de contacto para la informacin sobre el propietario del registro y sobre el registro. El atributo CI_ResponsibleParty.contactInfo debe utilizar una instancia de CI_Contact (Norma ISO 19115:2003, B.3.2.3, fila 387) para suministrar los datos sobre la forma de comunicarse con esa persona. 8.3.4. Ownership (propiedad) La asociacin Ownership conecta el RE_RegisterOwner con una instancia de RE_Register (apartado 8.2) que posee. La asociacin debe ser navegable desde el register al owner, pero no necesariamente en el sentido contrario. 8.4. RE_RegisterManager (Administrador del registro) 8.4.1. Introduccin La clase RE_RegisterManager (Figura 10) define informacin sobre el administrador del registro nombrado por el propietario del registro para administrarlo. Tiene 2 atributos y 2 asociaciones.

Octubre de 2009

32

Re_RegisterManager + nane : CharacterString + contact : CI_ResponsibleParty

1 +subregisterManager SubregisterManagement Management 1..* +register 0..* +Subregister

+manager

Re_Register

Re_SubregisterDescription

Figura 10. RE_RegisterManager 8.4.2. name (nombre) El atributo name debe mostrarse como un CharacterString que tenga un denominador compacto y legible por el ser humano, que se utiliza para indicar el administrador de ese registro.
Ejemplo: Grupo de trabajo de informacin geogrfica digital, y Agencia Hidrogrfica Internacional. Nota: Esta norma internacional no necesita que el nombre del administrador del registro sea nico, ya que en general, una organizacin tendr un nombre antes de encargarse de la administracin de un registro.

8.4.3. contact (contacto) El atributo contact debe mostrarse como una instancia de CI_ResponsibleParty (Norma ISO 19115:2003, B.3.2.1, fila 374). El atributo CI_ResponsibleParty.individualName o el atributo

CI_ResponsibleParty.positionName deben identificar, por el nombre o el cargo, respectivamente, a una persona que acte como contacto para la informacin sobre el administrador del registro y sobre el registro. El atributo CI_ResponsibleParty.contactInfo debe utilizar una instancia de CI_Contact [Norma ISO 19115:2003, B.3.2.3, fila 387] para facilitar informacin sobre los medios de comunicacin con esa persona. 8.4.4. Management (administracin) La asociacin Management conecta el RE_RegisterManager con una instancia de RE_Register (apartado 8.2) administrada por el administrador. La asociacin debe ser navegable desde el register al manager, pero no necesariamente en el sentido contrario.

Octubre de 2009

33

8.4.5. SubregisterManagement (administracin de subregistro) Para un registro jerrquico, la asociacin condicional SubregisterManagement conecta el RE_RegisterManager con una instancia de RE_SubregisterDescription (8.14) que describe un subregistro administrado por el administrador del registro. La asociacin debe ser navegable desde el register al subregisterManager, pero no necesariamente en el sentido contrario. 8.5. RE_SubmittingOrganization (organizacin remitente) 8.5.1. Introduccin La clase RE_SubmittingOrganization (Figura 11) especifica informacin sobre una organizacin remitente. Tiene 2 atributos y 2 asociaciones. 8.5.2. name (nombre) El atributo name debe representarse como un CharacterString que contiene un denominador compacto y legible por el ser humano que es utilizado para designar a la organizacin remitente.
Ejemplo: ISO TC 211, ISO/IEC SC 24, y ICAO. Nota: Esta norma internacional no necesita que el nombre del administrador del registro sea nico, ya que una organizacin en general, tendr un nombre antes de encargarse de la administracin de un registro.

Re_SubmittingOrganization
Submitter

1..*

+ nane : CharacterString + contact : CI_ResponsibleParty

1 proposal +sponsor

Sponsorship

+register

1..*

proposalInformation

1..*

Re_Register

<<Abstract>> RE_ProposalManagerinformation

Figura 11. RE_SubmittingOrganization

Octubre de 2009

34

8.5.3. contact (contacto) El atributo contact debe presentarse como una instancia de CI_ResponsibleParty (Norma ISO 19115:2003, B.3.2.1, fila 374). El atributo CI_ResponsibleParty.individualName o el atributo

CI_ResponsibleParty.positionName deben identificar, por el nombre o el cargo respectivamente, a una persona que hace de contacto para la informacin sobre la organizacin patrocinadora y las propuestas que se hayan enviado. El atributo CI_ResponsibleParty.contactInfo debe emplear una instancia de CI_Contact (Norma ISO 19115:2003, B.3.2.3, fila 387) para suministrar informacin sobre comunicarse con esa persona. 8.5.4. Sponsorship (patrocinador) La asociacin Sponsorship conecta un RE_SubmittingOrganization con un RE_Register (apartado 8.2) al que ha propuesto cambios. Esta asociacin debe ser navegable desde el register al submitter, pero no necesariamente en el sentido contrario. 8.5.5. Proposal (propuesta) La asociacin Proposal conecta un RE_SubmittingOrganization con las instancias de RE_ProposalManagement Information (apartado 8.9) asociadas con las propuestas que ha enviado. La asociacin debe ser navegable desde proposlInformation a sponsor, pero no necesariamente en el sentido contrario. 8.6. RE_ItemClass (clase de tem) 8.6.1. Introduccin RE_ItemClass (Figura 12) es un detalle de una clase de tems de informacin geogrfica establecidos en una norma tcnica. RE_ItemClass tiene 3 atributos y 3 asociaciones. los medios para

Octubre de 2009

35

Figura 12. RE_ItemClass 8.6.2. name (nombre) El atributo name debe ser representado como un CharacterString que contiene un denominador compacto y legible por el ser humano que ser utilizado para indicar una clase de tems. El name que define una clase de tems almacenada en un registro conforme a esta norma debe: a) indicar de forma exclusiva la clase de tems en el contexto del registro; y b) basarse en la descripcin de la clase de tems utilizado en la norma tcnica de aplicacin (apartado 8.6.3).

Octubre de 2009

36

8.6.3. technicalStandard (norma tcnica) El atributo technicalStandard debe representarse como una instancia de CI_Citation (Norma ISO 19115:2003, B.3.2.1, fila 359) que debe especificar la norma y ms precisamente la parte de ella, de acuerdo con los tems de la clase. 8.6.4. alternativeNames (nombres alternativos) El atributo alternativeNames debe contener un conjunto de instancias de RE_AlternativeName, donde cada una es una traduccin del name del RE_ItemClass a un idioma diferente al del operatingLanguage del RE_Register. 8.6.5. ContentDescription (descripcin del contenido) La asociacin ContentDescription debe conectar el RE_ItemClass con una instancia de RE_Register (apartado 8.2) donde los tems de esa clase estn contenidos. Esta asociacin debe ser navegable desde register a containedItemClass, pero no necesariamente en el sentido contrario. 8.6.6. Categorization (clasificacin) La asociacin Categorization debe conectar cada RE_RegisterItem (apartado 8.8) con la instancia de RE_ItemClass de la cual forma parte. Esta asociacin debe ser navegable desde describedItem a itemClass, pero no necesariamente en el sentido contrario. 8.6.7. SubregisterContentDescription (descripcin del contenido del subregistro) Para un registro jerrquico, la asociacin condicional SubregisterContentDescription debe conectar el RE_ItemClass con la instancia de RE_SubregisterDescription (apartado 8.14) que define un subregistro en el que estn contenidos los tems de esa clase. Esta asociacin debe ser navegable desde subregister a la containedItemClass, pero no necesariamente en el sentido contrario. 8.7. RE_ReferenceSource (fuente de referencia) 8.7.1. Introduccin La clase RE_ReferenceSource (Figura 13) detalla informacin sobre la fuente de especificaciones de RE_RegisterItem que son tomadas de un documento o registro externo. Tiene 1 atributo y 2 asociaciones.

Octubre de 2009

37

8.7.2. citation (mencin) El atributo citation debe usar una instancia de CI_Citation [Norma ISO 19115:2003, B.3.2.1, fila 359] para describir un documento o registro utilizado como fuente externa de tems. 8.7.3. Reference (referencia) La asociacin Reference debe conectar RE_ReferenceSource con un

RE_Register (apartado 8.2) que emplee especificaciones de tems de la fuente definida por RE_ReferenceSource. Esta asociacin debe ser navegable desde register a citation, pero no necesariamente en el sentido contrario.
Re_Register
1..* +itemReference SourceReference Reference

Re_Register
1..*

+register

0..* +citation

Re_ReferenceSource + citation : CI_Citation

1 +sourceCitation

Figura 13. RE_ReferenceSource

8.7.4. SourceReference (referencia de la fuente) La asociacin SourceReference debe conectar con un RE_ReferenceSource desde las instancias de RE_Reference (apartado 8.13) que se encuentran asociados con los tems especficos derivados de tems del documento o registro definido en RE_ReferenceSource. Esta asociacin debe ser navegable desde itemReference a sourceCitation, pero no necesariamente en el sentido contrario. 8.8. RE_RegisterItem (tem del registro) 8.8.1. Introduccin La clase RE_RegisterItem (Figura 14) describe los elementos de informacin que tomar cada tem almacenado en un registro. Tiene 9 atributos y 8 asociaciones. La

Octubre de 2009

38

norma tcnica que establece una clase de tems puede definir elementos adicionales a tomar. 8.8.2. itemIdentifier (identificador del tem) El atributo itemIdentifier debe definirse como un nmero entero positivo (es decir, mayor que cero) que se emplea para expresar exclusivamente ese tem dentro del registro y que est previsto para procesar la informacin. Los valores deben asignarse secuencialmente en el orden en el que los tems se proponen para entrar en el registro. Una vez que se asigna un valor, no debe reutilizarse.
Nota: Cuando un registro contiene tems de distintas clases, cada tem ser identificable de manera nica utilizando solamente el identificador del tem.

8.8.3. name (nombre) El atributo name debe representarse como un CharacterString que contiene un denominador compacto y legible por un ser humano que es utilizado para indicar un concepto de registro. Cada nombre debe: indicar un concepto de tem en el mbito de una clase de tem; y ser una expresin precisa del concepto del tem al que se refiere.
EJEMPLO: Elevacin y Forma de boya.

El name debe ser nico dentro del registro segn las siguientes reglas: Mltiples tems de la misma clase pueden emplear el mismo valor para el name, pero slo uno de esos tems puede tener el status de valid. tems de distintas clases pueden tener el mismo valor para el name. El name puede emplearse para facilitar las bsquedas de tems de inters para un usuario humano del registro.

Octubre de 2009

39

Figura 14. RE_RegistrerItem 8.8.4. status El atributo derivado status debe representarse como una instancia de RE_ItemStatus (apartado 8.20) que define el estado del registro del RE_RegisterItem. El valor se deriva a travs de las asociaciones de Addition y Amendment como se establece en la restriccin: {if (si) exists (existe) -> (self.amendmentInformation.amendmentType = #retirement and (y) self.amendmentInformation.disposition = #accepted and (y) self.amendmentInformation.status = #final) then (entonces) self.status = #retired

Octubre de 2009

40

else if (en otro caso si) exists (existe) -> (self.amendmentInformation.amendmentType = #supersession and (y) self.amendmentInformation.disposition = #accepted and (y) self.amendmentInformation.status = #final) then (entonces) self.status = #superseded else if (en otro caso si) exists (existe) -> (self.additionInformation.disposition = #accepted and (y) self.additionInformation.status = #final) then (entonces) self.status = #valid else (en otro caso) self.status = #notValid endif (fin si)} 8.8.5. dateAccepted (fecha de aceptacin) El atributo condicional dateAccepted debe mostrar la fecha en la que fue aceptada la propuesta para aadir un tem a un registro. La condicin est definida por la siguiente restriccin: {status <> #notValid implica dateAccepted -> notEmpty} El valor procede de la informacin de RE_additionInformation: DateAccepted = self.additionInformation.dateDisposed 8.8.6. dateAmended (fecha de modificacin) El atributo condicional dateAmended debe mostrar la fecha en la que fue aceptada una propuesta para reemplazar o retirar un tem. La condicin est definida por la siguiente restriccin: {status <> #superseded o status = #retired implica dateAmended -> notEmpty} El valor procede de la informacin de RE_AmendmentInformation: dateAmended = self.amendmentInformation.dateDisposed 8.8.7. definition (definicin) El atributo definition debe representarse como un CharacterString que incluye la definicin del concepto representado por ese tem y expresado en el lenguaje operativo del registro. La definition debe ser una expresin que indique claramente la naturaleza, propiedades, campo de aplicacin o cualidades esenciales del concepto tal como se defini en el apartado 7.3.1.
EJEMPLO: El equipamiento que consiste en una plataforma, a menudo encerrada, que sube y baja en un eje vertical para transportar personas, equipos o materiales; un ascensor y La forma de una boya.

Si una definicin es tomada de una fuente externa, RE_Reference (apartado 8.13) debe emplearse para proveer informacin acerca de la fuente, junto con el identificador nico del tem en la fuente externa, cuando est disponible.

Octubre de 2009

41

8.8.8. description (descripcin) El atributo opcional description debe representarse como un CharacterString que contenga una definicin del concepto representado por ese tem y expresado en el lenguaje operativo del registro. La descripcin debe ser una expresin que indique claramente la naturaleza, propiedades, campo de aplicacin o cualidades no esenciales del concepto representado por el tem, y que no estn especificadas por el elemento definition.
Ejemplo 1: Un ascensor puede moverse mediante un sistema de cables situados por encima, por traccin lateral o por empuje hidrulico. Ejemplo 2: La forma de boya se basa generalmente en la parte visible sobre el agua.

8.8.9. fieldOfApplication (campo de aplicacin) El atributo opcional fieldOfApplication debe representarse como un conjunto de instancias de RE_FieldOfApplication, cada una de las cuales debe describir un tipo de uso del tem. El fieldOfApplication puede utilizarse como la base para la creacin de metadatos para remitirlos a motores de bsqueda.
EJEMPLOS Produccin agrcola y Navegacin martima.

8.8.10. alternativeExpressions (expresiones alternativas) El atributo opcional alternativeExpressions debe representarse como un conjunto de instancias de RE_Alternative Expression (apartado 8.15), cada una indican un nombre alternativo, y necesariamente informacin adicional en un escenario diferente al del registro. No pueden existir dos instancias de RE_AlternativeExpression en el conjunto con el mismo valor para locale. 8.8.11. Content (contenido) La asociacin de agregacin Content debe conectar el RE_RegisterItem con el RE_Register (apartado 8.2) en el que se encuentra ubicado. Esta asociacin debe ser navegable desde register a containedItem, pero no necesariamente en el sentido contrario. 8.8.12. Categorization (clasificacin) La asociacin Categorization debe conectar el RE_RegisterItem con la instancia de RE_ItemClass (apartado 8.6) que define la clase de tem a la que pertenece. Esta asociacin debe ser navegable desde el describedItem hasta la itemClass, pero no necesariamente en el sentido contrario.

Octubre de 2009

42

8.8.13. Source (fuente) La asociacin condicional Source debe conectar el RE_RegisterItem con la instancia de RE_Reference (apartado 8.13) que identifica la fuente del tem del registro. Si el tem procede de una fuente externa, esta asociacin debe estar presente. Esta asociacin debe ser navegable desde specifiedItem hasta specificationSource, pero no necesariamente en el sentido contrario. La restriccin {RE_RegisterItem.itemSource.similarity<=3} restringe los cambios de una especificacin de tem que proviene de una specificationSource a cambios de estilo o aadidos de contexto (apartado 7.3.2.1). 8.8.14. Lineage (linaje) La asociacin opcional Lineage conecta el RE_RegisterItem con un conjunto de cero o ms instancias de RE_Reference (apartado 8.13) que provean informacin sobre el desarrollo de la especificacin de un tem. La asociacin debe ser navegable desde el item hasta el specificationLineage, pero no necesariamente en el sentido contrario. 8.8.15. Modification (modificacin) La asociacin condicional Modification debe conectar el RE_RegisterItem con una o ms instancias de otros RE_RegisterItem que lo precedi o reemplaz. La presencia de ms de un sucesor para un tem registrado implica una divisin del concepto representado por ese tem registrado. Cualquier successor debe representar el mismo concepto que su predecessor, o un subconcepto de tal concepto.
Ejemplo: El tipo de fenmeno boya contenido en un registro de catlogo de fenmenos podra reemplazarse por distintos tipos de fenmenos representando subtipos de boya en otro registro. Por el contrario, varios tipos de carretera en un registro podran ser reemplazados por un nico supertipo de ruta de transporte en otro registro de fenmenos.

8.8.16. Addition (adicin) La asociacin Addition debe conectar una instancia de RE_RegisterItem con una o ms instancias de RE_AdditionInformation (apartado 8.10) que tiene informacin sobre el proceso de aadir este RE_RegisterItem al registro. Esta asociacin debe ser navegable desde item hasta additionInformation, pero no necesariamente en el sentido contrario. 8.8.17. Clarification (aclaracin) La asociacin condicional Clarification debe conectar una instancia de RE_RegisterItem con cero o ms instancias de RE_ClarificationInformation (apartado

Octubre de 2009

43

8.11) que tienen informacin sobre el proceso de aclaracin de este RE_RegisterItem. Esta asociacin debe estar presente si hubo alguna propuesta para aclarar el tem. La asociacin debe ser navegable desde item hasta clarificationInformation, pero no necesariamente en el sentido contrario. 8.8.18. Amendment (correccin) La asociacin condicional Amendment debe conectar el RE_RegisterItem con cero o ms instancias de RE_AmendmentInformation (apartado 8.12) que contiene informacin sobre el proceso de corregir este RE_RegisterItem. Esta asociacin debe estar presente si hubo alguna propuesta de modificacin del tem. La asociacin debe ser navegable desde item hasta amendmentInformation, pero no necesariamente en el sentido contrario. 8.9. RE_ProposalManagementInformation (informacin de gestin de propuesta) 8.9.1. Introduccin La clase RE_ProposalManagementInformation (Figura 15) define los elementos de informacin de la gestin, que deben ser guardados para cada propuesta de aadir o modificar un tem del registro. Tiene 8 atributos y 1 asociacin, adems de 3 subclases que mantienen informacin sobre tipos especficos de propuestas.

Octubre de 2009

44

Figura 15. RE_PropasalManagementInformation 8.9.2. dateProposed (fecha de la propuesta) El atributo dateProposed debe representarse como una instancia de la clase <<Date>> (Norma ISO/TS 19103:2005, 6.5.2.7) y especifica la fecha en la que el tem ingresa en el registro.
Ejemplo: 2002-11-27.

8.9.3. justification (justificacin) El atributo justification debe representarse como un CharacterString que indique por qu tendra que implementarse la modificacin propuesta.

Octubre de 2009

45

8.9.4. status (estado) El atributo status debe representarse como una instancia de RE_DecisionStatus que identifica la situacin de la modificacin propuesta en el procedimiento de aprobacin. 8.9.5. disposition (disposicin) El atributo condicional disposition debe representarse como una instancia de RE_Disposition que define la disposicin de la propuesta. La condicin se describe en la restriccin {status<>#pending implica disposition -> notEmpty}, que significa que un valor debe proveerse si el valor del status es tentative o final. 8.9.6. date Disposed (fecha de disposicin) El atributo condicional dateDisposed debe representarse como una instancia de la clase <<Date>> (Norma ISO/TS 19103:2005, 6.5.2.7) y especifica precisamente la fecha desde la que se puede disponer la propuesta. La condicin se describe mediante la restriccin {status<>#pending implica que dateDisposed -> notEmpty} que indica que debe proporcionarse una fecha si el valor del status es tentative o final. La fecha debe ser revisada cuando el valor del status se cambie de tentative a final. 8.9.7. controlBodyDecisionEvent (evento de decisin del organismo de control) El atributo opcional controlBodyDecisionEvent debe representarse como un CharacterString que identifica un acontecimiento asociado con la decisin del organismo de control en relacin a la modificacin propuesta. 8.9.8. controlBodyNotes (notas del organismo de control) El atributo opcional controlBodyNotes debe representarse como un

CharacterString que contiene notas o comentarios relativos a la decisin del organismo de control respecto a la propuesta. Las notas individuales dentro de los comentarios deberan indicar fecha. 8.9.9. registerManagerNotes (notas del administrador del registro) El atributo opcional registerManagerNotes debe representarse como un CharacterString que contenga notas relacionadas con el manejo de la propuesta por el administrador del registro. Las notas individuales dentro de los comentarios deberan indicar fecha.

Octubre de 2009

46

8.9.10. Proposal (propuesta) La asociacin Proposal debe conectar una instancia de

RE_ProposalManagementInformation con el RE_Submitting Organization (apartado 8.5) que ha propuesto que el tem asociado sea aadido o modificado. Esta asociacin debe ser navegable desde proposalInformation hasta sponsor, pero no necesariamente en el sentido contrario. 8.10. RE_AdditionInformation (informacin de adicin) 8.10.1. Introduccin La subclase RE_AdditionInformation contiene informacin de la gestin acerca de la propuesta de aadir un tem a un registro. Tiene una asociacin aadida a los atributos y asociaciones heredadas de RE_ProposalManagement Information. 8.10.2. Addition (adicin) La asociacin Addition debe conectar una instancia de RE_AdditionInformation con la instancia de RE_RegisterItem que ha propuesto aadir. La asociacin debe ser navegable desde item hasta additionInformation, pero no necesariamente en el sentido contrario. Una multiplicidad de additionInformation mayor que 1 indica que una o ms propuestas de aadir el tem al registro fueron retiradas o no aceptadas. 8.11. RE_ClarificationInformation (informacin de aclaracin) 8.11.1. Introduccin La subclase RE_ClarificationInformation contiene informacin de la gestin acerca de una propuesta para aclarar un tem de un registro. Tiene 1 atributo y 1 asociacin adems de los atributos y asociaciones heredados de RE_ManagementInformation. 8.11.2. proposedChange (cambio propuesto) El atributo proposedChange debe representarse como un CharacterString que incluye el detalle de la aclaracin que identifica a los elementos del tem del registro que se han modificado y el valor anterior y posterior de cada uno.
Ejemplo: La definicin de este tem ha sido modificada para corregir un error tipogrfico. La palabra mal escrita fenmno se cambi a fenmeno.

8.11.3. Clarification (aclaracin) La asociacin Clarification debe conectar una instancia de

RE_ClarificationInformation con la instancia de RE_RegisterItem que cuya describe la aclaracin. La asociacin debe ser navegable desde el item hasta la

Octubre de 2009

47

clarificationInformation, pero no necesariamente en el sentido contrario. 8.12. RE_AmendmentInformation (informacin de correccin) 8.12.1. Introduccin La subclase RE_AmendmentInformation contiene informacin de la gestin acerca de la propuesta de corregir un tem de un registro. Tiene 1 atributo y 1 asociacin aparte de los atributos y asociaciones heredados de RE_ProposalManagementInformation. 8.12.2. amendmentType (tipo de modificacin) El atributo amendmentType debe representarse como una instancia de RE_AmendmentType que describe el tipo de correccin propuesta. 8.12.3. Amendment (correccin) La la asociacin La Amendment asociacin debe ser conectar navegable una desde instancia item de hasta

RE_AmendmentInformation con la instancia de RE_RegisterItem para la que se propuso modificacin. debe amendmentInformation, pero no necesariamente en el sentido contrario. Una multiplicidad de amendmentInformation mayor que 1 implica que una o ms propuestas de reemplazar o retirar el tem fueron retiradas o no aceptadas. 8.13. RE_Reference (referencia) 8.13.1. Introduccin La clase RE_Reference (Figura 16) indica la informacin acerca de la fuente y/o linaje de un RE_RegisterItem especfico (apartado 8.8) proveniente de un documento o registro externo. Tiene 4 atributos y 3 asociaciones. 8.13.2. itemIdentifierAtSource (identificador del tem en la fuente) El atributo itemIdentifierAtSource debe representarse como un CharacterString que provee el valor del identificador del tem en el documento o registro fuente de donde proviene la especificacin del RE_RegisterItem (apartado 8.8).

Octubre de 2009

48

8.13.3. similarity (similitud) El atributo similarity debe usar un valor dado en el <<CodeList>>

RE_SimilarityToSource (apartado 8.24) que describa el tipo de modificacin que se realizado a la especificacin del tem, con respecto a la especificacin del tem en la fuente externa.

Figura 16. RE_Reference 8.13.4. referenceText (texto de referencia) El atributo opcional referenceText debe representarse como un CharacterString que puede ser empleada para proveer una copia de la documentacin del tem de RE_ReferenceSource.
Nota: Se intenta que este atributo sea utilizado en los casos en que RE_ReferenceSource no est disponible fcilmente para los usuarios del registro.

8.13.5. notes (notas) El atributo opcional notes debe representarse como un CharacterString que puede ser empleado para suministrar informacin adicional de cmo se origina la especificacin de un tem del registro en una fuente externa. 8.13.6. Source (fuente) La asociacin Source debe conectar un RE_Reference con el RE_RegisterItem (apartado 8.8) para el que provee informacin acerca de la fuente. Esta asociacin debe
Octubre de 2009 49

ser navegable desde specifiedItem hasta specificationSource, pero no necesariamente en el sentido contrario. Las modificaciones a una especificacin del tem que proviene de una specificationSource estn restringidas segn se muestra en el apartado 8.8.13. 8.13.7. Lineage (linaje) La asociacin opcional Lineage debe conectar un conjunto de cero o ms RE_Reference al RE_RegisterItem (apartado 8.8) para el que provee informacin sobre la derivacin de la especificacin del tem. Esta asociacin debe ser navegable desde el item hasta el specificationLineage, pero no necesariamente en el sentido contrario. 8.13.8. SourceReference (referencia de la fuente) La asociacin SourceReference debe conectar un RE_Reference con el RE_ReferenceSource (apartado 8.7) que especifica la fuente externa desde la que se tom la especificacin del tem. Esta asociacin debe ser navegable desde itemReference hasta la sourceCitation, pero no necesariamente en el sentido contrario.

Figura 17. RE_SubregisterDescription

Octubre de 2009

50

8.14. RE_SubregisterDescription 8.14.1. Introduccin RE_SubregisterDescription (Figura 17) es una subclase de RE_RegisterItem que debe ser utilizado en el registro principal de un registro jerrquico para definir a cada uno de los subregistros adheridos. Hereda 9 atributos y 8 asociaciones de RE_RegisterItem. Su semntica no se modifica, sin embargo algunos dependen de restricciones o condiciones adicionales especificadas en este apartado. Adems,

RE_SubregisterDescription tiene 2 atributos y 2 asociaciones propios de la clase.

Nota: Debido a que un subregistro es un tipo de registro, est contenido en una instancia de RE_Register que se define a s misma (apartado 8.2.1). El RE_SubregisterDescription contiene informacin similar sobre el subregistro, que a su vez est incluida dentro del registro principal.

8.14.2. name (nombre) RE_SubregisterDescription hereda el atributo name de RE_RegisterItem. El valor del name debe ser igual al valor del RE_Register.name como se muestra en el subregistro. 8.14.3. description (descripcin) El atributo opcional heredado description puede emplearse para aportar la informacin especificada por el RE_Register.contentSummary en el subregistro. 8.14.4. Categorization (clasificacin) La asociacin Categorization se hereda de RE_RegisterItem. Debe conectar una instancia de RE_SubregisterDescription con la itemClass que identifica a esta norma como fuente de la especificacin de la clase RE_SubregisterDescription. Por lo tanto, los valores de los atributos del objeto identificado por itemClass estn sujetos a siguientes restricciones: {self.itemClass.name = Subregister} {self.itemClass.technicalStandard.CI_Citation.title = Norma ISO 19135 Informacin geogrfica Procedimientos para el registro de tems de informacin geogrfica} {self.itemClass.technicalStandard.CI_Citation.alternateTitle = ISO 19135:2004} {self.itemClass.technicalStandard.CI_Citation.date:CI_Date.date = 2004} {self.itemClass.technicalStandard.CI_Citation.otherCitatonDetails = Apartado 8.14} 8.14.5. uniformResourceIdentifier (identificador de recurso uniforme) El atributo uniformResourceIdentifier debe representarse como una instancia de CI_OnLineResource (Norma ISO 19115:2003, B.3.2.5, fila 396) donde el atributo las

Octubre de 2009

51

OnLineResource.function tiene el valor information (002) (Norma ISO 19115:2003, B.5.3, fila 3) y el valor correspondiente del atributo OnLineResource.linkage especifica un recurso que provee acceso a todo el contenido del subregistro. 8.14.6. operatingLanguage (idioma operativo) El atributo operatingLanguage debe representarse como una instancia de la clase RE_Locale (apartado 8.17) que es utilizada para indicar el idioma, la informacin del pas y la codificacin de caracteres para la correcta interpretacin del contenido de las cadenas de caracteres del subregistro. 8.14.7. SubregisterManagement (administracin del subregistro) La asociacin SubregisterManagement debe conectar un

RE_SubregisterDescription con una instancia de RE_RegisterManager (apartado 8.4) que provee informacin acerca del administrador de registro que administra el subregistro. La asociacin debe ser navegable desde subregister hasta subregisterManager, pero no necesariamente en el sentido contrario. 8.14.8. SubregisterContentDescription (descripcin del contenido del subregistro) La asociacin SubregisterContentDescription conecta un

RE_SubregisterDescription a una o ms instancias de RE_ItemClass (apartado 8.6), donde cada una describe las caractersticas de una clase de tems contenidos en el subregistro. La asociacin debe ser navegable desde subregister hasta la containedItemClass, pero no necesariamente en el sentido contrario. 8.15. RE_AlternativeExpression (expresin alternativa)

8.15.1. Introduccin La clase RE_AlternativeExpression (figura 18) es un tipo de datos que se emplea para aportar informacin sobre un tem de un registro en un lenguaje alternativo. Tiene 4 atributos y 1 asociacin. Pueden especificarse subclases de RE_AlternativeExpression para aadir atributos adicionales adecuados a las clases particulares de tems.
Ejemplo: Una especificacin para un registro de elementos de metadatos podra identificar a una subclase de RE_AlternativeExpression que incluya los campos del diccionario de datos indicados en la Norma ISO 19115:2003 (obligacin/condicin, tipo de datos, y dominio) como atributos adicionales.

8.15.2. name (nombre) El atributo name debe representarse como un CharacterString donde el contenido cumple con los requisitos de RE_Register Item.name, a menos que el escenario

Octubre de 2009

52

aplicable sea el indicado en RE_AlternativeExpression.locale. 8.15.3. definition (definicin) El atributo opcional definition debe representarse como un CharacterString donde el contenido cumple con los requisitos de RE_RegisterItem.definition, a menos que el escenario aplicable sea el indicado en RE_AlternativeExpression.locale. 8.15.4. description (descripcin) El atributo opcional descripcin debe representarse como un CharacterString donde el contenido cumple con los requisitos de RE_RegisterItem.description, a menos que el escenario aplicable sea el indicado en RE_AlternativeExpression.locale. 8.15.5. fieldOfApplication (campo de aplicacin) El atributo opcional fieldOfApplication debe representarse como un conjunto de instancias de RE_FieldOfApplication donde el contenido cumple con los requisitos de RE_Registeritem.fieldOfApplication, a menos que el escenario aplicable sea el indicado en RE_AlternativeExpression.locale.

<<DataType>> RE_AltemativeExpression + name : CharacterString + definition[0..1] : CharacterString + description[0..1] : CharacterString + fielOfApplication[0..1] : Set<RE_FieldOfApplication>

+Expressio

0..*

<<DataType>> RE_Locale Milieu +locale 1 + name : CharacterString + languaje : languajeCode + country : CharacterString + CharacterEncoding : MD_ CharacterSetCode + citation : CI_Citation

Figura 18. RE_SubregisterExpression y Re_locale

Octubre de 2009

53

8.15.6. Milieu (contexto) La asociacin Milieu conecta una instancia de RE_AlternativeExpression con la instancia de RE_Locale (apartado 8.17) aplicable a los valores de los atributos de esta instancia de RE_AlternativeExpression. RE_Locale debe ser una de las contenidas en la instancia de RE_ItemClass.alternativeLanguages (apartado 8.6.4) que es asociado con un tem del registro. La asociacin debe ser navegable desde expression hasta locale, pero no necesariamente en el sentido contrario. 8.16. RE_AlternativeName (nombre alternativo) 8.16.1. Introduccin La clase RE_AlternativeName (Figura 12) es un tipo de datos empleados para proveer el nombre de una clase de tem en un lenguaje alternativo. Tiene 1 atributo y 1 asociacin. 8.16.2. name (nombre) El atributo name debe representarse como un CharacterString. 8.16.3. language (idioma) La asociacin language conecta una instancia de RE_AlternativeName con la instancia de RE_Locale (apartado 8.17) que indica el lenguaje utilizado para el nombre alternativo. 8.17. RE_Locale (escenario) 8.17.1. Introduccin La clase RE_Locale (figura 18) tiene 5 atributos y 1 asociacin. Y adems, provee informacin sobre lenguajes que se utilizan en el registro. 8.17.2. name (nombre) El atributo name debe representarse como un CharacterString que detalle el escenario.
Ejemplo: Gals/Galico

8.17.3. language (idioma) El atributo language debe contener como valor un cdigo de lenguaje de 3 caracteres como muestra la Norma ISO 639-2.
Nota: La lista de cdigos conservada por la autoridad de registro ISO 639-2, puede encontrarse en la direccin URL http://www.loc.gov/standards/iso639-2/langcodes.html.

Octubre de 2009

54

8.17.4. country (pas) El atributo country debe representarse como un CharacterString que tiene un cdigo de pas de 3 dgitos, como muestra la Norma ISO 3166-1.
Nota: Se puede encontrar la lista de cdigos en la direccin URL http://ftp.ics.uci.edu/pub/ietf/http/related/iso3166.txt o en la Agencia de Conservacin de la Norma ISO 3166 en la direccin URL http://www.iso.ch/iso/en/prods-services/iso3166ma/index.html.

8.17.5. characterEncoding (codificacin de caracteres) El atributo characterEncoding debe representarse como una instancia de MD_CharacterSetCode (Norma ISO 19115:2003, B.5.10) que define el nombre de la norma de codificacin de caracteres empleada. 8.17.6. citation (mencin) El atributo opcional citation debe representarse como una instancia de CI_Citation (Norma ISO 19115:2003, B.3.2.1, fila 359) que define un recurso que provee ms informacin del escenario.
Ejemplo: Una instancia de CI_Citation podra proveer informacin acerca de un dialecto determinado de un idioma identificado por el escenario, o sobre algunos otros aspectos de la presentacin de informacin culturalmente relevantes, como por ejemplo un mtodo determinado de formato de nmeros.

8.17.7. Milieu (contexto) La asociacin condicional Milieu debe conectar una instancia de RE_Locale con las instancias de RE_AlternativeExpression que emplean ese escenario. La asociacin debe ser navegable desde la expresin hasta el locale, pero no necesariamente en el sentido contrario. La asociacin es condicional ya que RE_Locale tambin se emplea para identificar el operatingLanguage de un registro (apartado 8.2.5).
Ejemplo: Una instancia de RE_Locale que identifica a Ingls, segn se emplea en los Estados Unidos de Amrica, tendra los siguientes valores de atributos: name: US English language: eng country: 840 characterEncoding: 009 citation: (no utilizado)

8.18. RE_Version (versin) 8.18.1. Introduccin La clase de tipo de datos RE_Version (Figura 8) tiene 2 atributos.

Octubre de 2009

55

8.18.2. number (nmero) El atributo number debe representarse como una CharacterString limitada que define la versin. La cadena de caracteres debe ser de la forma <primer nmero entero positivo> <punto> <segundo nmero entero positivo><caracteres alfabticos> (#.#a), donde: a) <primer nmero entero positivo> (uno o ms dgitos) debe especificar la denominacin mayor de la versin; b) <punto> (.) delimitar el <primer nmero entero positivo> del <segundo nmero entero positivo> cuando este ltimo exista; c) <segundo nmero entero positivo> (uno o ms dgitos) opcionalmente deber especificar la denominacin menor de la versin; y d) <letras> (uno o ms caracteres) opcionalmente especificar la denominacin de la subversin menor.
Ejemplo: 2.1.a.

8.18.3. date (fecha) El atributo date debe representarse como una instancia de la clase <<Date>> (Especificacin Tcnica ISO/TS 19103:2005, apartado 6.5.2.7) que define la fecha de la versin, la que puede estar abreviada.
Ejemplo: 2002-10-21.

8.19. RE_FieldOfApplication (campo de aplicacin) 8.19.1. Introduccin RE_FieldOfApplication (Figura 14) es un tipo de datos que se emplea para proveer informacin acerca del uso de un tem del registro. Tiene 2 atributos, nombre y descripcin. 8.19.2. name (nombre) El atributo name debe representarse como un CharacterString que se usa para identificar el campo de aplicacin.
Ejemplo: Produccin agrcola, Navegacin martima.

8.19.3. description (descripcin) El atributo opcional description debe representarse como un CharacterString que provee una descripcin del campo de aplicacin.
Ejemplo: Relacionado con la ciencia, el arte y negocio de cultivar el suelo, producir cosechas y

Octubre de 2009

56

criar animales., Relacionado con la ciencia o el arte de pilotear barcos o buques de un lugar a otro por el mar.

8.20. RE_ItemStatus (estado del tem) RE_ItemStatus (Figura 14) es una <<Enumeration>> que define el estado de un tem del registro (apartado 8.8.4). El dominio de RE_ItemStatus se muestra en la Tabla 2.

Tabla 2. Valores de RE_ItemStatus

Valor notValid (no vlido) valid (vlido) superseded (reemplazado) Significado El tem ingres en el registro, pero el organismo de control no acept la propuesta de aadirlo. El tem fue aceptado, se recomienda su uso, y no ha sido reemplazado ni retirado. El tem ha sido reemplazado por otro tem y no se recomienda ms su uso. Se decidi que ya no se recomienda el uso del tem. No fue reemplazado por otro tem.

retired (retirado)

8.21. RE_DecisionStatus (estado de la decisin) RE_DecisionStatus (Figura 15) es una <<Enumeration>> que define el estado de una decisin referente a una propuesta para aadir o modificar un tem del registro (8.9.4). El dominio de RE_DecisionStatus se muestra en la Tabla 3.

Tabla 3. Valores de RE_DecisionStatus

Valor pending (pendiente) tentative (provisional) final (final) Significado No se ha tomado ninguna decisin. Se ha tomado una decisin, pero todava se puede apelar. Se ha tomado una decisin y se ha terminado el plazo para apelar o se ha resuelto la apelacin.

8.22. RE_Disposition (situacin) RE_Disposition (Figura 15) es una <<Enumeration>> que provee los valores para detallar la situacin de una propuesta de aadir o modificar un tem del registro (apartadp 8.9.5). El dominio de RE_Disposition se muestra en la Tabla 4.

Octubre de 2009

57

Tabla 4. Valores de RE_Disposition

Valor withdrawn (retirada) accepted (aceptada) notAccepted (no aceptada) Significado La organizacin remitente retir la propuesta. El organismo de control decidi aceptar la propuesta. El organismo de control decidi no aceptar la propuesta.

8.23. RE_AmendmentType (tipo de modificacin) RE_AmendmentType (Figura 15) es una <<Enumeration>> que provee los valores para detalaar el tipo de modificacin solicitada por una propuesta de modificar un tem del registro (apartado 8.12.2). El dominio de RE_AmendmentType se muestra en la Tabla 5.

Tabla 5. Valores de RE_AmendmentType

Valor supersession (reemplazo) retirement (retirada) Significado La propuesta requiere que un tem sea reemplazado La propuesta requiere que un tem sea retirado

8.24. RE_SimilarityToSource (similitud con la fuente) RE_SimilarityToSource (Figura 16) es un <CodeList> que identifica el tipo de modificacin que se hizo a una especificacin de un tem referida a la especificacin del tem en una fuente externa (apartado 8.13.3). El dominio de RE_SimilarityToSource se muestra en la Tabla 6.

Octubre de 2009

58

Tabla 6. Valores de RE_SimilarityToSource

Cdigo 1 Valor identical (idntico) Significado No se realiz ningn cambio a la especificacin. El estilo de la especificacin fue modificado para equipararlo con el estilo y la estructura de otras especificaciones en el registro que ha importado la especificacin. La especificacin contiene informacin acerca su contexto que no est explcito en la fuente externa. La especificacin del tem del registro fue generalizada para que tenga un significado ms amplio que el tem definido en la fuente externa. La especificacin del tem del registro fue concretada para que tenga un significado menos amplio que el del tem especificado en la fuente externa. La naturaleza de las diferencias entre el tem del registro y el tem similar en la fuente externa no se especifica.

restyled (rediseado)

contextAdded (contexto aadido) (generalizacin) generalization

specialization (especializacin) unspecified (no especificado)

Octubre de 2009

59

Anexo A (Normativo) Conjunto de pruebas genricas A.1. Conformidad general A.1.1. Responsabilidades del propietario del registro a) Propsito de la prueba: Comprobar que el propietario del registro ha identificado a un administrador, y un organismo de control del registro ha especificado los criterios que establecen qu organizaciones pueden actuar como organizaciones remitentes, y se ha establecido un procedimiento para procesar las apelaciones a las decisiones que tom el organismo de control. b) Mtodo de prueba: Requerir informacin acerca del registro al propietario del registro y/o al administrador del registro. Comprobar que la informacin requerida se incluye. c) Referencia: apartado 5.2. d) Tipo de prueba: Bsico. A.1.2. Responsabilidades del administrador del registro a) Propsito de la prueba: Comprobar que el administrador del registro distribuye un paquete de informacin que contenga una descripcin del registro y la forma de presentar las propuestas, y que el administrador del registro provea informes al propietario del registro en los intervalos definidos por el propietario del registro. b) Mtodo de prueba: Requerir una copia del paquete de informacin y controlar que est completo. Solicitar al propietario del registro copias de los informes del administrador del registro. c) Referencia: apartado 5.3. d) Tipo de prueba: Bsico. A.1.3. Presentacin por organizaciones remitentes acreditadas a) Propsito de la prueba: Controlar que todas las organizaciones remitentes cumplan con los criterios determinados por el propietario del registro, y que los tems del registro fueron propuestos por organizaciones remitentes acreditadas. b) Mtodo de prueba: Obtener una copia de los criterios determinados por el propietario del registro para las organizaciones remitentes y analizar la lista de organizaciones remitentes para comprobar que todas cumplen con tales criterios.

Octubre de 2009

60

Comprobar que cada una de las organizaciones remitentes asociadas con cada uno de los tems de una muestra del registro, se incluyan en la lista de organizaciones remitentes. c) Referencia: apartados 5.4.1 y 8.9.10. d) Tipo de prueba: Bsico. A.1.4. Procedimientos de gestin a) Propsito de la prueba: Comprobar que el registro sea administrado segn las reglas definidas en esta norma internacional. b) Mtodo de prueba: Controlar los procedimientos descriptos en el paquete de informacin distribuido por el administrador del registro. d) Referencia: apartado 6. c) Tipo de prueba: Aptitud. A.1.5. Contenido del registro a) Propsito de la prueba: Comprobar que los tems del registro contengan el contenido mnimo especificado. .

b) Mtodo de prueba: Analizar cada una de las entradas de una muestra del registro para asegurar que se incluyen todos los elementos de informacin definidos en esta norma internacional y por la norma tcnica que describe la clase de tem correspondiente. c) Referencia: apartado 8. d) Tipo de prueba: Aptitud. A.1.6. Publicacin de los contenidos del registro a) Propsito de la prueba: Controlar que los contenidos del registro estn disponibles al pblico. b) Mtodo de prueba: Analizar el paquete de informacin que distribuye el administrador del registro. Acceder al sitio web o al documento procesable electrnicamente y observar la informacin disponible. c) Referencia: apartado 6.4. d) Tipo de prueba: Aptitud. A.2. Registros jerrquicos A.2.1 Registro principal a) Propsito de la prueba: Comprobar que el registro principal provea la informacin solicitada sobre los subregistros.

Octubre de 2009

61

b) Mtodo de prueba: Acceder al registro principal y requerir informacin acerca de uno o ms subregistros. Examinar el resultado para controlar que estn presentes todos los elementos exigidos. c) Referencia: apartado 2.3. d) Tipo de prueba: Bsico. A.2.2. Subregistro a) Propsito de la prueba: Comprobar que el subregistro est conforme a la descripcin proporcionada por el registro principal. b) Mtodo de prueba: Acceder a la instancia de RE_Register que define al propio registro y comparar la informacin que contiene con la informacin de la instancia de RE_SubregisterDescription que describe este subregistro en el registro principal. c) Referencia: apartado 2.3. d) Tipo de prueba: Bsico. A.3. Registros establecidos por ISO/TC 211 A.3.1. Mantenimiento por un administrador de registro autorizado a) Propsito de la prueba: Comprobar que un administrador de registro autorizado mantiene el registro. b) Mtodo de la prueba: Comprobar la lista de autoridades registradoras que se encuentran en la Web de ISO, para garantizar que la organizacin haya sido autorizada por el ISO TMB para actuar como un administrador de registro para la norma tcnica que especifica la clase de tem correspondiente. c) Referencia: apartado C.2. d) Tipo de prueba: Bsico. A.3.2. Presentacin por parte de organizaciones remitentes acreditadas a) Propsito de la prueba: Comprobar que todas las organizaciones remitentes cumplan con los criterios definidos por ISO/TC 211, y que los tems del registro fueron presentados por organizaciones remitentes acreditadas. b) Mtodo de prueba: Analizar la lista de organizaciones remitentes para garantizar que todas cumplen los criterios especificados en esta norma. Controlar que cada organizacin remitente est asociada con un tem de una muestra del registro para asegurar que cada una figure en la lista como una organizacin remitente. c) Referencia: apartado C.6. d) Tipo de prueba: Bsico.

Octubre de 2009

62

Anexo B (Informativo) Notacin UML B.1. Introduccin Este anexo se provee una descripcin breve de la notacin UML segn lo especificado en la Norma ISO/IEC 19501-1 y en la ISO/TS 19103:2005, y que es utilizada en los diagramas UML de esta norma.

<<Estereotipo>> NombreDeClase +nombreDeAtributo: TipoDeDatos +nombreDeOperacin(nombreDeParmetro1: TipoDeDatos): TipoDeDatos de salida

Figura B.1. Clase UML B.2. Clase Una clase UML (Figura B.1) representa un concepto dentro del sistema que se va ha modelarse. Es una descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, mtodos, relaciones y semntica. Una clase se dibuja como un rectngulo con tres compartimentos divididos por lneas horizontales. La parte superior contiene el nombre de la clase y otras propiedades generales de la misma (incluyendo al estereotipo); la parte intermedia contiene una lista de atributos y la parte inferior incluye una lista de operaciones. Las partes de los compartimentos de atributos y operaciones pueden omitirse para simplificar un diagrama. Su omisin no supone que no existan los mismos.
Nota: Esta norma internacional no especifica alguna operacin ni mtodo.

La Norma ISO/TS 19103:2005 establece que un nombre de una clase no debe incluir espacios en blanco y que las palabras individuales del nombre deben comenzar con mayscula. B.3. Estereotipo Los estereotipos extienden la semntica, pero no la estructura de los tipos y clases preexistentes. Un estereotipo se usa para clasificar (o marcar) otros elementos UML para que se comporten como si fuesen instancias de una nueva clase de metamodelo "virtual", cuya forma est basada en las clases base preexistentes. Un estereotipo puede agregar valores y restricciones adicionales. Todos los elementos del
Octubre de 2009 63

modelo que se clasifican a travs de un estereotipo definido tienen estos valores y restricciones. Los estereotipos de nivel de clase usados en esta norma incluyen: a) <<DataType>> establecido en la Norma ISO/IEC 19501, es un descriptor de un conjunto de valores que no poseen identidad (de existencia independiente y la posibilidad de efectos secundarios). Los tipos de datos contienen tipos predefinidos primitivos y tipos que pueden ser definidos por el usuario. De esta manera, un tipo de datos es una clase con pocas o ninguna operacin, donde la funcin principal es mantener el estado abstracto de otra clase para transmitir, guardar, codificar o guardar con continuidad. b) <<Enumeration>> especificado en la Norma ISO/IEC 19501, es un tipo de datos con instancias que forman una lista de valores literales nominales. Se declaran el nombre de la enumeracin y su valor literal. La enumeracin representa una lista corta de valores potenciales bien entendidos dentro de una clase. Ejemplos clsicos son los Booleanos que pueden tener slo dos (o tres) valores potenciales VERDADERO, FALSO (y NULO). La mayora de las enumeraciones son codificadas como un conjunto secuencial de nmeros enteros, a menos que se indique lo contrario. Generalmente, la codificacin real slo se emplea con compiladores de lenguajes de programacin. c) <<CodeList>>, establecido en la Norma ISO/TS 19103:2005, es una enumeracin flexible que usa cadenas de valores a travs de una vinculacin con la clave del tipo de Diccionario y devuelve valores como tipos de cadena, por ejemplo Diccionario (Cadena, Cadena). Un CodeList es ventajoso para expresar una lista larga de valores potenciales. Si todos los elementos de la lista son conocidos, se debe emplear un Enumeration; si solamente son conocidos los valores probables de los elementos, se debe usar un CodeList. Las listas de cdigos enumerados pueden codificarse en base a una norma, como la Norma ISO 3166-1. Un CodeList es ms probable que muestre sus valores al usuario, y por tanto son a menudo nemotcnicos. Distintas herramientas suelen ser usadas en distintos esquemas de codificacin (disponibles con tablas de traduccin a otros esquemas de codificacin). B.4. Atributo Un atributo representa una caracterstica comn a los objetos de una clase. Se detalla un atributo a travs de una cadena de texto que puede ser analizada por elementos que describen las propiedades del atributo: visibilidad nombre [multiplicidad]: expresin-tipo = valor- inicial donde

Octubre de 2009

64

visibilidad puede ser pblico (indicado por un signo +) o privado (indicado por un signo -). nombre es una cadena de caracteres. La Norma ISO/TS 19103:2005 establece que el nombre de un atributo no deber incluir espacios en blanco, debe comenzar con una letra minscula, y las siguientes palabras del nombre deben empezar con maysculas. multiplicidad especifica el nmero de valores que una instancia de una clase puede tener para un atributo dado. La notacin se detalla en el apartado B.10. Cuando no se muestra la multiplicidad de un atributo en un diagrama, este tiene el valor 1 por defecto. expresin-tipo identifica el tipo de datos del atributo. valor- inicial especifica el valor por defecto para el atributo, si existe. B.5. Asociacin Una asociacin (Figura B.2.) es una relacin semntica entre clases que define las conexiones entre sus instancias. Una asociacin se grafica como una lnea continua que une dos rectngulos de clase. Una asociacin puede tener un nombre, representado como una cadena de caracteres ubicados cerca de la lnea, pero no cerca de sus extremos. La Norma ISO/TS 19103:2005 establece que un nombre de una asociacin no deber incluir espacios en blanco y que cada una de las palabras que forman el nombre deben comenzar con mayscula. En los extremos de la asociacin se ubica la informacin relativa a la clase de ese extremo de la asociacin, incluyendo la multiplicidad y nombre del rol.

Figura B.2. Asociaciones UML

Octubre de 2009

65

B.6. Nombre del rol El nombre del rol ubicado en el extremo de una asociacin define el comportamiento de la clase de ese extremo con respecto a la otra clase situada en el otro extremo de la asociacin. En la Figura B.2, el rol de Alfa describe el rol que la clase denominada Alfa tiene respecto a la clase denominada Beta. Un nombre del rol se representa como una cadena de caracteres. La Norma ISO/TS 19103:2005 establece que un nombre de rol no deber incluir espacios en blanco, que debe comenzar con minscula y que las restantes palabras que compongan el nombre empiezan con maysculas. B.7. Navegabilidad Una flecha en el extremo de la lnea de una asociacin indica que la navegacin es en direccin a la clase agregada a la flecha. Es decir, que la informacin mantenida en esa clase es accesible desde la clase ubicada al otro extremo de la asociacin. Las flechas pueden estar en un extremo de la lnea, en los dos extremos o en ninguno. Esta norma aplica la prctica de mostrar flechas solamente en el caso de que las trayectorias de navegacin sean posibles slo en una direccin. Se admite que todas las dems asociaciones son navegables en ambos sentidos. En la Figura B.2, NombreAsociacin2 es navegable de Gamma a Delta, pero no en direccin contraria. B.8. Agregacin Las asociaciones pueden usarse para exponer las relaciones de agregacin o composicin entre clases. Un diamante hueco en el extremo de una asociacin muestra que la clase de ese extremo es un agregado de instancias de la clase del otro extremo de la asociacin. Por ejemplo, la clase Gamma, de la Figura B.2, es un agregado de cero o ms instancias de la clase Delta. La agregacin es considerada una forma dbil de composicin. Los tems de una agregacin pueden existir independientemente de la agregacin, y pueden ser miembros de ms de una agregacin. B.9. Composicin Un diamante relleno en el extremo de una asociacin indica que la clase en ese extremo est compuesta de instancias de la clase ubicada al otro extremo de la asociacin. Por ejemplo, la clase psilon de la Figura B.2 esta compuesta de cero o ms instancias de la clase Phi. Los tems de una composicin no pueden existir independientemente de la clase de composicin, ni pueden pertenecer a ms de una clase de composicin.

Octubre de 2009

66

B.10. Multiplicidad La multiplicidad define el nmero de instancias de una clase que pueden asociarse con una clase ubicada en el otro extremo de la asociacin.

Figura B.3. Multiplicidad UML

Los valores que se muestran en la Figura B.3 son vlidos. Tienen el siguiente significado: una instancia, o ninguna, de Alfa puede estar asociada con una instancia de Beta; una instancia, o ninguna, de Beta puede estar asociada con una instancia de Alfa; una instancia y slo una, de Gamma puede estar asociada con una instancia de Delta; si n es un nmero entero, n instancias y slo n, de Delta pueden estar asociadas con una instancia de Gamma; si n1 y n2 son nmeros enteros y n2 > n1, el nmero de instancias de psilon que pueden asociarse con una instancia de Phi puede estar en el rango de n1 a n2; si n es un nmero entero, n o ms instancias de Phi pueden estar asociadas con una instancia de psilon. B.11. Generalizacin La Norma ISO/IEC 19501 describe una generalizacin (Figura B.4) como una relacin taxonmica entre un elemento ms general y uno ms especfico. El elemento ms especfico es totalmente consistente con el elemento ms general y tiene informacin adicional. Una instancia de elemento ms especfico puede usarse cuando se permite un elemento ms general. La generalizacin es mostrada como una lnea continua desde el elemento ms especfico, como una subclase, que llamamos hijo al

Octubre de 2009

67

elemento ms general, como una superclase, que llamamos raz, con un tringulo hueco en el extremo de la lnea donde se encuentra con el elemento ms general. En la Figura B.4 se muestran dos relaciones de generalizacin.

Figura B.4. Generalizacin UML

B.12. Elementos derivados Un elemento derivado, como un atributo o un nombre de rol, es uno cuyo valor se puede calcular a partir de otro elemento, pero se muestra por claridad, aunque no agrega informacin semntica. Un elemento derivado se muestra con una barra inclinada (/) delante de su nombre. B.13. Nota Una nota (Figura B.5) contiene informacin textual. Se grafica como un rectngulo con la esquina superior derecha doblada, ligada a ningn o a algn elemento del modelo por una lnea discontinua. Las notas pueden usarse para incorporar comentarios o restricciones. B.14. Restriccin Una restriccin establece una condicin o restriccin semntica. Aunque la Norma ISO/IEC 19501 especifica un Lenguaje de Restriccin de Objetos para representar restricciones, puede escribirse una restriccin usando cualquier notacin formal, o un lenguaje natural. Una restriccin se muestra con una cadena de texto entre llaves ({}). Se ubica cerca del elemento al que se aplica. Si la notacin para un elemento es una cadena de texto (por ejemplo un atributo), la cadena de restriccin puede seguir a la cadena de texto del elemento entre llaves. Una restriccin incluida como un elemento en

Octubre de 2009

68

una lista es aplicable a todos los elementos posteriores de la lista, hasta el siguiente elemento de restriccin o el final de la lista.

Figura B.5. Nota y restriccin

Octubre de 2009

69

Anexo C (Normativo) Establecimiento de registros por parte del Comit Tcnico de ISO/TC 211 C.1. Introduccin El Comit Tcnico ISO/TC 211 ha desarrollado varias normas tcnicas que especifican clases de tems de informacin geogrfica, y puede desarrollar ms en el futuro. El TC puede elegir establecer registros para algunas de estas clases. Una propuesta para establecer un registro se debera incluir en la propuesta de nuevo tem de trabajo (NWIP) para desarrollar una norma tcnica que especificar una clase de tem a registrar. El Comit Tcnico ISO/TC 211 tambin puede decidir establecer un registro en conexin con una norma que ya est en desarrollo. En todos estos casos, el Comit Tcnico ISO/TC 211 debe ser el propietario del registro. C.2. Designacin de un administrador del registro ISO/TC 211 Cuando el ISO/TC 211 decide establecer un registro, la Secretara del TC debe solicitar candidaturas a organizaciones calificadas (apartado C.3) para ser administrador del registro. Para reducir la propagacin de autoridades registradoras, el ISO/TC 211 debe primero buscar candidatos entre las autoridades registradoras que ya han acreditado. Si ningn administrador de registro ISO/TC 211 es factible, la Secretara de ISO/TC 211 debe solicitar candidaturas. Slo los organismos nacionales miembros de ISO/TC 211, y las organizaciones coordinadas con el ISO/TC 211 pueden nominar organizaciones para ser autoridades registradoras de ISO/TC 211. El ISO/TC 211 debe aprobar la nominacin por votacin por correspondencia o por resolucin plenaria. Si se nomina a ms de un candidato, el ISO/TC 211 debe elegir entre ellos por votacin por correspondencia. Una vez que se haya elegido un candidato, la Secretara del ISO/TC 211 debe solicitar la aprobacin del ISO/TMB. C.3. Calificacin de un administrador de registro ISO/TC 211 Para calificar a efectos del nombramiento como administrador de registro ISO/TC 211 una Organizacin debe demostrar que: a) es una entidad legal; b) existe desde hace cinco aos como mnimo; c) disfruta de una estructura financiera slida; d) tiene disponible a personal tcnicamente competente en las materias relativas con

Octubre de 2009

70

las normas tcnicas en las que se basan las clases de tems del registro; e) est de acuerdo en su capacidad para servir como un administrador de registro durante un mnimo de cinco aos; f) tiene suficientes recursos materiales (por ejemplo, hardware, software) e instalaciones de comunicacin (por ejemplo, direccin postal, telfono, fax, direccin de correo electrnico, pgina Web); g) si opera con una estructura de pago, esta debe ser slo con el propsito de recuperar gastos, acordada con el ISO/TC 211 y aprobada por el Consejo de ISO; y h) no debe solicitar financiacin de la Secretara Central de ISO o de los miembros de ISO. C.4. Responsabilidades de un administrador de registro ISO/TC 211 El administrador del registro debe proporcionar un informe de sus actividades en cada reunin plenaria ISO/TC 211. Debe indicar (por ejemplo, en su pgina Web), que ha sido nombrado administrador de un registro ISO/TC 211 por ISO. Para promocionar la normalizacin de tems registrados, el administrador del registro debe proveer gratuitamente, a los desarrolladores de normas, copias de partes del registro mantenidas por el administrador del registro en los trminos y condiciones establecidos por l. El administrador del registro debe procesar totalmente las propuestas presentadas en un mximo de 120 das. C.5. Contrato Si es nombrado, un administrador de registro ISO/TC 211 debe trabajar con un contrato con ISO. Con un aviso de 12 meses de antelacin, tanto el administrador del registro ISO/TC 211 como ISO pueden resolver terminar el contrato. El documento contractual debe: a) identificar a las partes principales, que son: 1) la Organizacin Internacional para la Normalizacin (ISO), representada por ISO/TC 211; y 2) el administrador del registro ISO/TC 211 (el administrador del registro). b) identificar a todas las organizaciones comprometidas por el administrador del registro para establecer y/o operar y/o mantener el sistema del registro en su nombre (Terceros Proveedores de Servicios). c) especificar las medidas administrativas, que incluyen: 1) la jurisdiccin legal en que se ejecuta el contrato; 2) el plazo del contrato;

Octubre de 2009

71

3) las medidas para supervisar e informar, incluyendo los informes a las reuniones del plenario ISO/TC 211; 4) el calendario para la revisin de contratos; 5) las medidas para la renovacin de contratos; 6) las medidas para la variacin de contrato y modificacin de la gestin. 7) las medidas para la resolucin de disputas; 8) las medidas para la terminacin adelantada del contrato, tanto por una inesperada y forzada retirada, o con el aviso previo de 12 meses para la retirada de una de las partes principales; 9) las disposiciones para la transferencia del registro a ISO/TC 211 al expirar o cancelar el contrato. d) identificar los requisitos del contrato y las responsabilidades de las partes, incluyendo: 1) los requisitos para la gestin del registro (reflejando las disposiciones del captulo 6 de esta norma internacional); 2) las responsabilidades del administrador del registro (reflejando las disposiciones del apartado 5.3.2 de esta norma internacional); y 3) las responsabilidades de ISO/TC 211. e) indicar los trminos y condiciones para suministrar informacin al pblico, incluyendo: 1) los mtodos de suministro; 2) los procedimientos para calcular y revisar las tarifas (si se han de pagar tarifas); y 3) el reconocimiento de la propiedad intelectual. Los contratos para la prestacin de servicios entre el administrador del registro y un tercero, proveedor de servicios, debe someterse a la aprobacin de ISO/TC 211 y deben anexarse al contrato entre ISO/TC 211 y el administrador del registro. Un anexo al contrato debe nombrar a los representantes de ISO/TC 211 y al administrador del registro, como los responsables de la gestin y administracin cumplimiento del contrato. C.6. Organizaciones remitentes En el caso de registros establecidos por ISO/TC 211, las siguientes organizaciones remitentes pueden hacer las propuestas para aadir, aclarar, reemplazar o retirar tems del registro: a) cualquier miembro P u O de ISO/TC 211; o b) cualquier organizacin que tenga un enlace con ISO/TC 211. y

Octubre de 2009

72

C.7. Organismos de control C.7.1. Nombramiento de organismos de control por ISO/TC 211 ISO/TC 211 debe, consultando con los organismos miembros y las organizaciones de enlace, nombrar un organismo de control compuesto de personas con la experiencia tcnica apropiada. C.7.2. Responsabilidades de los organismos de control Un organismo de control debe revisar las propuestas para registrar tems individuales o conjuntos de ellos e informar al administrador del registro de su decisin en un plazo mximo de 90 das desde que recibi la propuesta del administrador del registro. C.8. Apelaciones Una organizacin remitente puede apelar a ISO/TC 211 si no est de acuerdo con la decisin de un organismo de control de rechazar una propuesta de registro. Una apelacin debe contener al menos una descripcin de la situacin, una justificacin para la apelacin, y una declaracin del impacto si la apelacin no tiene xito. En el caso de una apelacin, la Secretara de ISO/TC 211 debe emitir una votacin por correspondencia para que el TC vote aceptar o rechazar la apelacin. Para tal votacin, tanto para los votos de mantener como para los votos para revocar la decisin del organismo de control, se debe requerir una declaracin de la razn del voto. La decisin del TC debe publicarse en un mximo de 150 das desde la fecha de la apelacin.

Octubre de 2009

73

Anexo D (Normativo) Informacin que debe incluirse en las propuestas para el registro de tems D.1. Elementos de informacin requeridos para todas las propuestas La informacin siguiente debe incluirse en cualquier proposicin para registrar un tem de informacin geogrfica: a) nombre de la organizacin remitente (apartado 8.5.2); b) informacin de contacto para la organizacin remitente (apartado 8.5.3); c) fecha de presentacin de la propuesta; d) declaracin de la propuesta donde se especifique si es para aadir, aclarar, reemplazar o retirar un tem; y e) justificacin para aceptar la propuesta (apartado 8.9.3). D.2. Elementos de informacin adicional para propuestas de aadir tems nuevos al registro D.2.1. Elementos de informacin obligatorios La informacin siguiente debe incluirse en cualquier propuesta de aadir un tem a un registro: a) nombre de la clase del tem a la que pertenece el mismo (apartado 8.6.2); b) nombre del tem (apartado 8.8.3); y c) definicin del tem (apartado 8.8.7). D.2.2. Elementos de informacin condicionales Los siguientes elementos de informacin condicionales pueden incluirse segn se necesite: a) informacin sobre la referencia que describe la fuente de donde se ha obtenido un tem de una referencia externa (apartado 8.7.2); b) identificador asignado al tem en su fuente (apartado 8.13.2); c) tipo de modificaciones hechas a la especificacin del tem respecto a las de su fuente (apartado 8.13.3); y d) informacin adicional, segn lo solicite la norma internacional que especifica la clase del tem.

Octubre de 2009

74

D.2.3. Elementos de informacin opcional Los elementos de informacin opcional pueden incluir: a) una descripcin del tem (apartado 8.8.8); b) campo(s) de aplicacin donde pueda utilizarse el tem (apartado 8.8.9); c) nombres, definiciones y elementos opcionales de la especificacin del tem en lenguajes alternativos (apartado 8.8.10); d) informacin de la mencin que define el linaje del tem (apartado 8.8.14); y e) comentarios adicionales. D.2.4. Elementos de informacin adicionales requeridos en las propuestas para aclarar un tem registrado Los elementos de informacin adicionales pueden incluir: a) identificador del tem (apartado 8.8.2); b) nombre del tem (apartado 8.8.3); y c) modificacin propuesta al tem (apartado 8.11.2). D.3. Elementos de informacin requeridos en las propuestas para reemplazar un tem registrado Para el elemento registrado que ser reemplazado: a) identificador del tem (apartado 8.8.2); y b) nombre del tem (apartado 8.8.3). Para el nuevo tem que reemplazar al tem registrado, se incluirn todos los elementos especificados para las propuestas de aadir tems nuevos a un registro (apartado D.2). D.4. Elementos de informacin adicionales de propuestas para retirar un tem registrado Los elementos de informacin adicionales incluirn: a) identificador del tem (apartado 8.8.2); y b) nombre del tem (apartado 8.8.3).

Octubre de 2009

75

Bibliografa [1] ISO 19101:2002, Geographic information. Reference model. [2] ISO/IEC 11179-3:2003, Information technology. Metadata registries (MDR). Part 3: Registry metamodel and basic attributes. [3] ISO 6523, Data Interchange. Structures for the identification of organizations. [4] ISO/IEC 19501:2005 Information technology. Open Distributed Processing. Unified Modeling Language (UML) Version 1.4.2. [5] ISO 19104, Geographic information. Terminology. [6] ISO 19110, Geographic information. Methodology for feature cataloguing. [7] ISO 19119, Geographic information. Services. [8] ISO 704:2000, Terminology work. Principles and methods. [9] ISO/IEC TR 19764, Information technology. Guidelines, methodology and reference criteria for cultural and linguistic adaptability in information technology products. [10] ISO/IEC 11179-6, Information technology. Specification and standardization of data elements. Part 6: Registration of data elements. [11] ISO/IEC Directives, Part 1, Procedures for the technical work. [12] ISO/IEC JTC 1 Procedures for the technical work of ISO/IEC JTC 1 on Information Technology. [13] ISO/IEC 9973:1994, Information technology. Computer graphics and image processing. Procedures for registration of graphical items.

Octubre de 2009

76