Estoy desarrollando una aplicación que necesitará almacenar metadatos en línea e intext . Lo que quiero decir con eso es lo siguiente: digamos que tenemos un texto largo y queremos almacenar algunos metadatos relacionados con una palabra u oración específica del texto.

¿Cuál sería la mejor manera de almacenar esta información?

Mi primer pensamiento fue incluir en el texto algún tipo de Markdownsintaxis que luego se analizaría en la recuperación. Algo parecido a esto:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam __nonummy nibh__[@note this sounds really funny latin]
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Esto introduciría dos problemas en los que puedo pensar:

1. Una relativamente pequeña es que si dicha sintaxis se encuentra fortuitamente en dicho texto, puede interferir con el análisis.
2. La más importante es que esto no mantiene estos metadatos separados del texto en sí.

Me gustaría tener una estructura de datos discreta para almacenar estos datos, una tabla de base de datos tan diferente en la que se almacenan estos metadatos, para poder usarlos de manera discreta: consultas, estadísticas, clasificación, etc.

EDITAR: Dado que el respondedor eliminó su respuesta, creo que sería bueno agregar su sugerencia aquí, ya que fue una sugerencia viable que se amplió en este primer concepto. El póster sugería usar una sintaxis similar, pero vincular los metadatos a la tabla PRIMARY KEYde la metadatabase de datos.

Algo que se vería así:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam __nonummy nibh__[15432]
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Donde 15432sería el IDde una fila de la tabla que contiene la información necesaria y consultable, como en el ejemplo a continuación.

Mi segundo pensamiento fue almacenar información de este tipo en una tabla de DB con el siguiente aspecto:

TABLE: metadata

ID    TEXT_ID    TYPE    OFFSET_START    OFFSET_END    CONTENT
1     lipsum     note    68              79            this sounds really funny latin

De esta forma, los metadatos tendrían una identificación única, text_idcomo una clave externa conectada a la tabla que almacena los textos y conectaría los datos con el texto en sí mismo utilizando un rango de desplazamiento de caracteres simple .

Esto haría el truco de mantener los datos separados de los metadatos , pero un problema que puedo ver inmediatamente con este enfoque es que el texto básicamente no sería editable . O, si quisiera implementar la edición del texto después de la asignación de metadatos, básicamente tendría que calcular la adición o eliminación de caracteres en comparación con la versión anterior, y verificar si cada una de estas modificaciones agrega o elimina caracteres antes o después de cada de los metadatos asociados.

Lo cual, para mí, suena como un enfoque realmente poco elegante.

¿Tiene alguna sugerencia o sugerencia sobre cómo podría abordar el problema?

Edición 2: algunos problemas XML

Agregar otro caso que haría bastante necesario que esta separación de datos y metadatos suceda.

• Digamos que quiero hacer posible que diferentes usuarios tengan diferentes conjuntos de metadatos del mismo texto , con o sin la posibilidad de que cada usuario muestre los metadatos del otro usuario.

Cualquier solución del tipo de descuento (o HTML, o XML) sería difícil de implementar en este momento. La única solución en este caso en la que podría pensar sería tener otra tabla DB que contendría la versión de un solo usuario del texto original, conectándose a la tabla de texto original mediante el uso de a FOREIGN KEY.

No estoy seguro si esto es muy elegante tampoco.

• XML tiene un modelo de datos jerárquico: cualquier elemento que se encuentre dentro de los límites de otro elemento se considera hijo , lo que no suele ser el caso en el modelo de datos que estoy buscando; en cualquier XML hijos elemento debe estar cerrada antes de que el padre etiqueta puede ser cerrado, lo que permite sin superposición de elementos.

Ejemplo:

<note content="the beginning of the famous placeholder"> Lorem ipsum dolor sit <comment content="I like the sound of amet/elit"> amet </note> , consectetuer adipiscing elit </comment> , <note content="adversative?"> sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.<note content="funny latin"> </note> </note>

Aquí tenemos dos problemas diferentes:

1. Superposición de diferentes elementos: el primer comentario comienza dentro de la primera nota, pero termina después del final de la primera nota, es decir, no es su hijo.

2. Los mismos elementos se superponen: la última nota y la nota en negrita se superponen; sin embargo, dado que son el mismo tipo de elemento, el analizador cerraría el último elemento abierto en el primer cierre, y el primer elemento abierto en el último cierre, que, en esta circunstancia, no es lo que se pretende.

Buscaría una combinación de sus soluciones, pero en su lugar, usaría un estándar: XML. Tendrías una sintaxis como esta

Lorem ipsum dolor sit amet, consectetuer adipiscing elit,
sed diam <note content="It sound really funny in latin">nonummy nibh</note>
euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Por qué XML

Si lo piensa, es exactamente cómo está estructurada toda la web : contenido (texto real) que lleva semántica, lo que llama metadatos , a través de etiquetas html.

De esta manera tienes un mundo realmente genial que se abre:

• Analizador gratuito
• Batalla probada para agregar metadatos al contenido
• Facilidad de uso (según los usuarios a los que se dirige)
• Puede extraer fácilmente el texto sin formato, sin los metadatos, ya que es una característica estándar en los analizadores XML. Es muy útil tener una versión indexable de su contenido, por lo que Lorem <note>ipsum</note>se genera cuando está buscando, lorem ips*por ejemplo.

Por qué XML sobre Markdown

Un sitio web como stackexchange usa markdown ya que la semántica que transmite su contenido es bastante básica: énfasis, enlaces / URL, imagen, encabezado, etc. Parece que la semántica que está agregando a su contenido es

1. Mas complejo
2. Sujeto a cambios o debe ser extensible

Por lo tanto, siento que Markdown no sería una muy buena idea. Además, Markdown no está realmente estandarizado, y analizar / descargar puede ser un dolor de cabeza, incluso una sintaxis más marcada ver la publicación de Jeff Atwood sobre el WTF que conoció al analizar Markdown .

Sobre la separación entre datos y metadatos

Per se, tal separación no es obligatoria. Supongo que está buscando la ventaja que trae:

• Posibilidad de tener el contenido sin los metadatos.
• Separación de preocupaciones: no quiero tener sobrecarga de efectos secundarios / complejidad al manipular metadatos debido a los datos, y de otra manera.

Todas estas preocupaciones se resuelven mediante el uso de XML. Desde el XML, puede volcar fácilmente cualquier contenido despojado de etiquetas, y los datos / metadatos están separados, al igual que el atributo y el texto real está separado en XML.

Además, no creo que realmente pueda tener sus metadatos totalmente no vinculados a sus datos . Por lo que describe, sus metadatos son una composición de sus datos, es decir, eliminar los datos conduce a la eliminación de metadatos. Aquí es donde los metadatos divergen del HTML / CSS habitual. CSS no desaparece cuando se elimina un elemento html, porque puede aplicarse a otros elementos. No creo que este sea el caso en sus metadatos.

Tener metadatos cercanos a los datos, como en XML o Markdown, permite una fácil comprensión (y quizás depuración) de los datos. Además, el ejemplo que da en su segundo pensamiento agrega cierta complejidad, porque para cada dato que estoy leyendo, necesito consultar la tabla de metadatos para obtenerlos. Si la relación entre sus datos y sus metadatos es 1: 1 o 1: N, entonces es IMO claramente inútil, y solo trae complejidad (un buen caso de YAGNI).

El caso de uso de la solución

No estoy de acuerdo con algunas de las otras respuestas, simplemente porque, si bien son excelentes soluciones, probablemente no sean su solución. Sí, XML tiene la marca de palabra en sus siglas, pero probablemente no sea ideal para su situación. Es demasiado complejo, ofrece poca ayuda para mantener los metadatos separados del texto original. Básicamente, convertirá todo en una forma de metadatos, creando un conjunto de datos con sobrepeso.

Como es probable que no haya una solución o enfoque absolutamente correcto, la mejor solución responde a la pregunta:

¿Cómo serán utilizados los datos por el sistema?

Además, si intenta preguntar, cómo un diseño de solución podría agregar de manera inherente al valor del sistema, en la forma en que se utilizará, entonces está más cerca de encontrar su respuesta elegante .

Entendiendo el problema

Ok suficiente comentario, profundicemos en el problema. Este es el problema tal como lo entiendo (obviamente, agregarlo será beneficioso):

• Hay un texto original
  • Suposiciones sobre este texto original:
  • Este texto, puede o no estar compuesto por varios documentos independientes
  • Este texto, puede o no ser editado por uno o más usuarios
  • Este texto contiene información relacionada . Por eso estoy asumiendo (corríjame si estoy equivocado) que los metadatos están relacionados y no son descriptivos . Por lo tanto, almacena información relacionada con el texto original, y no información que describe el texto. Así que va a guardar notas sobre el texto original, y no por ejemplo describir que el texto es un encabezado que es audaz y es un enlace a una página web, etc.
  • El texto debe filtrarse fácilmente, distinto de los metadatos.
  • El texto debe protegerse para que no se corrompa y corrompa los metadatos.
• Debe haber un medio para almacenar información relacionada con el texto original (metadatos)
  • Estos metadatos también necesitan sus propios metadatos (meta), que contendrían información como para qué usuario (o grupos) son relevantes los metadatos, como una descripción de los metadatos, por ejemplo, si es una nota o un comentario, o descripción etc.
  • Estos metadatos (y sus metadatos) deben soportar alteraciones en el texto original, alteraciones de los metadatos y alteraciones de los metadatos (meta).
  • Los metadatos (+ meta-metadatos) deben estructurarse bien y consultarse fácilmente, indexarse ​​o incluso unirse de manera relacional a otros conjuntos de datos. La naturaleza relacional de los metadatos no solo debe limitarse a las consultas, sino también facilitar las actualizaciones o la reescritura y la alteración de los metadatos como resultado de las actividades de datos relacionales.
  • El valor de los metadatos (+ meta-metadatos) está en su naturaleza muy relacionada . Se vuelve inmediatamente contraproducente en el momento en que pierde su relación con el texto original. Por lo tanto, la integridad de su relación con el texto original es un imperativo de diseño obligatorio.
• Otros supuestos sobre la naturaleza del problema y cómo se utilizará son:
  • Acceso al sistema heterogéneo concurrente. Es decir que el usuario puede desear ver el texto y editar metadatos, al mismo tiempo que el administrador (u otro proceso) realiza consultas de datos relacionales en los metadatos estructurados.
  • El sistema tendrá varios usuarios.
  • El sistema es moderno. Es decir que no está limitado por el espacio de almacenamiento, la velocidad de procesamiento o los imperativos en tiempo real. La funcionalidad centrada en la integridad y el propósito es una prioridad más alta que las limitaciones físicas de los recursos informáticos.
  • Existe una posibilidad (aunque baja) de que los usos y la funcionalidad del sistema puedan evolucionar o cambiar un poco, a medida que se utiliza el sistema.

Construyendo el diseño de la solución

Comprendiendo el problema como lo he descrito anteriormente, ahora comenzaré a sugerir posibles soluciones y enfoques que tengan como objetivo resolver el problema anterior.

Componentes

Por lo tanto, vería que debería haber un sistema de acceso de usuario personalizado. Filtraría metadatos relevantes e irrelevantes del texto original. Facilitaría la edición y visualización de metadatos en el texto. Aseguraría la integridad de la relación entre los metadatos y su texto original. Estructuraría los metadatos y ofrecería una fuente de datos a un sistema de datos relacionales. Lo más probable es que proporcione una gran cantidad de otras funciones orientadas a un propósito.

Estructura

Por lo tanto, dado que es importante mantener la integridad de los metadatos en el texto original, la mejor manera de garantizar esto es mantener los metadatos en línea con el texto original. Esto ofrecerá el beneficio de que los datos originales se pueden editar con confianza sin romper esta integridad.

Las preocupaciones con este enfoque son la corrupción de los metadatos por los datos originales y viceversa. La adecuada indexación y estructuración de los metadatos y sus (meta) metadatos de una manera que permita consultas y actualizaciones y un acceso eficiente. El fácil filtrado de metadatos del texto original.

Con esto en mente, sugeriría que una parte de la solución se base en el enfoque de usar PERSONAJES DE ESCAPE dentro del texto original. Esto no es lo mismo que diseñar su propio lenguaje de marcado o usar un lenguaje de marcado existente como XML o HTML. Es fácil diseñar un CARÁCTER DE ESCAPE que tenga una probabilidad de cero o casi cero de existir en el texto original.

Mi consejo para usted a este respecto sería considerar cuidadosamente los datos originales, y tratar de determinar la naturaleza de la página de códigos en la que está almacenada y luego buscar un CARÁCTER ideal o SECUENCIA DE CARÁCTEReso es poco probable o imposible de ocurrir. Por ejemplo, en ASCII hay literalmente caracteres de control integrados con valores de bytes que nunca se usan en las interfaces de usuario estándar. Lo mismo puede decirse de un sistema de información basado en fuentes o en datos relacionales. Solo tenga cuidado con los códecs de datos binarios. Dependiendo de la naturaleza de los datos originales, puede ser valioso construir un analizador que confirme el descubrimiento de una secuencia de control, tal vez observando los datos que se escapan y verificando su integridad, ya sea con una simple inspección de la estructura del escapado. datos, o incluso mediante la inclusión de un carácter de control que se calcula para cada secuencia de datos escapada.

Datos de ejemplo con secuencias de escape

Esta es una historia de un hombre. >>>> (#) ¿Por qué es esta historia sobre un hombre y no una mujer? (#) ( ) Userid :: 77367 ( ) Comentario del gerente ( ) DataID :: 234234234 >>>> Un hombre que fue a cortar un prado, Fui a cortar un prado. El hombre fue con su perro >>>> (#) Pregúntele al cliente si la historia sería mejor con un gato (#) >>>> para cortar el prado. Así que ahora esta es la historia de un hombre y su perro que fueron a cortar un prado.

Un hombre y su perro, fueron a cortar un prado, fueron a cortar un prado, un prado alcanzado sobre la montaña. >>>> (#) Esto suena mucho mejor con un bosque (**) Sugerencia Nota (#) >>>>

El hombre y su perro y su misión, para cortar un prado, un prado alcanzado sobre la montaña solo se alcanza al cruzar el río.

Datos de ejemplo sin secuencias de escape

Esta es una historia de un hombre. Un hombre que fue a cortar un prado, fue a cortar un prado. El hombre fue con su perro a cortar el prado. Así que ahora esta es la historia de un hombre y su perro que fueron a cortar un prado.

Un hombre y su perro, fueron a cortar un prado, fueron a cortar un prado, un prado alcanzado sobre la montaña.

El hombre y su perro y su misión, para cortar un prado, un prado alcanzado sobre la montaña solo se alcanza al cruzar el río.

Obviamente, esto se analiza fácilmente, no es complejo como un lenguaje de marcado completo y se adapta fácilmente a su propósito.

Resuelto todavía? Bueno, yo diría que no. Nuestra solución todavía tiene algunos agujeros. La indexación y el acceso estructurado de estos datos es deficiente. Además, no sería razonable consultar este archivo (o varios archivos) al mismo tiempo que lo edita.

¿Cómo podríamos resolver ese problema?

Sugeriría una TABLA DE ASIGNACIÓN DE DATOS como encabezado del documento. También sugeriría implementar una COLA DE ACTUALIZACIÓN DE TABLA TRANSACCIONAL . Dejame explicar. Los diseñadores de un sistema de archivos, particularmente un sistema de archivos de disco rotativo, enfrentaron desafíos de diseño similares a los que usted describió anteriormente. Necesitaban insertar información sobre los archivos en el disco junto con los datos. Una gran solución para la integridad de la relación de estos datos fue DUPLICARLA en una Tabla de asignación de archivos (FAT).

Esto significa que para cada elemento de metadatos individual, hay una entrada correspondiente en la tabla de asignación de datos . Por lo tanto, es rápido, estructurado y relacional, e independiente de los datos originales. Si es necesario realizar consultas, uniones o actualizaciones en los metadatos, entonces se hace fácilmente simplemente accediendo a la Tabla de asignación de datos .

Obviamente, se debe tener cuidado para garantizar que los metadatos en línea originales sean un reflejo verdadero de los datos de la tabla de asignación de datos. Ahí es donde entra en juego una Cola de actualización de tabla transaccional. Cada cambio, adición o eliminación de metadatos no se realiza en los datos en sí, sino en la cola. la cola se asegurará de que se realicen todos los cambios en los datos en línea y en la tabla, o que no se realice ningún cambio. También permite realizar actualizaciones asincrónicas, por ejemplo, todos los metadatos de un determinado usuario se pueden eliminar ejecutando un comando de eliminación en la cola. Si los metadatos en línea estaban bloqueados y en uso, la cola no realizaría ningún cambio hasta que pudiera hacerlo tanto en los datos de la tabla como en los datos en línea.

Este es un tipo típico de pregunta de ingeniería en el sentido de que todas sus opciones tienen diferentes compensaciones, y cuál es la mejor depende de lo que sea importante para usted. Desafortunadamente, no ha brindado suficiente información para tomar la determinación.

Tampoco parece haber considerado un problema semántico importante. Digamos que el texto original es

Mi amigo Bob me prestó cinco dólares.

Alguien agrega un comentario sobre "Bob" diciendo

Bob es un completo idiota.

Luego, el texto original se edita en

Jane le prestó a Bob cinco dólares que luego me prestó

Usted puede tener un cierto sentido de este caso particular, el uso de un algoritmo de coincidencia de texto como lo que se utiliza para mostrar un archivo diff, pero las compensaciones de carácter van a hacer que los metadatos se adhieren a la "Jan" en "Jane".

Peor es si el texto se edita en

Mi amigo Steve me prestó cinco dólares.

Podrías averiguar cómo adjuntar los metadatos a "Steve", pero ¿cómo sabes si corresponde?

Además, ¿ha decidido si los metadatos en sí mismos pueden tener metadatos? Eso podría cambiar su implementación.

Más allá de los problemas semánticos, no está muy claro lo que está haciendo con los datos. Pensé que tal vez era muy inconveniente tener el texto original "contaminado" con cualquier marcado, pero estaba de acuerdo con tener valores de ID en él. Lo que no tiene mucho sentido si los metadatos se aplican a una sección de texto en lugar de insertarse en un punto del texto.

Supongo que, para la mayoría de los propósitos, almacenar texto marcado es más fácil o, como segunda opción, pasar todo SQL y tener el texto y el marcado representados por una jerarquía de nodos, básicamente un DOM en forma de tabla. Si sus datos son jerárquicos, puede ser más fácil usar XML y obtener analizadores existentes de forma gratuita, en lugar de escribir el suyo propio.

Es bastante posible que haya una solución bastante simple que sea lo suficientemente buena para su situación exacta, pero no puedo decirle qué es eso porque realmente depende de lo que está tratando de hacer, en detalle.

Te sugiero encapsular cualquier estrategia que elijas tanto como puedas, aunque esto es bastante difícil de hacer si gran parte de tu implementación necesita ser visible para muchas consultas SQL.

Lamento que la respuesta esté tan dispersa y tan llena de "depende", pero las preguntas de diseño del mundo real son así.

Creo que la sugerencia del contestador anterior, la que menciona en su pregunta) es muy buena.

Se comportaría de la misma manera que publicamos enlaces en los sitios de StackExchange, pero los datos de información estarían en otra tabla. Los beneficios son que tiene los datos separados y, por lo tanto, consultables e indexables. Al editar el texto, puede verificar si hay ID de metadatos eliminados y limpiar la tabla de metadatos.

El único pequeño problema como usted dijo es el análisis, pero puede solucionarlo con bastante facilidad.

Digamos que tengo un texto:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

Añado la nota así:

Lorem ipsum dolor sit amet, consectetuer adipiscing elit, sed diam [@ 123, # 456,2w] nonummy nibh euismod tincidunt ut laoreet dolore magna aliquam erat volutpat.

[@123,#456,2w]significa: user_id = 123, note_id = 456, y el texto marcado por esta nota abarca las siguientes 2 palabras (podrían ser caracteres ( c), oraciones ( s), paragraps ( p) o lo que sea). La sintaxis exacta puede ser diferente, por supuesto.

En los editores de texto plano, el texto de las notas se puede almacenar fácilmente al final del documento, al igual que con las notas al pie de Markdown.

En los editores de texto enriquecido, este tipo de nota se puede mostrar en el texto como un icono, y el texto marcado se puede resaltar de alguna manera. El usuario puede eliminar esas notas como caracteres normales con Delo Backspace, y editarlas con algún tipo de modo de edición especial. Me imagino cambiar el tamaño de las áreas señaladas con un mouse y editar el texto de la nota con una ventana emergente.

Pros:

• Va bien con las "intersecciones" ya que marca un desplazamiento (implícitamente por la posición de la nota en el texto) y una longitud para cada nota.
• Admite entorno multiusuario. (De hecho, esto necesita una investigación más profunda y probablemente tenga que lidiar con algo como las transformaciones operativas de Google Wave , que mi cerebro no puede manejar).
• Se puede editar con editores de texto enriquecido y sin formato.
• Puede manejar fácilmente las revisiones, ya que todos los marcadores están en su lugar: cuando edita el texto antes de un marcador, el marcador simplemente cambia junto con otro texto.
• Fácil de analizar.
• No necesita una base de datos externa, pero aún puede usar una si lo desea.
• Se puede mezclar con Markdown o XML si elige una sintaxis discreta.

Contras para la edición de texto sin formato:

• No puede ver áreas en el texto marcadas con notas (a menos que resalte el texto sin formato, que también es una opción), sino solo los lugares donde comienzan las notas. Esto se compensa con la capacidad de elegir unidades de longitud arbitrarias: caracteres, palabras, oraciones, párrafos.
• Puede editar el texto debajo de una nota sin darse cuenta, especialmente si una nota abarca bastante tiempo (por ejemplo, más de 2 párrafos). Puede compensarse mediante un mecanismo de control de revisión que compara un texto debajo de cada nota con su versión anterior y notifica a un usuario si se modificó.

Contras generales:

• Problemas con varios usuarios editando el mismo texto, pero creo que es inevitable de todos modos. No soy un experto en este campo.