tv.um.es

Bueno, si se no hay, si no hay más preguntas, de momento, de todas maneras, al final nos va a sobrar, seguramente, algún, algún nos 15 minutos, no podemos aprovechar para resolver aquellas que queden por ahí en el tintero, vale? Bueno, nos movemos entonces a la parte del sistema de gestión, recordando un poco lo que teníamos hasta ahora, según unos datos que hemos importado desde desde unas fuentes de entrada, que ya lo tenemos en un formato. Poco vale, ya hemos hecho todas estas formaciones y demás, y los tenemos en ese formato listos, ya para poder pasar a generar el rbs y seguir con los siguientes pasos que se ahora es de. Esto es lo que se va a encargar el sistema de gestión. Entonces, este este sistema de gestión sea, como decía, será el encargado de recoger los datos en formato del servicio y general, así como sus alegaciones para los enlaces entre ellos del otro de la otra, con la que comentábamos entonces con ellos. Lo que va a hacer es utilizar el la librería de descubrimiento, para validar si se trata de un nuevo recurso o uno que ya existe, que hay que actualizar, o bien es necesario realizar un borrado, por ejemplo. Entonces también va a generar el rdc, apoyándose en la factoría de Uriz, que se va a encargar de darnos esos esos identificadores que antes comentábamos, cuando estábamos hablando de la introducción del rdc. Eso nos lo va a proporcionar, está ese módulo de servicio, denominado Yunis Factory y también de la ingesta del dlr de Essen, el serio del modelo de gestión, junto con con la operación a realizar, por ejemplo, insertar o actualizar o eliminar lo que permitirá disponer también de un loco, de todas las operaciones realizadas en el sistema, pudiendo ser útil. En caso de necesitar restaurada, la información final, en todo, en todos estos sistemas, cine nacional, va registrando todos. Todo lo que ha ido ocurriendo es una especie de los van a ir registrando todos estos eventos, con lo cual si en un momento dado quisiese realizar un rol, va a otro momento, podría reproducir todos los pasos que se han producido desde desde entonces para para volver a para buenos, por un lado, para identificar posibles problemas o, por otro lado, para poder reproducirlo. En caso de pérdida de información también va a ser bastante útil. En cuanto a este series Bus -que del sistema de gestión vemos que éste tiene un icono un poco diferente, y en la tubería, en este caso en lugar de utilizar Kafka, vamos a utilizar otro mecanismo Bale. Uno de los inconvenientes de utilizar Kafka es que no garantiza el orden, no es capaz de garantizar el orden por diferentes motivos, ni tampoco ha sido su cometido. El cometido principal causa es la ingesta masiva de datos, independientemente del orden que en el que llegue a entonces, al no garantizar un orden en podemos tener diferentes problemas o encontrarnos con diferentes problemas. Entonces vamos a necesitar que los datos vayan ordenados en este sentido. Después por esto vamos a utilizar en lugar de un mal el cual utiliza el estándar jm, este tipo de sistema, así que nos nos lo garantizaría, pero de otra manera se utilizaría más o menos de la misma de la misma forma. Luego el procesador de eventos, como ya comentábamos antes, poco sobre ellos, cada uno de estos procesados de eventos en Canarias de consumirlos los mensajes disponibles en este, esta cola del modelo de gestión y enviarlos almacenamiento correspondiente a través de un adaptador. La idea es que exista un procesador de eventos por cada una de las diferentes almacenamiento, como decíamos antes, que vamos a tener en principio va a ser y wiki base, aunque en un futuro se podrían añadir más, y, si es que fuese necesario y fuese necesario hacer una evolución, una ampliación del sistema mediante esta técnica. Pues ya os digo, es muy muy sencillo el poder añadirlo; simplemente tendríamos que añadir un nuevo procesador de eventos que este consumiendo está en esta cola, tener debajo. Una. Una se encarga de hacer esa esa transformación, esa traducción al almacenamiento pertinente. Realmente el procesador de eventos no es que cambie, vale, no, no es nuestro, no tenemos una implementación distinta para cada uno de los de los almacenamientos. El proceso simplemente se va a encargar de escuchar la cola, de consumir los mensajes y luego delegar en unas horas a las lectoras va a tener un una interfaz estándar. Todos ellos Stefan, que está definida igual para todos ellos, lo que cambia su implementación, con lo cual la pieza del Event, de procesos de eventos es la misma. Simplemente hay diferentes instancias de la misma. Otra otra de las ventajas de irnos a una arquitectura de servicios, puedo levantar la misma pieza con diferente configuración? En este caso la confederación diferente va a ser que llama a un servicio distinto de almacenamiento, pero el resto es exactamente igual y aprovechó la misma, la misma, la misma implementación, simplemente levantó diferentes instancias de acuerdo. Entonces, luego, cuando nos vamos a el caso de los, como como decía, bueno, en lugar de añadir la lógica correspondiente a un sistema de almacenamiento se va a utilizar ese adaptador que está especializado en el sistema en concreto. De acuerdo? Entonces es adaptador lo que lo que tiene, como decía, es una, es una pista andar, todos ellos tienen la misma, pero luego se adaptaba a a lo que haga falta. Entonces se van a encargar de transformar en el rbs que van a recibir, que se lo va a enviar el procesador de eventos para que concuerda con el sistema final, como, por ejemplo las las en algunos en algunos sistemas de almacenamiento, como puede ser, por ejemplo, wiki base, tienen que cambiar un poco, tiene una arquitectura de Ourense un poco diferente en el caso de Huawei, que iba a ser, por lo tanto, de alguna manera tenemos que hacer una traducción de esas boris al formato wiki, va a ser, por decirlo así y eso también se va a encargar el lector a Savater para ello, haciendo uso de la factoría de la factoría de Uriz, entonces, donde la odisea en el caso de que iba a ser y griega, entonces la factoría de hybris también va a tener ese registro de esa de esas traducciones para que sea para correr, relacionar ambas, ambas Ulises ambos en ambos formatos. Entonces, como como decía, dentro de este recurso del proyecto pues han desarrollado dos adaptadores diferentes. Uno para caso de trenes y otro para Paraguay, que iba a ser y podrían hacerse, los que les fuesen necesarios para, para, para futuras ampliaciones. Para un poco ya introdujimos un poco un poco el tema, pero bueno, un poco por por profundizar un poco más y con el fin de aumentar la estabilidad y la alta disponibilidad del sistema, pues propone la autorización de el sistema de procesamiento de streaming, de eventos. Este tipo de sistemas están siendo utilizados principalmente en proyectos que requieren el procesamiento de grandes cantidades de datos, sobre todo de ingesta de ingesta de información, consiste en utilizar, mediante una técnica de publicación y suscripción, un look distribuido de solo lectura. La ventaja todas las operaciones es que las operaciones de escrito eran las más eficientes, que las actualizaciones en una base de datos. Entonces, aquí realmente lo que lo que vamos a ir haciendo es cogiendo de todas las fuentes de datos, y metiendo ahí los los datos, y luego ya se procesará posteriormente por quien porque los consuman hoy de esa forma un poco la la los diferentes los diferentes módulos era un poco, un poco hablando del tema. Este procesamiento en streaming. Pues bueno, pues normalmente se suelen utilizar para pagar. Como decía, para hacer ingestas masivas de información se producen datos en todo momento en que, hablando en términos más generales fuera del ámbito de este proyecto, pues se están produciendo en todo momento datos en diferentes fuentes, después temas de movilidad, de temas de y yo te de logística, transacciones financieras, etc, etc. Ahí hay muchísima información que se está produciendo y, y para poder aprovecharse de ello necesitamos una plataforma que soporta la ingesta de grandes volúmenes de información, y aquí hay un poco en juego las herramientas, como por ejemplo este tipo de, como hacía este tipo, de. Si te vas a la final es eso, es, pues una publicación y suscripción es ahora mismo estamos viendo cómo todos estos elementos se están publicando información dentro de la de la cola, Kafka sería los los productores. Se cargan de describir en la la la cola desde diferentes fuentes de datos, pero luego por el por el otro lado de la cola, pues vamos a tener una serie de consumidores, ya sea uno o varios. Bueno, ya hemos visto ejemplos de los dos casos había. Teníamos disponibles colas que vamos a tener solamente un consumidor. Pero, por ejemplo la del la de la gestión de eventos o del módulo de gestión, pues teníamos varios consumidores. Uno para cada uno de los diferentes almacenamientos que tenía. Entonces. Cada uno va a hacer con los datos un poco lo que lo que considere, lo que considere oportuno y le haga falta realmente le va a llevar a todos todos los datos y cada uno es muy libre de hacer. Con ellos lo que quiere está un poco, tiene un poco independientes entre sí cada uno de los de los consumidores en ese. En ese sentido, entonces realmente lo que estamos consiguiendo es ese acoplando los productores de los de los consumidores, totalmente, lo cual implica que pues que puede darse el caso de que el consumo o el tratamiento posterior de la información sea más lento en algunas partes. Que la producción de los datos entonces, de esta manera al poder destacó no impacta no es decir puede podemos estar gestando datos en el sistema de una forma masiva de una forma muy rápida. Todo ello quedaría distribuido por ejemplo, toda esta información y luego los consumidores, cuando tengan disponibilidad, ya pueden seguir trabajando todos esos eventos, todos esos mensajes y tardando el tiempo que necesite cada cada uno de ellos. De esa manera conseguimos que no impacte en la producción de información. El hecho de que uno de los consumidores tarde tardé más tiempo del necesario o del previsto, no. Entonces en ese, en ese sentido, nos va a dar una ventaja, una ventaja enorme. Entonces, otras otras ventajas. Es también que un fallo de un consumidor no, no nos vaya a afectar a todo el sistema. Evidentemente, tanto el resto de consumidores como como los productores van a poder seguir trabajando con normalidad, también que sería sería posible añadir nuevos consumidores en caso de que fuese necesario al sistema sin afectar a los a los productores, que ya tenemos un poco también lo que lo que antes comentamos de cara a los distintos almacenamientos no era algo que podríamos que podríamos conseguir gracias a una, a una arquitectura de tipo tipo. Cuando cuando nos vamos a a mundo digamos que sale el concepto de tópico entonces, que es realmente un tópico, es un es un sprint de mensajes relacionados entre sí; es una, por decirlo de alguna, era una especie de Colau, ese es el look distribuido que como con una serie de mensajes que nos van a servir para para un fin común antes antes veíamos que teníamos varios, varios topes no puede ser bush general, pues eso sería un tópico. Teníamos el exterior del módulo de entrada o series Bus de de los enlaces; ese sería otro y luego tendríamos el de los del modelo de gestión, que sería otro otro topic, cada uno de esos es para una finalidad en concreto son son mensajes diferentes realmente mal entonces por ello por eso digamos hablamos de mensajes relacionados. Los que componen un punto que se relacionados entre sí mediante una representación lógica. Los topics, evidentemente, son definidos en tiempo de tiempos de desarrollo final, es lo que necesite. Cada una de las aplicaciones no podía ser de otra de otra manera, y luego en cuanto a relación productor topic, pues podría ser aena. Es decir, podríamos estar hablando de que un mismo productor sea capaz de escribir en un tópico o varias ejemplo. Antes vimos que iba a escribir en 2. Entonces topics, vale una para los objetos, planos y otro para para los objetos de tipo de tipo; enlace para los enlaces entre entre ellos, pero también la relación podría ser a la inversa, no es decir que tenga varios varios productores escribiendo sobre sobre el mismo sobre el mismo tópico, por ejemplo, en estas relaciones en esta aplicación. No sé no sé si no se va a dar este caso, pero, por ejemplo, pongamos en el caso de una de una aplicación de la que tengamos diferentes dispositivos enviando información, pues, por ejemplo, en el mundo logístico, no que tengamos diferentes diferentes caminos enviando su su ubicación; o la temperatura de que está teniendo dentro novel para mantener la cadena de frío. En ese caso, digamos que tendríamos varios dispositivos escribiendo en el mismo topic pueden ser un poco las relaciones en aena, pero también las relaciones sería de cara a los a los consumidores, no al final, como como vimos antes, nos va a permitir tener varios consumidores leyendo del mismo, del mismo, del mismo tono. Bueno, también es posible tener un número de topes y limitado, bueno, invitado entre comillas, porque al final será limitado por lo que no soporta el sistema cielo, por los recursos del propio sistema que éste está implementado y luego también vemos que los que están divididos en distintos en distintas partición, dentro de Kafka. Entonces, normalmente los mensajes, pues lo va a gestionar, los va a ir dividiendo en distintas las distintas peticiones de las que se compone el tópico al final, digamos que serían como una especie de sus colas, por decirlo de alguna manera, en las que se van insertando la información, pero en este caso el control lo tendría un poco un poco normalmente por defecto, pues esa esa determinación las suele hacer por por una clave de registro que se envía desde el productor. Pero bueno, yo digo que eso es lo normalmente, lo va a gestionar, gestionar también también, esto se suelen utilizar la las participaciones para facilitar los consumidores paralelos, que podamos tener más de más de un consumidor, leyendo sobre la misma, la misma cola. Esto no quiere decir no estoy hablando del caso que estábamos viendo antes de tener varios consumidores escuchando para fines distintos, sino que estábamos hablando de escalar un mismo consumidor, es decir, en ese caso cuando un mismo consumidor para para salvar una situación de cuello de botella, porque tenemos muchísimos mensajes y que queremos tener varios, que varios consumidores que procesen para agilizar lo que nos interesa. Es que no es que vayan llegando todos los mensajes a todos, sino que cada consumidor reciba una porción, una porción de ellos. Entonces mediante la técnica de partición es ese facilita esa esa, esa posibilidad de tener consumidores trabajando en en paralelo, no? Entonces la posibilidades que tendríamos es que podríamos estar consumiendo registros en paralelo hasta el número de participantes que tengamos también por este motivo. El tema de las participaciones no es bueno, es uno de los motivos por los que no se garantiza el orden y el orden. Se garantiza nivel de partición, pero si tenemos más de una partición, que es lo habitual, al menos tener dos digamos que que el orden ya no es garantizado, vale? Entonces un poco un poco por ese motivo que tuvimos que meter un sistema que sí que es lo que sí lo soporta, como como comentamos, como comentábamos antes de acuerdo, bueno, un poco, un poco como cómo funciona todo todo esto, pues vamos, que ya yendo a nivel de partición quizás vale. Pues vemos que se van insertando en el orden de forma secuencial pues empezaríamos por el por el obsequio número cero así sucesivamente y bueno pues el siguiente y tenga a escribir ya al final. Aquí por ejemplo, seguiría. Pues eso vemos cómo iría escribiendo el número 11, pero tendríamos dos consumidores y uno estaría estaría más adelantado que el otro. Uno estaría leyendo el número 10. Sin embargo, tenemos un poco más lento que sigue, si bien el cuadro esto no es ningún problema dentro de dentro, dentro de Kafka y precisamente es una de las de las ventajas, del poner, el poder de como decíamos, la escritura que va por arriba van una velocidad y luego por debajo distintos distintos consumidores con con distintas velocidades, uno más lentos y otros más veloces son estos soportado perfectamente por este tipo de arquitectura y además una de las ventajas que nos permite que nos permite lidiar con este tipo de situaciones. Un poco Un poco más de lo mismo en este caso Bale entonces bueno nada este estilo arquitectónico pues se ha denominado normalmente por su arquitectura tipo capa suele materializarse normalmente mediante el uso de Kafka, como como estamos viendo, el cual va a tener puesto de esas ventajas que decíamos. Buena utilización de Un lobo, distribuido como fuente de verdad, permitiendo desarrollar diferentes vistas de los mismos datos. Una vista vista, puede ser Una base de datos rdc o índice de búsqueda como las bueno, al final quiere decir es que vamos a poder tener diferentes consumidores que vayan que vayan a que estén leyendo sobre los mismos datos, pero cada uno va a hacer lo que tenga que hacer, ya sea insertar en Un lastre y ensartar en Una base de datos rdc, generar Un informe. Bueno, son ejemplos de todo lo que se podría hacer. No se podía hacer todo lo que lo que lo que queramos, pero quedamos con eso. No podemos tener distintos consumidores y cada uno de ellos hará lo que tenga que hacer con los mismos datos. Vale, muy, muy importante. Lo ha dicho. Si Una aplicación productora de eventos comienza a fallar generando datos incorrectos, sería sencillo modificar los consumidores para que ignoren datos, datos erróneos también. Si tuviésemos Una base de datos que llegásemos a corromper, pues ya tendríamos Una restauración mucho más, más complicada e incluso bueno ahora tener que utilizar otros mecanismos más más agresivos, seguramente, y también el tema de la depuración, pues puede ser más, más sencillo, al ir leyendo todos los desde Un pUnto dado, pues podemos ir viendo cómo se ha ido modificando los registros por todos los estados, pueblos que han ido pasando para poder llevar a Una determinada Una determinada situación. Vale, bueno, eso también puede facilitar el análisis de datos posterior, muchas, muchas ocasiones, pues eso es mucho más útil entender cómo se ha llevado a un estado que dispone únicamente del fino. Entonces es bueno. Vale, entonces, suena un poco como, como antes ya comentábamos, un poco un poco, cuando ésta lo estábamos viendo en la arquitectura, Kafka no está diseñado para garantizar el orden de los eventos enviados. Es por ello que en los casos en los que sea necesario garantizar este orden, apostar por otro tipo de otro tipo de sistemas y, en este caso el sistema tipo j. Meses, como es Astiz Astiz veintidos, es un broker de mensajería o piensos que implementa la especificación j j Mesa y por tanto preservando ese ese orden de mensajes enviados. Messi tiene dos modos de funcionamiento, por decirlo de alguna manera, tendría la opción de publicar mensajes a un tópico o a una cola. Hay una diferencia fundamental entre entre ambas aproximaciones, que está aquí un poco. Expresaban un topic, digamos, que envía el mensaje a, desde el productor a varios consumidores al mismo tiempo como una especie de. Esto es normalmente llamado publicación, suscripción vale mucho más parecido a lo que sería Kafka, que sería trabajaría de esta misma manera a todos los consumidores les llegaría todos los mensajes. Sin embargo, una cola podría podría tener también varios consumidores, pero en este caso redirige cada mensaje. Solo a un consumidor los consumidores esperarían en línea en la cola tomando tornas para obtener los nuevos mensajes; sería una especie de antes, hablábamos de procesamiento, paralelo, puedo decirlo de alguna manera. Bale? Entonces sería también llamada. Muchas veces estamos a la forma de trabajar aquí simplemente, bueno, saber que existen estos dos mecanismos. En el caso de que nos atañe de este, de esta aplicación. Nosotros, para dado que vamos a trabajar, vamos a intentar suplir una carencia de Kafka, lo que necesitamos es que funcione como Kafka, pero pero de forma de forma que garantice el orden. Entonces, por ello vamos a ir con la modalidad de las medidas de Tropic Bale, o sea, la segunda que tenemos aquí que tenemos expresada aquí abajo, que fue la primera, que entonces sería un poco un poco. Eso todos los mensajes van a llegar a todos los consumidores. Ya hemos visto un poco como cómo trabaja. Bueno, el sistema de gestión que hemos visto, porque trabajamos con un procesamiento en streaming. Llega el tono un poco de ver cómo se va a proceder a generar el él. En este caso vale? Entonces, digamos que haciendo recapitula un poco, decíamos que tele bajan, eran los ojos los ojos. Los baleares, sistema de gestión, y con ello general el rbs vale? Esto como hacíamos tiene un tiene un problema que necesitamos, por un lado, tener los objetos planos, y, por otro, las relaciones para no tener problemas a la hora de insertar estas últimas de tener que que detener casos como, por ejemplo, de que no exista un objeto relacionado en un momento dado. Entonces, para ello vamos a ir con los objetos lados. Planos por un lado y con las relaciones por otro. Entonces, la estrategia que vamos a seguir es un poco, es un poco esa. La tele, lo que se va a encargar de generar todos los objetos planos en ese momento va a entrar en juego. El sistema de gestión que va a empezar a consumir los los mensajes que le llegan desde la tele, con este tipo de objetos, va a generar el rbs para los mismos y los va a enviar a la que para que se inserten en los diferentes sistemas de almacenamiento. Entonces con eso lo que vamos a conseguir es una, una primera versión de la información que simplemente son recursos, pero están todos son todo como como como islas es un archipiélago de islas están que no están interconectadas entre entre sí entonces lo que necesitamos es poder conectar, establecer puentes entre entre entre ellas y para eso entraría en juego las relaciones. Las relaciones se van a enviar por la parte de una buena segunda pasada, por decirlo de alguna manera, y también van a ser procesadas después por parte del sistema de gestión. Este caso no va a estar escuchando continuamente por las relaciones, sino que en el momento en el que termine de procesar todos todos los sujetos planos de una carga, va a empezar a procesar las relaciones entre entre los mismos y con eso vamos a actualizar el rbs. Con todas esas relaciones, añadiendo las dietas necesarias para interconectar establecer esos puentes entre entre los diferentes recursos, que se vayan a que se vayan a insertar que se vayan a que vayamos a tener, y con ellos, ya conseguiremos el todos los datos en el formato final, con todas las relaciones para poder ser explotados y, por otros, por otros sistemas para otorgarle la potencia necesaria, los a los mismos. Entonces, viendo un poco un poco como los datos que nos van a venir, un ejemplo de un objeto plano de lo que no nos va a llegar desde la tele sería seria. Esto no sería un objeto en formato y eso que iba a tener una serie de una serie de información. En primer lugar, por ser la operación que se va a llevar a cabo, como puede ser. En este caso, se está indicando que sea una inserción. También podríamos estar hablando de actualizaciones o eliminaciones de información, es importante saberlo para saber lo que tenemos que hacer después. Con estos datos. Después, los datos en sí mismo que aquí estamos, como decíamos antes, están llegando a unos datos en formato de tipo literal. Perdón, vale. Como puede ser, pues pues en este caso están definiendo unos datos de un proyecto, pues podría ser el título del proyecto tenga una fecha de inicio y finalización una modalidad etc etc etc con ello con todo con todo esto lo que va a hacer el sistema de gestión va a ser coger unos coger este este guiso y con ello generar en las redes utilizando apaches como como antes comentamos para en primer lugar general el modelo y luego, posteriormente general, el lro de un formato y enviarlo a la cola de la cola de del sistema de gestión de eventos para que luego estén los los los a Sabater y demás, adaptándolos al almacenamiento pertinente. Esto, como vemos, no tiene ningún tipo de relación con otros, con otros elementos, pero aquí ya es donde llega. Entra en juego también no el la. Los datos, los enlaces los lisos. Las grabaciones, mejor dicho, de los datos que ya van a ir en una segunda pasada como como comentábamos, donde por un lado nos va a llevar en el caso de la operación, vale para diferenciar un poco de los anteriores, pero este es el que nos va a decir que se va a insertar líneas sobre sobre unos objetos que ya tenemos. Dónde identificamos los datos? En este caso sería un dato de tipo proyecto con el identificador, equis, vale y lo vamos a aplicar a diferentes diferentes recursos, no. Por un lado podríamos encajarlo a objetos de tipo factura. En este caso no tendríamos ninguno. Iría a la relación vacía, pero por ejemplo, sí que tenemos personas que forman parte de ese ese proyecto que teníamos, hay unas cuantas unas cuantas a las cuales se generaría esa se añadirían esas tripletes perdón, se añadiría al proyecto triplete para relacionarlo con todas estas. Con todas estas personas. Estas personas que ya existen porque ya los hemos insertado en la primera, la primera pasada, como como acabamos de ver ver bale es un poco el proceso de el proceso de generación, sería sería ese prolongado objetos planos y, por otro lado, los enlaces y-Congreso Ya. Todo el todo se completó con todos los datos enlazados entre sí formando una estructura de tipo de tipo, como veamos al principio, que al final es lo que lo que nos interesa tener. En cuanto a la. En cuanto a la relación con la factoría de, de acuerdo. También es también es muy importante un poco verlo vamos la factoría de va a ser la encargada de asignar las urnas a los recursos generados de acuerdo con la política de Ourense establecida para el sistema. Vale al final porque significa el sistema de gestión. Su cometido es generar, agradece a partir de unos datos, pero no sabe de Orissa final de algún lado. Se tiene que informar de la de la de Las Furias, que tiene casi a los a los recursos que le están llegando. Entonces, ahí es donde viene un poco al rescate, la factoría de uri se va a encargar de degenerar todas esas esos identificadores que le vamos a asignar, no solo a los recursos, sino también Ory. Es que hay que indicar a los a los atributos, es decir, el recurso va a tener su propio Aguri, pero cada uno de los atributos va a tener la suya propia que lo identifique antes. Antes veíamos el caso del proyecto. Pues si es verdad que el proyecto va a tener sur y en general que identificar ese proyecto en concreto, pero luego el título va a tener su sur y que identifica que son atribuibles, tributo título El la fecha de inicio y la fecha de firmas a tener el suyo propio, la modalidad va a tener el suyo propio, y así sucesivamente. No todos eso también son para indicar los atributos, con lo cual necesito un sistema que me facilite toda esa, toda esa información. El sistema de juristas hace un poco de pegamento o, si me lo permitía, entre la arquitectura semántica que es este, este módulo esté este bloque que estamos viendo hoy, pero hace pegamento entre la semántica y la infraestructura, o antológica, que veréis mañana ya que, como decía antes, la infraestructura antológica va a definir los datos, la estructura que va, que precisa tener esos datos y, por tanto, va a establecer los tipos y los atributos que va a tener cada uno de los recursos, y va a tener una integración también con la factoría de Ourense, porque tiene que registrar todo eso sea la factoría de. Tiene que conocer todas esas que son, se han definido por parte de la antología, con lo cual ahí en esa factoría de Orense, donde donde se estaba un poco uniendo ambos ambos ambos mundos ambos ambas partes del sistema entonces de cara al sistema de gestión, llevamos que esa factoría de obras nos va a dar todo eso, tanto el identificador para ese recurso en concreto, como todas las series que necesite para poder componer el que será el tipo, el tipo del recurso, es decir, las clases o si vamos a un mundo oriental, objetos que es de tipo proyecto proyecto, tendrá su sur identificativa y también de los atributos acuerdo, pero también hay otro otro punto, otro punto, otro punto importante, ya que durante todo este procesamiento de datos va a ser necesario realizar las tareas de conciliación y descubrimiento de entidades en otras fuentes de datos enlazados. Vale? Entonces ahí también en juego? La librería de descubrimiento que vemos aquí esta librería de descubrimiento nos va a permitir saber si un recurso que nos está llegando es un recurso que ya tenemos en el sistema, poder discernir si es así mediante mediante diferentes algoritmos. Por ejemplo, puede ser que nos llegue el investigador equis vale, pero ese investigador que se llama pues tenemos que saber si tiene correspondencia con otro investigador que se llama Xhaka en el sistema o por el contrario es otro otro investigador distinto. No? Entonces eso se va a cargar un poco. La librería, descubrimiento, en base a una serie de base de una serie de algoritmos, va a evitar precisamente el tener datos que vienen de distintos fuentes, vale? El que podamos tener duplicados de información? Al final es, por ejemplo, si nos vamos a una agenda telefónica en la que tengamos diferentes contactos, esa va a hacer esa labor de identificar cuáles son los mismos, cuales son equivalentes y hacernos, mediante digo, mediante una serie de algoritmos el poder discernir de forma automatizada si son si son diferentes o no? Habrá casos, evidentemente en lo que eso no es posible hacerlo de forma de forma automatizada mediante un razonamiento automático, y tendrá que entrar algún alguna, alguna labor manual por el medio, lógicamente no, pero bueno, lo habitual sería que la mayor parte de los casos se consiga mediante un razonamiento automático, y luego habrá otros. Habrá que dar soporte a esos otros en los que en los que no va a ser, no va a ser posible hacerlo de una forma tan, tan automática y tiene que intervenir un humano para poder, para poder conseguirlo un poco quedar con la idea de todo esto. Todo esto también se se va a explicar en posteriores sesiones. Hay sesiones más específicas de la factoría de misil y del descubrimiento, ya que tienen mucha, mucha enjundia en el sistema, pero buenas de cara a la sesión de hoy. Es importante tener claro las piezas que hace cada cada una de las de las piezas que desempeñan en el sistema. Si tenéis alguna duda con respecto a toda esta parte que estamos viendo, si no, pasamos a la siguiente. Bueno, bien, no sé si está siendo muy pesada la formación, igual demasiado teórica, no, por eso es el principio de todo esto y recogiendo todo lo que teórico y luego vaya poco a poco, pero muchas veces tiene claro que la estructura y como estaba de momento está claro. Por mi parte lo mejor. Yo al principio lo hago más adelante. Cuando empezaron a surgir las dudas, cuando nos metamos más lo que más estamos, si estas primeras sesiones son un poco más teóricas que siempre conviene tenerlo un poco más, más claro, aunque sea así una visión general, luego ya van a ser un poco más tácticas. Así entiendo que será un poco más amenas también de caras, de cara a abordar las noticias. Buenas. Vale? Pues si nada se parece.