La historia de Carbon LDP

Este artículo se publicó originalmente en CarbonLDP.com, el sitio web de nuestra herramienta de plataforma de linked data. Recientemente lanzamos la versión 5 de Carbon LDP™ que incluye nuevas características, entre ellas, el soporte para bases de datos a nivel Enterprise. Esto hace que este sea uno de los lanzamientos más importantes que hemos hecho a la fecha. En este punto, pensé que sería bueno compartirles la historia de cómo y por qué creamos esta plataforma. Muy pocos saben que hemos pasado los últimos cinco años en investigación y desarrollo y que, para que naciera este concepto, transcurrieron ocho años más antes de eso. Esto es algo en lo que he estado involucrado desde hace 13 años y es una de las razones por las que dejé IBM para ayudar a establecer nuestra compañía, Base22. En un principio, no pensaba desarrollar un sistema web semántico. Fue un año antes de que incluso el concepto Linked Data fuera acuñado por Tim Berners-Lee y nueve años antes la Plataforma Linked Data (LDP) se había convertido en el estándar W3C. Yo solo quería hacer algo que pudiera mejorar nuestro software y resolvería los problemas más comunes dentro del desarrollo de software. Al final resultó que Linked Data era la respuesta, aunque no era el objetivo original. Formalmente, yo era Arquitecto en IBM, pasaba mucho tiempo trabajando tarde, tratando de cumplir a duras penas mis fechas de entrega, diseñando sistemas, y escribiendo código. Más de una vez, y me siento orgullo de eso, me encontré enfrentando plazos aparentemente imposibles. Pero al mismo tiempo, tenía un deseo inquebrantable de hacer un trabajo de calidad. Así que hice lo que hace un artesano orgullo: me sacrifiqué con horas de sueño, fines de semana, tiempo con la familia e incluso vacaciones. Aun cuando la precariedad de nuestros proyectos tuviera poco que ver con mi propia culpa, el fracaso nunca fue una opción para mí. Trabajé duro, un proyecto tras otro, siempre cumpliendo con lo que tenía que hacer. En el camino, empecé a pensar en el proceso de desarrollo de software y cómo se podría mejorar. Para mí, crear nuevas aplicaciones parecía más difícil de lo necesario. Cada vez me sentía más frustrado con todas las conexiones back-end que se tenían que hacer antes para que el trabajo pudiera completarse en el front-end. Para hacer una aplicación centrada en datos, por ejemplo, no era raro trabajar dos o más semanas solamente configurando la base de datos, el modelo de objetos, el nivel de servicio, los SQL queries y similares. Tener que hacer esto una y otra vez para una app y luego otra; empecé a preguntarme por qué no podría ser esto mucho más dinámico. Después de todo, el modelo de datos detrás de los sistemas se basa en unos pocos principios clave que siempre son los mismos. Hay objetos de dominio (clases en Java y entidades o tablas en una base de datos). Cada uno tiene propiedades (campos, getters y setters en Java y columnas en una base de datos). Y luego hay relaciones que se mantienen entre ellos (un modelo orientado al objeto en Java y relaciones clave en una base de datos con SQL queries para unirse). La cantidad de tiempo que se necesita para configurar todo eso es solo una parte del problema. También otro problema es que, una vez que diseñaste el esquema (schema) de la base de datos, todo lo demás está vinculado rígidamente a ello. Los stakeholders del negocio asumen que los cambios, como añadir un solo atributo de datos, debería ser sencillo. Hacer un cambio debería ser tan simple como se escucha, pero aparentemente los cambios “sencillos” tienen enormes efectos secundarios. El esquema de la base de datos tiene que ajustarse. Las clases de Java necesitan modificarse, recompilarse o reestructurarse. Los queries de SQL necesitan cambiarse. Las pruebas unitarias necesitan modificarse. Se tienen que ejecutar pruebas de regresión. ¿Y todo eso solo por añadir un atributo? Sí. Y esto no es todo. Lo siguiente que tienes que hacer es pensar en la integración de los sistemas. Además de las capas de cambio requeridas dentro de una aplicación, puede haber más en los sistemas interoperativos, cuya complejidad aumenta exponencialmente por cada nuevo componente en una red participante. Una red de tres componentes tiene solo tres posibles conexiones.

Simplemente añade dos componentes más a esta red y la cantidad de conexiones posibles aumenta a diez. No es de extrañar que los obstáculos de datos tiendan a permanecer así, ¡con valor atrapado en un único sistema!

Si haces un cambio en tu API de manera que la interfaz cambie, ¿entonces cuántos consumidores también necesitarán cambiarse? Y toma en cuenta que esto fue hace 13 años, mucho antes de la explosión del Big Data, antes de que la computación en la nube fuera la norma, antes de que los microservicios fueran algo. Hoy en día, las soluciones están compuestas por sistemas y servicios interoperativos más que nunca. Y esto era lo que me tenía despierto hasta tarde. Así que, una noche publiqué una pregunta en una comunidad de geeks en línea. No me acuerdo de las palabras exactas, pero fue algo como esto…

“¿Por qué tenemos que hacer una base de datos específica para aplicación y un modelo de objeto todo el tiempo? ¿No hay una manera de hacer más dinámica esa parte en vez de hacer todo el código complejo, recopilando y desplegando?, podríamos… no sé… ¿cambiar un archivo config?”

En otras palabras, ¿cómo podemos definir el modelo de datos de manera más dinámica y tener todo ese proceso para crear, leer, actualizar y eliminar datos de manera más inmediata? Si había una manera, quería encontrarla. Si no existía, quería inventarla. Y así empezó la visión de lo que eventualmente se convertiría en Carbon LDP. Recibí varias respuestas sobre la complejidad del problema. Sobre varios intentos fallidos para resolverlo dentro de la historia de la industria. Los problemas de rendimiento que surgen cuando intentas hacer un schema de base de datos para crear esquemas dinámicos de bases de datos. Pero una respuesta misteriosa, en particular, despertó mi interés. Alguien simplemente dijo: “Deberías revisar el RDF”. Googleé “RDF” y descubrí que es el acrónimo de Resource Description Framework, un modelo estándar de W3C para el intercambio de datos en la web. Aprendí que RDF tiene características que facilitan la combinación de datos incluso aunque los esquemas subyacentes difieran y eso especialmente le da soporte a la evolución de los esquemas a lo largo del tiempo sin la necesidad de que se cambien todos los consumidores de datos. También aprendí que es parte de una familia de tecnologías y conceptos que conforman esta cosa llamada web semántica. También googleé eso. Resulta que la web, tal como la conocemos, está lejos de alcanzar su máximo potencial. Es una red de documentos principalmente creados para que los humanos los lean. Es difícil para las computadoras entender esa información o interoperarla con otra porque solo está semiestructurada. Carece de la semántica o significado que las computadoras usan. La web semántica fue una visión para incorporar la semántica en la arquitectura existente de la web para que estas redes de documentos se puedan convertir en redes de datos. En lugar de tener un library gigante de páginas web, por ejemplo, imagina la web como una enorme base de datos. Esa es la idea general. Pero en esa época, era un concepto muy académico, solo dentro de la esfera de entusiastas y doctores en Inteligencia Artificial. Y esto fue mucho antes de que la IA se popularizara; antes de que Watson le ganara al campeón de Jeopardy y cuando todavía la mayoría de la gente creía que la IA era un sueño inalcanzable. Era un concepto tan académico y confuso que estoy seguro me llevó tres años estudiarlo hasta que se me prendió el foco. Ese momento de iluminación me llegó cuando me di cuenta de que el modelo RDF de grafos era una solución viable para el problema de hacer más dinámicos los sistemas de datos. ¿Por qué? Porque no hay una estructura inherente en una base de datos de grafos RDF. No hay esquemas rígidos que definir. La estructura surge de los mismos datos, así que los cambios estructurales se pueden hacer simplemente cambiando los datos. Un sistema debidamente diseñado puede funcionar dinámicamente contra estos cambios con una disminución en la necesidad de reescribir código. Esto es inmensamente poderoso, pero engañosamente sencillo. En pocas palabras, así es como funciona. Un grafo RDF es solo una colección de tres simples declaraciones llamadas “triples”. Estas tienen un tipo de sujeto, predicado y objeto, igual que la estructura de la oración que aprendimos en la primaria.

El RDF aprovecha los URI de la web para identificar cosas así que, técnicamente, la misma declaración sería algo más parecido a esto:

Aquí podemos ver por qué usamos el término Linked Data. Esa declaración crea un enlace entre el recurso Jacky el recurso Jill a través de la propiedad tieneAmigo. Es parecido a un hipervínculo, pero es más poderoso porque la naturaleza de la relación está descrita semánticamente. En lugar de tener un enlace arbitrario entre un recurso y otro (como sucede con los hipervínculos tradicionales), este link tiene significado. Por ejemplo, un hipervínculo tradicional entre el blog de Jack y el Blog de Jill no dice nada acerca de la naturaleza de la relación. Pero este enlace identifica que Jack y Jill son personas y que la relación es una amistad. Así que esto está impregnado de significado (semántica) y nos referimos a las entidades de datos, no nada más a páginas web.

Ahora, supongamos que queremos agregar una nueva propiedad de datos. En una base de datos relacional tradicional, tenemos que agregar una nueva columna al esquema de base de datos. Seguramente vamos a reescribir algunos SQL queries. Probablemente también tengamos que agregar una nueva propiedad en el código del software (tanto en el servidor y como en el front-end). Sin embargo, dado que un grafo RDF es solo una lista de declaraciones de tres partes, todo lo que tenemos que hacer es agregar uno nuevo a la lista. Sin tener que hacer cambios en el esquema, podemos darle a Jack una nueva propiedad como un correo electrónico, simplemente insertando un triple como este…

<http://example.com/people#jack><http://example.com/person#hasEmail> "jack@example.com"

Podemos inventar nuevas propiedades sobre la marcha y colocarlas en la base de datos contra los sujetos apropiados, como Jack y Jill, ya sea con valores literales (por ejemplo, series, fechas, números) o con un valor que es otro URI (un enlace a otra entidad de datos). No necesitas crear un esquema rígido. No necesitas definir ninguna tabla o columna nueva ni relaciones clave principales/externas. De hecho, puedes pensar en cualquier base de datos RDF solo como una tabla con tres columnas para sujeto, predicado y objeto. Cuando queramos cambiar los datos o la estructura de los datos, solo tenemos que insertar nuevas declaraciones.

La estructura surge de forma dinámica de las propiedades que definimos, que son en si mismas datos (no esquemas) y de los enlaces que se crean entre los recursos. Los sujetos, los objetos y los valores literales son nodos en un grafo y las propiedades son enlaces entre ellos. De esta manera, podemos ver cómo un grafo complejo de relaciones puede surgir de una simple pila de triples en la base de datos. El grafo puede existir en una base de datos o extenderse entre varias.

De hecho, todo el universo se puede describir mediante simples declaraciones de tres partes en una sola tabla sin esquema (la base de datos RDF o triplestore). Esta flexibilidad libre de esquemas significa que no necesitamos conocer todos los requerimientos para nuestros datos siguientes. Podemos construir una app y dejar que los datos evolucionen conforme avanzamos. Podemos escribir la lógica de la aplicación para entender el significado de las propiedades específicas que inventamos o podemos codificar la app para que responda a esas propiedades genéricamente (basado en los tipos de datos). En otras palabras, podemos hacer rápidos cambios a cualquier aplicación solamente cambiando los datos. Dado que la estructura básica del mismo RDF no cambia (siempre es una lista de declaraciones de tres partes), raras veces vamos a cambiar la manera como el código lee estas declaraciones. Aunque expliqué esto a grandes rasgos, resulta ser una solución viable para el rápido desarrollo, evolución e integración de aplicaciones. Así que, quienquiera que haya sido el que respondió a mi pregunta hace tantos años, tenía razón. El RDF sería la clave para crear sistemas centrados en datos de una manera mucho más rápida y dinámica. Y, además, fue en esto en lo que nos basamos para el modelo de datos que Carbon LDP usaría. Da la casualidad de que esta elección de diseño hace que las aplicaciones Carbon LDP sean inherentemente aplicaciones de web semántica o soluciones Linked Data, aunque eso es solo un maravilloso efecto secundario; no era el objetivo original. La meta siempre fue algo sencillo:

• Hacer más rápido y fácil la creación de aplicaciones
• Hacer más fácil modificarlas con el tiempo
• Hacer más fácil integrarlas (enlaces) y aumentar su valor

Con los fundamentos de la web semántica y tecnologías Linked Data como RDF, Carbon LDP evolucionó en una plataforma robusta que logró estos objetivos. Aun así, los desarrolladores no necesitan ser expertos en estos conceptos. Haber pasado por el dolor de toda la curva de aprendizaje nosotros mismos, hemos insistido en que Carbon LDP debería abstraer estos conceptos lejos de toda preocupación. Ahora es una plataforma para crear, evolucionar e integrar aplicaciones rápida y fácilmente como nunca y lo hace de maneras que son accesibles para cualquier desarrollador. Como desarrolladores que hemos batallado con requerimientos que siempre están cambiando y con fechas de entrega casi imposibles, Carbon LDP fue la plataforma que siempre soñamos. Así que la construimos. Ahora, creamos apps rápido, las cambiamos fácilmente y las integramos sabiamente. En resumen, ahora podemos construir soluciones más inteligentes y tú también. Carbon LDP v5 está disponible con dos licencias: Estándar y Enterprise. La versión Estándar es gratuita y tiene todas las funciones usando un sistema de base de datos de archivos locales. La versión Enterprise le da soporte a bases de datos a nivel Enterprise como Stardog y GraphDB™ para construir apps que escalen. No tienes que pasar años estudiando para entender qué es Linked Data; nosotros ya lo hicimos por ti y todo está tras bambalinas. Con Carbon LDP puedes crear apps robustas, centradas en datos, usando mayormente código front-end y teniendo una necesidad mínima de hacer tuberías para el servidor. Quitando toda esta parte dolorosa del trabajo, puedes construir apps más rápido y enfocarte en las partes que realmente importan como la experiencia de usuario.