Tags: Interoperabilidad

Construyendo un vocabulario para el callejero de Santander

10 Sep 2013

Cuando hablamos de vocabularios en la web semántica nos estamos refiriendo principalmente a la definición de conceptos y relaciones que describen o representan términos de un área específica del conocimiento. Podemos encontrar desde vocabularios muy simples con unas pocas definiciones a vocabularios muy complejos, con varios cientos de términos.

En la web semántica resultan decisivos a la hora de la integración de datos y de su reutilización pues al publicar un conjunto de datos muchos campos pueden llevar a confusiones o ambigüedades, resultando necesaria la definición formal de los mismos.

En nuestro esfuerzo por conformar una infraestructura tecnológica de soporte a las iniciativas de apertura de datos alrededor de iCMS, incorporamos el modelado de los datos a publicar garantizando su formalización a través de vocabularios.

Hay dos formas populares de describir o formalizar vocabularios, RDF Schema (RDFS) y OWL (en el contexto de esta última especificación vocabulario y ontología son usados indistintamente). RDFS resulta un poco más ligero que OWL y la inferencia automática más eficiente pero es impropio para un modelado complejo que requiere el uso de OWL.

En un vocabulario encontraremos dos elementos: clase y propiedad, la primera representa conceptos, por ejemplo, una persona, una localidad, un documento, etc. Las relaciones que involucran a dichos conceptos son sus propiedades. Asociado a la propiedad encontramos también el dominio, que indica a que clase está asociada la propiedad y el rango, que señala los tipos de valores que tomará la propiedad.

Por ejemplo, podemos definir la propiedad ej:autor que pertenece al dominio de la clase ej:Documento y que tiene como rango instancias de la clase ej:Persona.

Cuando tenemos que disponer de un vocabulario que cubra los conceptos de uno de nuestros conjuntos de datos lo primero que debemos intentar es encontrar un vocabulario reconocido como lo pueden ser FOAF, DCMI Metadata Terms, SKOS, vCard, etc. que lo incluya, para ello nos valemos de alguno de los buscadores especializados como LOV, Falcons, Swoogle, Watson, etc. Si no es posible encontrar entre los vocabularios reconocidos el concepto que se ajuste a los datos que estamos publicando debemos construir un vocabulario propio y siempre que sea posible extender de esos vocabularios usando herencia de clases mediante la propiedad rdfs:subClassOf o estableciendo relaciones mediante propiedades del tipo owl:sameAs y owl:equivalentClass para indicar similitudes entre clases, y owl:equivalentProperty para el caso de las propiedades.

Por otro lado resulta necesario implantar un esquema de URI que proporcione un mecanismo de identificación común para los sistemas de gestión del conocimiento –en nuestro caso el vocabulario– de forma que se pueda hacer referencia a estos de forma única, fiable y persistente en el tiempo, requisito clave para facilitar su posterior reutilización.

La Norma Técnica de Interoperabilidad de Reutilización de recursos de la información para el caso de definición de vocabularios indica que las URI deben de conformarse según el siguiente esquema: [code language=”html” light=true]http://{base}/def/{sector}/{dominio}[/{concepto}[/code]

Como herramienta para la definición de nuestro vocabulario hemos utilizado la versión gratuita de TopBraid Composer y para su publicación Neologism.

Veamos ahora el proceso completo a partir de uno de los conjuntos de datos que publica el Portal de Datos Abiertos del Ayuntamiento de Santander, el Callejero, aquí tenemos por ejemplo el recurso Calles, entre sus campos tenemos el tipo de vía (Calle, Pasaje, Avenida, Plaza, Alameda, Travesía, etc.). Usando los buscadores no nos fue posible encontrar un vocabulario que definiera este concepto, lo mismo sucede con la sigla que se le asocia (CL, PSJ, AV, PZ, AL, TRV, etc.), por ello decidimos definir un vocabulario propio.

Con TopBraid Composer definimos las propiedades generales del vocabulario:

Formulario de definición del vocabulario

Observar que este vocabulario sería accesible a través de la URI:

http://datos.ayto-santander.es/def/urbanismo-infraestructuras/callejero

El código RDF/XML generado sería:

<?xml version="1.0"?>
<rdf:RDF
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:skos="http://www.w3.org/2004/02/skos/core#"
    xmlns:cc="http://web.resource.org/cc/"
    xmlns="http://datos.ayto-santander.es/def/urbanismo-infraestructuras/callejero#"
    xmlns:owl="http://www.w3.org/2002/07/owl#"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:dcterms="http://purl.org/dc/terms/"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
    xmlns:dctype="http://purl.org/dc/dcmitype/"
    xmlns:vann="http://purl.org/vocab/vann/"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
  xml:base="http://datos.ayto-santander.es/def/urbanismo-infraestructuras/callejero">
  <owl:Ontology rdf:about="">
    <dcterms:hasFormat>
      <dctype:Text rdf:about="http://datos.ayto-santander.es/def/urbanismo-infraestructuras/callejero.rdf">
        <dc:format>
          <dcterms:IMT>
            <rdf:value>application/rdf+xml</rdf:value>
            <rdfs:label xml:lang="es">RDF</rdfs:label>
          </dcterms:IMT>
        </dc:format>
      </dctype:Text>
    </dcterms:hasFormat>
    <owl:versionInfo rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
    >v 1.0</owl:versionInfo>
    <dc:creator rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
    >Ayuntamiento de Santander</dc:creator>
    <dcterms:issued>2013-05-02</dcterms:issued>
    <vann:preferredNamespaceUri rdf:datatype="http://www.w3.org/2001/XMLSchema#anyURI"
    >http://datos.ayto-santander.es/def/urbanismo-infraestructuras/callejero#</vann:preferredNamespaceUri>
    <vann:preferredNamespacePrefix rdf:datatype="http://www.w3.org/2001/XMLSchema#string"
    >callej</vann:preferredNamespacePrefix>
    <rdfs:comment xml:lang="es">Se utiliza para representar elementos del Callejero.</rdfs:comment>
    <dc:title xml:lang="es">Vocabulario del Callejero</dc:title>
    <dc:rights xml:lang="es">Ayuntamiento de Santander - Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 España de Creative Commons</dc:rights>
    <cc:license rdf:resource="http://creativecommons.org/licenses/by-nc-sa/3.0/es"/>
  </owl:Ontology>

Veamos a continuación la definición de una clase en el mismo, por ejemplo el caso de Tipo-via ya comentado:

Formulario para definir una clase

Que tiene como URI:

[code language=”plain” light=true]
http://datos.ayto-santander.es/def/urbanismo-infraestructuras/callejero#Tipo-via
[/code]
Su código en RDF/XML sería:

  <rdf:Description rdf:about="#Tipo-via">
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#Class"/>
    <rdfs:comment xml:lang="es">Los diferentes objetos en un Callejero, ejemplo: LADERA, CALLE, BULEVAR, etc.</rdfs:comment>
    <dcterms:issued>2013-05-02</dcterms:issued>
    <rdfs:isDefinedBy rdf:resource="#"/>
    <rdfs:label xml:lang="es">Tipo de vía</rdfs:label>
    <rdfs:subClassOf rdf:resource="http://www.w3.org/2003/01/geo/wgs84_pos#SpatialThing"/>
    <skos:definition xml:lang="es">Los diferentes tipos de vía en un Callejero</skos:definition>
  </rdf:Description>

Una de las propiedades asociadas a la clase Tipo-via es sigla, veamos como la hemos definido:

Formulario para definir una propiedad

Su URI sería: [code language=”plain” light=true]http://datos.ayto-santander.es/def/urbanismo-infraestructuras/callejero#sigla[/code]

y su representación RDF/XML:

<rdf:Description rdf:about="#sigla">
    <rdfs:domain rdf:resource="#Calles"/>
    <rdfs:domain rdf:resource="#Numeros-postales"/>
    <rdfs:range rdf:resource="http://www.w3.org/2001/XMLSchema#string"/>
    <rdf:type rdf:resource="http://www.w3.org/2002/07/owl#DatatypeProperty"/>
    <rdfs:domain rdf:resource="#Tipo-via"/>
    <dcterms:issued>2013-05-02</dcterms:issued>
    <rdfs:domain rdf:resource="#Tramos-calle"/>
    <rdfs:comment xml:lang="es">Por ejemplo: CL, AV, BO, etc.</rdfs:comment>
    <rdfs:isDefinedBy rdf:resource="#"/>
    <rdfs:label xml:lang="es">Sigla del Tipo de Vía</rdfs:label>
    <skos:definition xml:lang="es">La sigla del tipo de vía que se asocia al nombre de la vía</skos:definition>
  </rdf:Description>

Definido el vocabulario completo simplemente lo subimos a Neologism usando Importar vocabulario, rellenamos los campos del formulario y pinchamos en Importar desde archivo:

Formulario importando el vocabulario callej

Y ya tenemos el vocabulario publicado:

Vista del vocabulario ya importado con sus clases y propiedades

Suponiendo que esta URL fuera pública, Neologism sería capaz de devolvernos las consultas a las URI de las clases y propiedades del vocabulario para el callejero de Santander.

(Spanish version) “Retocando” el modulo de activos…

08 Nov 2012

Intermediación de Datos: nueva NTI aprobada (spanish)

06 Ago 2012

El mes pasado se publicaban en el BOE tres nuevas Normas Técnicas de Interoperabilidad (NTI), completando con ello gran parte de las previstas por el ENI. En concreto, fueron aprobadas las normas técnicas para:

Sin embargo, en este post quiero centrarme en la última, la norma técnica para los

Protocolos de Intermediación de Datos

Con esta norma se pretende dar cobertura técnica a parte de lo establecido hace tiempo por las leyes 30/1992 “Régimen Jurídico de las Administraciones Públicas y del Procedimiento Administrativo Común” y 11/2007 “de acceso electrónico de los ciudadanos a los Servicios Públicos”, donde se establece el intercambio de datos entre las distintas administraciones públicas en beneficio del ciudadano.

En concreto, y citando ambas leyes, los ciudadanos tenemos derecho a:

  • Ley 30/1992 Art. 35 literal f): “A no presentar documentos no exigidos por las normas aplicables al procedimiento de que se trate, o que ya se encuentren en poder de la Administración actuante“.
  • Ley 11/2007 Art. 6 “derechos de los ciudadanos”, literal 2b: “A no aportar los datos y documentos que obren en poder de las Administraciones Públicas, las cuales utilizarán medios electrónicos […]

O si nos vamos más lejos aún, los

  • Reales Decretos 522 y 523 de 2006 que suprimen la aportación de fotocopias de documentos acreditativos de identidad y la exigencia de aportar el certificado de empadronamiento como documento probatorio del domicilio y residencia en los trámites de la AGE.

Imagino a muchos de vosotros echando las manos a la cabeza al leer estos artículos y os preguntaréis: “¿y entonces por qué me pidieron la fotocopia de mi DNI, el certificado de empadronamiento, o el certificado de trabajo de mi empresa?”. Sin ir más lejos la semana pasada me tocó presentar mi certificado de empadronamiento, y me volverá a tocar dentro de una semana para solicitar el DNI a mi hija.

Y entonces, ¿dónde reclamamos estos derechos?

Como mencioné en mi anterior artículo “La Generación TIC del 2007“, son muchos los avances realizados en esta materia, pero son muchos más los que quedan por recorrer. No en vano, en esta NTI se describe el papel fundamental que ya viene haciendo la Plataforma de intermediación del Ministerio de Hacienda y Administraciones Públicas, instrumento tecnológico que ya permite el intercambio de datos entre las distintas administraciones públicas adscritas.

En tiempos de Crisis

Como no podía ser de otra forma, corren unos tiempos en los que toda medida de ahorro (y no recorte) debería ser de obligado cumplimiento. Medidas como el intercambio de datos entre las distintas administraciones sin duda supone una inversión acertada.

Según los números publicados en una de las presentaciones del proyecto “Datos”: Servicio de Verificación y Consulta de Datos: Plataforma de Intermediación, el coste de la emisión de un “volante” con los datos de residencia solicitados por otra institución, es de unos 10 euros.

Si tomamos el dato de 2010, con más de 2,5 millones consultas realizadas, estaríamos hablando de más de 25 millones de euros de ahorro.

Mi visión personal

En esta ocasión el marco regulatorio no es el problema, como podemos comprobar, pero algo sigue sin encajar en la voluntad de las administraciones para que estas normas se cumplan y sean más perceptibles por la ciudadanía.

En mi opinión, falta un régimen sancionador que apriete a los dirigentes, itinerantes o no, y evite el incumplimiento sistemático con el que nos encontramos demasiadas veces los ciudadanos.

Si queréis ponerle un toque de humor a toda esta situación, no os perdáis este corto donde se escenifica todo esto que estamos hablando.

Real-time Open Data con iCMS. Integración con Virtuoso

11 Abr 2012

Con el objetivo de habilitar diversos mecanismos de acceso a la información publicada a través de la Interfaz de Interoperabilidad de Contenidos Web (iCMS), además del end-point opensearch que conforma la propia interfaz de iCMS, se han implementado mecanismos de integración con servidores semánticos (en este post nos centraremos en Virtuoso) . Entre otras características, estos sistemas permiten la utilización del lenguaje estándar SPARQL para la consulta de los datos almacenados.

Entre las funcionalidades de iCMS encontramos la gestión de eventos asociados a las colecciones de datos (al iniciar y al modificar las colecciones), permitiendo vincular scripts (en la versión actual de iCMS se da soporte a la inyección de scripts Groovy, aunque en el Roadmap de la solución se encuentra el soporte para otras tecnologías, como pueden ser Python o Ruby) a dichos eventos.

El mecanismo de integración entre iCMS y Virtuoso se apoya en esta funcionalidad, es decir, se trata de un script Groovy que incluye toda la lógica necesaria para conectar con virtuoso, crear los grafos, obtener los recursos/datos (desde los back-ends a través de los drivers iCMS) cuya modificación ha lanzado el evento y finalmente actualizar la información en Virtuoso.

La actualización de los datos en Virtuoso se realiza mediante la ejecución de sentencias INSERT/DELETE de SPARQL a través de los servicios desplegados por Virtuoso.

En la parametrización de las colecciones de datos, cuyo contenido va a ser volcado en Virtuoso, es preciso establecer la configuración del evento que dispara el script Groovy que incluye la lógica de integración con el servidor semántico. Esta configuración sigue el siguiente modelo:

[code]
event {
my_event_script {
path = “/opt/icms/data/scripts/groovy_virtuoso.groovy”
urlSubscription = “http://localhost:8080/icms”
collections = “<nombre_coleccion>”
parameters {
virtuoso_url = “jdbc:virtuoso://localhost:1111”
virtuoso_usr = “icms_virt”
virtuoso_psw = “icms_virt”
virtuoso_graph = “<http://nombre_grafo>”
}
}
}
[/code]

La configuración anterior le indica a iCMS que cuando haya algún cambio en los recursos de la colección definida (“nombre_colección” en el ejemplo) se ejecute el script groovy_virtuoso.groovy con los parámetros dados. Dicho script contiene toda la lógica necesaria para rellenar Virtuoso con los nuevos cambios.

En el siguiente gráfico se muestra a alto el proceso de integración entre iCMS y el servidor semántico Virtuoso:

Proceso de integración entre iCMS y Virtuoso

XAdES Plugtest Remote Event – XML Advanced Electronic Signatures

26 Mar 2012

As we announced in the PAdES post, ETSI Centre for Testing and Interoperability (CTI) is organizing a new Remote Plugtests Interop events for XAdES Signatures from 14th March to 28th March 2012.

This Remote event aims at conducting interoperability test cases on XAdES signatures (TS 101 903) and the XAdES Baseline Profile (TS 103 171).

This testing will provide full test coverage of the both specifications including testing signatures evolution, simulating real life situations.

This Plugtests event will enable participants to conduct 4 types of tests (Interoperability and Conformance):

  • Generation and cross-verification (Positive) tests
  • Only-verification (Negative) tests
  • Signature Upgrade tests
  • Conformance testing on XAdES Baseline Profile signatures

Plugtest XAdES

The purpose of these events is:

  • To enable participants to assess the level of interoperability of XAdES.
  • To identify additional issues that should be taken into account in future XAdES standardisation activities.
  • To improve the quality of XAdES specifications.
  • To ease the introduction of XAdES signatures, by providing the means to solve interoperability problems before widespread deployment..

You can get more information on plugtests portal for electronic signatures:  http://xades-portal.etsi.org/pub/index.shtml

As shown in our website, we can provide you a little description about de XAdES profiles differing in protection level offered. Each profile includes and extends the previous one:

  • XAdES, basic form just satisfying Directive legal requirements for advanced signature;
  • XAdES-T (timestamp), adding timestamp field to protect against repudiation;
  • XAdES-C (complete), adding references to verification data (certificates and revocation lists) to the signed documents to allow off-line verification and verification in future (but does not store the actual data);
  • XAdES-X (extended), adding timestamps on the references introduced by XAdES-C to protect against possible compromise of certificates in chain in future;
  • XAdES-X-L (extended long-term), adding actual certificates and revocation lists to the signed document to allow verification in future even if their original source is not available;
  • XAdES-A (archival), adding possibility for periodical timestamping (e.g. each year) of the archived document to prevent compromise caused by weakening signature during long-time storage period.

After this, you may be interested in free downloading one of our  development kits for Java, .NET or PHP from our website for developers to electronically sign on XAdES format.

Portal de Datos Abiertos de la Junta de Andalucía

03 Ene 2012

Hace pocos días salía a producción la primera fase del Portal de Datos Abiertos de la junta de Andalucía. Esta primera fase del proyecto tiene como objetivo ofrecer una aproximación a los datos disponibles en la Junta de Andalucía, así como establecer un punto único de acceso a los mismos. Los servicios ofrecidos en esta etapa pueden catalogarse como 2 estrellas, según la clasificación del Open Linked Data propuesta por Tim Berners-Lee.

Para mediados de 2012 será publicada la versión final del Portal, en la que se habrán realizado las siguientes actuaciones:

  • Modelado semántico de los datos.
  • Ampliar el catálogo de datos disponible.
  • Dotar al Portal de la infraestructura necesaria para ofrecer conjuntos de datos de 4 y 5 estrellas. El Portal ofrecerá un SPARQL endpoint (implementado con Virtuoso), así como servicios de suscripción a los contenidos (para lo que se habilitará un servidoriCMS público).
  • Incorporar un conjunto de aplicaciones de ejemplo y documentación técnica destinada a desarrolladores, con el objetivo de facilitar la construcción de sistemas que reutilicen la información disponible.

En el siguiente diagrama se muestra la infraestructura tecnológica (presentada por la Junta de Andalucía en el evento Opendatasev  que tuvo lugar el pasado noviembre) que dará soporte a la iniciativa de apertura de datos en la Junta de Andalucía:

Arquitectura tecnológica Portal Datos Abiertos de la JA

Apertura de datos con iCMS

13 Jul 2011

En  octubre de 2007, en una de las conferencias de la SunLight Foundation se discutía sobre el modelo a seguir por los Organismos Públicos para realizar la apertura de datos almacenados electrónicamente. En este evento tienen su origen un conjunto de principios básicos a tener en cuenta en diseño de cualquier iniciativa de apertura de datos (que hoy día son incluidos en la Ley de Transparencia de diversos Organismos Públicos):

  • Completeness. Los Datos deben ser lo más completos que sea posible.
  • Primacy. Deben ser obtenidos en su origen, evitando la transformaciones intermedias.
  • Timeliness. Publicados en tiempo real, o actualizados siempre sea posible.
  • Ease of Physical and Electronic Access. Fácilmente accessibles.
  • Machine readability. Procesables electrónicamente.
  • Non-discrimination. Accesibles sin discriminación (disponibles para todos).
  • Use of Commonly Owned Standards. Publicados en formatos no proprietarios.
  • Licensing. Datos libres (el licenciamiento utilizado debe facilitar el acceso libre a los mismos).
  • Permanence. Se debe garantizar la permanencia en el tiempo de los conjuntos de datos publicados.
  • Usage Costs. Sin coste.

Es esta ocasión nos centraremos en los tres primeros enunciados (datos completos, obtenidos directamente desde la fuente y actualizados), pues representan (al menos, desde mi punto de vista) algunos de los aspectos más destacables de la Interfaz de Interoperabilidad de Contenidos Web (iCMS), esto es, la posibilidad de publicar conjuntos de datos obteniéndolos directamente desde su fuente, sin necesidad de recurrir a procesos de consolidación de los datos en repositorios centralizados (por ejemplo, mediante ETLs). De esta forma, siempre que se cumplan determinadas condiciones (que son establecidas en el proceso de configuración del conjunto de datos), los datos son ofrecidos completamente actualizados. Obviamente, para ofrecer esta posibilidad, ha sido necesario recurrir a mecanismos de caché e indexación con el objetivo de que el acceso a los datos no penalice el rendimiento de los back-ends (sistemas donde son generados/almacenados los datos).

Hace unas semanas, tuve la suerte de asistir como oyente al evento Gobierno Abierto: “Reto y Oportunidad” , donde en una de las mesas redondas uno de los ponentes presentaba un concepto que enmarca claramente las características descritas anteriormente:Real-Time Open Data.

Todo esto es posible gracias al sistema de notificaciones implementado en iCMS. En primer lugar, los back-ends notifican al servidor iCMS (a través de los drivers iCMS) los cambios que se producen en los datos,  con el objetivo de las actualizaciones sean indexadas. Por otro lado,  una vez indexados los cambios, el servidor iCMS procede a notificar dicho cambio a todos los sistemas suscritos al conjunto de datos en el que se ha producido el evento. Este proceso es descrito en el siguiente diagrama:

notificaciones icms

En el siguiente gráfico se presenta a muy alto nivel el rol que desempeña iCMS dentro de una iniciativa de apertura de datos:

Arquitectura Open Data basada en iCMS

En futuras entradas, se detallará el resto de capacidades/funcionalidades de iCMS, así como los procesos de integración con CKAN yVirtuoso.

Arranca el proyecto de desarrollo de la intranet de TP Ferro en Drupal

07 Jun 2010

Recientemente en VIAVANSI hemos iniciado un proyecto para TP Ferro. Esta empresa es la concesionaria de la construcción, mantenimiento y gestión del tramo de tren de alta velocidad que une Figueres (Girona) y Perpignan (Francia).

El proyecto es realmente interesante, con características como las que siguen:

  • TP Ferro dispone de sistemas de información especializados, para mantenimiento, explotación, etc.
  • Se desea construir una intranet que se integre con estos sistemas especializados siguiendo un paradigma SOA: la información reside en un sistema especializado y es consumida (REST) por un nodo central (intranet), por lo que realmente la complejidad del proyecto está más dirigida a resolver la problemática de integración de sistemas.
  • La intranet además debe resolver problemáticas típicas como la gestión de recursos humanos, gestión documental (para lo que se ha escogido Alfresco que se integrará vía CMIS), agendas, gastos, reporting…
  • Se nos permite trabajar con metodologías ágiles (Scrum), algo novedoso al trabajar principalmente con Administraciones públicas que requieren metodologías tradicionales como Metrica v3.
  • Estamos valorando utilizar un componente central que gestione la interoperabilidad entre los distintos sistemas, para lo que podría utilizarse iCms si la dirección del proyecto lo estima oportuno.
  • Se utilizará VIAFIRMA para garantizar la integridad de los documentos críticos, realizando un proceso de firmado digital en servidor.
  • La dirección técnica reside en TP Ferro en colaboración con consultores de Klicap.
  • Hemos podido percibir un excelente nivel de preparación del proyecto por parte del cliente: ya se dispone de un pre-desarrollo basado en Drupal que resulta ciertamente útil, mind maps para la definición de entidades, etc. En definitiva, un cliente que apuesta por el proyecto lo cual obviamente favorece el éxito del proyecto.

Para construir ese nodo central hemos optado por Drupal, que es una excelente base sobre la que inyectar lógica en base a módulos y además es una herramienta ya perfectamente conocido por el cliente.

La Junta de Andalucía destaca iCMS

27 Abr 2010

El pasado 13 de abril de 2010 Pilar Rodríguez, Secretaria General de Telecomunicaciones y Sociedad de la Información de la Consejería de Economía, Innovación y Ciencia de la Junta de Andalucía, ha descrito en una entrevista para SOCINFO las iniciativas del organismo en relación al Esquema Nacional de Interoperabilidad (ENI).

Tal y como menciona Pilar Rodríguez en la citada entrevista, VIAVANSI ha sido un actor importante en las nuevas iniciativas de interoperabilidad en la Junta de Andalucía, al ser la empresa desarrolladora de iCMS, sistema para la interoperabilidad de contenidos web.

[…]