Sto sviluppando un'applicazione che dovrà archiviare metadati in - line e in- text . Quello che intendo con questo è il seguente: diciamo che abbiamo un lungo testo e vogliamo memorizzare alcuni metadati collegati a una parola specifica o frase del testo.

Quale sarebbe il modo migliore per conservare queste informazioni?

Il mio primo pensiero è stato quello di includere nel testo una sorta di Markdownsintassi che sarebbe poi analizzata al momento del recupero. Qualcosa simile a questo:

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.

Ciò introdurrebbe due problemi a cui posso pensare:

1. Uno relativamente piccolo, è che se detta sintassi si trova casualmente sul detto testo, può fare confusione con l'analisi.
2. Il più importante è che questo non mantiene questi metadati separati dal testo stesso.

Vorrei avere una struttura di dati discreta per contenere questi dati, una tabella DB così diversa in cui sono archiviate queste metadate, in modo da poterle utilizzare in modi discreti: query, statistiche, ordinamento e così via.

EDIT: Dal momento che il risponditore ha eliminato la sua risposta, penso che potrebbe essere utile aggiungere il suo suggerimento qui, poiché è stato un suggerimento praticabile che si è esteso su questo primo concetto. Il poster ha suggerito di utilizzare una sintassi simile, ma di collegare i metadati alla tabella PRIMARY KEYdel metadatadatabase.

Qualcosa che assomiglierebbe a questo:

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

Dove 15432si trova la IDriga di una tabella contenente le informazioni necessarie e interrogabili, come nell'esempio seguente.

Il mio secondo pensiero è stato quello di memorizzare informazioni di questo tipo in una tabella DB simile a questa:

TABLE: metadata

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

In questo modo i metadati avrebbero un ID univoco, a text_idcome una chiave esterna collegata alla tabella che memorizza i testi e collegherebbe i dati con il testo stesso usando un semplice intervallo di offset dei caratteri .

Questo farebbe il trucco di mantenere i dati separati dai metadati , ma un problema che posso immediatamente vedere con questo approccio è che il testo non sarebbe sostanzialmente modificabile . Oppure, se volessi implementare la modifica del testo dopo l'assegnazione dei metadati, dovrei sostanzialmente calcolare le aggiunte o la rimozione dei caratteri rispetto alla versione precedente e verificare se ciascuna di queste modifiche aggiunge o rimuove i caratteri prima o dopo ogni dei metadati associati.

Il che, per me, sembra un approccio davvero poco elegante.

Hai qualche suggerimento o suggerimento su come potrei affrontare il problema?

Modifica 2: alcuni problemi XML

Aggiungendo un altro caso che renderebbe del tutto necessario per far avvenire questa separazione di dati e metadati.

• Diciamo che voglio rendere possibile a diversi utenti di avere diversi set di metadati dello stesso testo , con o senza la possibilità che ciascun utente visualizzi effettivamente i metadati degli altri utenti.

Qualsiasi soluzione del tipo markdown (o HTML o XML) sarebbe difficile da implementare a questo punto. L'unica soluzione in questo caso a cui potrei pensare sarebbe quella di avere ancora un'altra tabella DB che conterrebbe la versione per singolo utente del testo originale, collegandosi alla tabella di testo originale mediante l'uso di a FOREIGN KEY.

Non sono sicuro che sia molto elegante.

• XML ha un modello di dati gerarchico: qualsiasi elemento che si trova all'interno dei confini di un altro elemento è considerato come suo figlio , il che spesso non è il caso del modello di dati che sto cercando; in XML qualsiasi elemento figlio deve essere chiuso prima che il tag padre possa essere chiuso, evitando sovrapposizioni di elementi.

Esempio:

<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>

Qui abbiamo due diversi problemi:

1. Diversi elementi sovrapposti: il primo commento inizia all'interno della prima nota, ma termina dopo la fine della prima nota, ovvero non è suo figlio.

2. Stessi elementi sovrapposti: l'ultima nota e la nota in grassetto si sovrappongono; tuttavia, poiché sono lo stesso tipo di elemento, il parser chiuderebbe l'ultimo elemento aperto alla prima chiusura, e il primo elemento aperto all'ultima chiusura, che, in questa circostanza, non è quello che si intende.

Vorrei un mix delle tue soluzioni, ma invece, userei uno standard: XML. Avresti una sintassi come questa

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.

Perché XML

Se ci pensate, è esattamente come è strutturata l'intera rete : contenuto (testo reale) che trasporta semantici - ciò che chiamate metadati - attraverso tag html.

In questo modo hai un mondo davvero fantastico che si apre:

• Parser gratuito
• Modo testato in battaglia per aggiungere metadati ai contenuti
• Facilità d'uso (a seconda degli utenti targetizzati)
• È possibile estrarre facilmente il testo non elaborato, senza i metadati, poiché è una funzionalità standard sui parser XML. Questo è molto utile per avere una versione indicizzabile dei tuoi contenuti, quindi Lorem <note>ipsum</note>viene sollevato durante la ricerca, lorem ips*ad esempio.

Perché XML su Markdown

Un sito web come stackexchange utilizza il markdown in quanto la semantica trasmessa dal suo contenuto è piuttosto semplice: enfasi, collegamenti / URL, immagine, intestazione ecc. Sembra che la semantica che stai aggiungendo al tuo contenuto sia

1. Più complesso
2. Soggetto a modifiche o deve essere estensibile

Quindi sento Markdown non sarebbe una buona idea. Inoltre Markdown non è davvero standardizzato, e analizzare / scaricare potrebbe essere un dolore nel culo, ancora più una sintassi markdownish vedi il post di Jeff Atwood sul WTF che ha incontrato durante l'analisi di Markdown .

Sulla separazione tra dati e metadati

Di per sé, tale separazione non è obbligatoria. Presumo che tu stia cercando il vantaggio che comporta:

• Possibilità di avere il contenuto non elaborato senza i metadati
• Separazione delle preoccupazioni: non voglio avere effetti collaterali / complessità durante la manipolazione dei metadati a causa dei dati e in altro modo.

Tutte queste preoccupazioni vengono eliminate dall'uso di XML. Dall'XML, è possibile scaricare facilmente qualsiasi contenuto privo di tag e dati / metadati sono separati, proprio come l'attributo e il testo effettivo sono separati in XML.

Inoltre, non penso che tu possa davvero avere i tuoi metadati totalmente non legati ai tuoi dati . Da quello che descrivi, i tuoi metadati sono una composizione dei tuoi dati, cioè l'eliminazione dei dati porta alla cancellazione dei metadati. È qui che i tuoi metadati divergono dal solito HTML / CSS. Il CSS non scompare quando viene rimosso un elemento html, perché può essere applicato ad altri elementi. Non penso che questo sia il caso nei tuoi metadati.

Avere metadati vicini ai dati, come in XML o Markdown, consente una facile comprensione (e forse il debug) dei dati. Inoltre, l'esempio che fai sul tuo secondo pensiero aggiunge una certa complessità, perché per ogni dato che sto leggendo, ho bisogno di interrogare la tabella dei metadati per ottenerli. Se la relazione tra i tuoi dati e i tuoi metadati è 1: 1 o 1: N, allora l'IMO è chiaramente inutile e porta solo complessità (un buon caso di YAGNI).

Il caso d'uso della soluzione

Non sono d'accordo con alcune delle altre risposte, semplicemente perché, benché ottime soluzioni, probabilmente non sono la tua soluzione. Sì, XML ha la parola markup nel suo acronimo, ma probabilmente non è l'ideale per la tua situazione. È troppo complesso, offre poca assistenza nel mantenere i metadati separati dal testo originale. Fondamentalmente trasformerà tutto in una forma di metadati, creando un set di dati in sovrappeso.

Poiché probabilmente non esiste una soluzione o un approccio assolutamente corretti, la soluzione migliore risponde alla domanda:

Come verranno utilizzati i dati dal sistema?

Inoltre, se provi a chiedere, come un progetto di soluzione potrebbe intrinsecamente aggiungere al valore del sistema, nel modo in cui verrà utilizzato, allora sei più vicino a trovare la tua risposta elegante .

Comprensione del problema

Ok abbastanza commento, scaviamo nel problema. Questo è il problema per come lo capisco (ovviamente aggiungere a questo sarà utile):

• C'è un testo originale
  • Ipotesi su questo testo originale:
  • Questo testo può essere composto o meno da più documenti indipendenti
  • Questo testo, può o meno essere modificato da uno o più utenti
  • Questo testo contiene informazioni correlate . Con ciò presumo (correggimi se sbaglio) che i metadati sono correlati e non descrittivi . Quindi memorizza informazioni relative al testo originale e non informazioni che descrivono il testo. Così sarà memorizzare note sul testo originale, e non con l'esempio descrive che il testo è un titolo che è audace e è un link a un sito web, etc.
  • Il testo deve essere facilmente filtrato distinto dai metadati
  • Il testo dovrebbe essere protetto dall'essere corrotto e corrotto dai metadati
• Dovrebbe esserci un mezzo per memorizzare le informazioni relative al testo originale (metadati)
  • Questi metadati necessitano anche dei propri (metadati) metadati, che potrebbero contenere informazioni quali l'utente (o i gruppi?) Per i quali i metadati sono rilevanti, come una descrizione dei metadati, diciamo che è una nota o un commento, oppure descrizione ecc.
  • Questi metadati (ed i suoi (meta) metadati) devono resistere alle alterazioni del testo originale, alle alterazioni dei metadati e alle alterazioni dei (meta) metadati
  • I metadati (+ Meta-Metadata) devono essere strutturati bene e facilmente interrogati, indicizzati o persino uniti in modo relazionale ad altri set di dati. La natura relazionale dei metadati non dovrebbe essere limitata alle query, ma anche facilitare gli aggiornamenti o riscrivere e alterare i metadati a seguito delle attività relative ai dati relazionali.
  • Il valore dei metadati (+ Meta-Metadata) è nella sua natura molto correlata . Diventa immediatamente controproducente nel momento in cui perde la sua relazione con il testo originale. Pertanto, l' integrità della sua relazione con il testo originale è un imperativo del progetto obbligatorio.
• Altre ipotesi sulla natura del problema e su come verrà utilizzato sono:
  • Accesso al sistema eterogeneo simultaneo. Ciò significa che l'utente potrebbe voler visualizzare il testo e modificare i metadati, contemporaneamente all'amministratore (o ad un altro processo) che sta eseguendo query di dati relazionali sui metadati strutturati.
  • Il sistema avrà diversi utenti
  • Il sistema è moderno Ciò significa che non è vincolato dallo spazio di archiviazione, dalla velocità di elaborazione o dagli imperativi in ​​tempo reale. L'integrità e la funzionalità focalizzata sullo scopo è una priorità più alta rispetto alle limitazioni delle risorse di elaborazione fisica.
  • Esiste la possibilità (sebbene bassa) che gli usi e le funzionalità del sistema possano evolversi o cambiare in qualche modo, man mano che il sistema viene utilizzato.

Costruire il design della soluzione

Comprendendo il problema come ho già indicato sopra, inizierò ora a suggerire possibili soluzioni e approcci che mirano a risolvere il problema di cui sopra.

componenti

Quindi vedrei che ci dovrebbe essere un sistema di accesso utente personalizzato. Filtrerebbe i metadati pertinenti e irrilevanti dal testo originale. Faciliterebbe la modifica e la visualizzazione dei metadati nel testo. Assicurerebbe l'integrità della relazione tra i metadati e il suo testo originale. Strutturerebbe i metadati e offrirebbe un'origine dati a un sistema di dati relazionali. Molto probabilmente fornirà una serie di altre funzioni orientate allo scopo.

Struttura

Pertanto, poiché è importante mantenere l'integrità dei metadati nel testo originale, il modo migliore per garantire ciò è mantenere i metadati in linea con il testo originale. Ciò offrirà il vantaggio che i dati originali possono essere modificati con sicurezza senza compromettere questa integrità.

Le preoccupazioni con questo approccio sono la corruzione dei metadati da parte dei dati originali e viceversa. L'adeguata indicizzazione e strutturazione dei metadati e dei suoi (meta) metadati in un modo che consenta query e aggiornamenti e un accesso efficiente. Il facile filtraggio dei metadati dal testo originale.

Con questo in mente, suggerirei che una parte della soluzione sia basata sull'approccio dell'uso dei PERSONAGGI DI FUGA all'interno del testo originale. Ciò non equivale a progettare il proprio linguaggio di markup o utilizzare un linguaggio di markup esistente come XML o HTML. È facile progettare un PERSONAGGIO DI FUGA che ha una probabilità pari a zero o quasi zero di esistere nel testo originale.

Il mio consiglio in tal senso è quello di considerare attentamente i dati originali e provare a determinare la natura della tabella codici in cui sono memorizzati e quindi cercare un PERSONAGGIO o SEQUENZA DI CARATTERI idealeche è improbabile o impossibile che si verifichi. Ad esempio in ASCII ci sono letteralmente caratteri di controllo integrati con valori di byte che non vengono mai utilizzati nelle interfacce utente standard. Lo stesso si può dire per un sistema informativo basato su font o dati relazionali. Fai solo attenzione con i codec di dati binari. A seconda della natura dei dati originali, può essere utile costruire un parser che confermi la scoperta di una sequenza di controllo, magari guardando i dati che sono fuggiti e verificandone l'integrità, sia con una semplice ispezione della struttura dei fuggiti dati, o anche includendo un carattere di controllo che viene calcolato per ciascuna sequenza di dati di escape.

Dati di esempio con sequenze di escape

Questa è la storia di un uomo. >>>> (#) Perché questa storia di un uomo non è una donna? (#) ( ) Userid :: 77367 ( ) Commento del manager ( ) DataID :: 234234234 >>>> Un uomo che è andato a falciare un prato, è andato a falciare un prato. L'uomo è andato con il suo cane >>>> (#) Chiedi al cliente se la storia sarebbe migliore con un gatto (#) >>>> per falciare il prato. Quindi ora questa è la storia di un uomo e del suo cane che sono andati a falciare un prato.

Un uomo e il suo cane andarono a falciare un prato, andarono a falciare un prato, un prato allungato sopra la montagna. >>>> (#) Questo suona molto meglio con una foresta (**) Suggerimento (#) >>>>

L'uomo e il suo cane e la sua missione, falciare un prato, raggiungono un prato sopra la montagna solo attraversando il fiume.

Dati di esempio senza sequenze di escape

Questa è la storia di un uomo. Un uomo che andava a falciare un prato, andava a falciare un prato. L'uomo andò con il suo cane a falciare il prato. Quindi ora questa è la storia di un uomo e del suo cane che sono andati a falciare un prato.

Un uomo e il suo cane andarono a falciare un prato, andarono a falciare un prato, un prato allungato sopra la montagna.

L'uomo e il suo cane e la sua missione, falciare un prato, raggiungono un prato sopra la montagna solo attraversando il fiume.

Ovviamente questo è facilmente analizzabile, non complesso come un intero linguaggio Mark-up e facilmente adattabile al tuo scopo.

Risolto ancora? Bene, direi di no. La nostra soluzione ha ancora alcuni buchi. L'indicizzazione e l'accesso strutturato di questi dati sono scarsi. Inoltre, non sarebbe ragionevole interrogare questo file (o più file) contemporaneamente a modificarlo.

Come possiamo risolvere questo problema?

Vorrei suggerire una TABELLA DI ASSEGNAZIONE DEI DATI come intestazione del documento. Suggerirei anche di implementare una CODICE DI AGGIORNAMENTO DELLA TABELLA TRANSAZIONALE . Lasciatemi spiegare. I progettisti di un file system, in particolare di un file system a disco rotazionale, hanno affrontato sfide di progettazione simili a quelle sopra descritte. Avevano bisogno di incorporare informazioni sui file sul disco insieme ai dati. Un'ottima soluzione per l'integrità della relazione di questi dati, era DUPLICARLO in una tabella di allocazione dei file (FAT).

Ciò significa che per ogni singolo elemento di metadati è presente una voce corrispondente nella tabella di allocazione dei dati . Quindi è veloce, strutturato e relazionale e indipendente dai dati originali. Se è necessario eseguire query, join o aggiornamenti sui metadati, è possibile farlo semplicemente accedendo alla tabella di allocazione dei dati .

Ovviamente occorre prestare attenzione per garantire che i metadati in-line originali riflettano fedelmente i dati della tabella di allocazione dei dati. È qui che entra in gioco una coda di aggiornamento delle tabelle transazionali. Ogni modifica, aggiunta o rimozione di metadati non viene effettuata sui dati stessi, ma piuttosto sulla coda. la coda assicurerà quindi che tutte le modifiche vengano apportate sia ai dati in linea che a quelli della tabella, oppure che non vengano apportate modifiche. Consente inoltre l'esecuzione di aggiornamenti asincroni, ad esempio tutti i metadati di un determinato utente possono essere eliminati eseguendo un comando di eliminazione sulla coda. Se i metadati inline fossero bloccati e in uso, la coda non eseguirà alcuna modifica fino a quando non sarà in grado di farlo sia ai dati della tabella che ai dati inline.

Questo è un tipico tipo di domanda di ingegneria in quanto tutte le opzioni hanno diversi compromessi e la cosa migliore dipende da ciò che è importante per te. Sfortunatamente, non hai fornito informazioni sufficienti per decidere.

Inoltre non sembra che tu abbia considerato un importante problema semantico. Diciamo che il testo originale è

Il mio amico Bob mi ha prestato cinque dollari

Qualcuno aggiunge un commento su "Bob" dicendo

Bob è un completo idiota

Quindi il testo originale viene modificato in

Jane ha prestato a Bob cinque dollari che poi mi ha prestato

Si potrebbe dare un senso a questo caso particolare utilizzando un algoritmo di matching di testo come quello che viene utilizzato per mostrare un file diff, ma compensazioni di carattere stanno andando a fare i metadati attribuiscono alla "Jan" in "Jane".

Peggio ancora è se il testo è modificato in

Il mio amico Steve mi ha prestato cinque dollari

Potresti riuscire a capire come allegare i metadati a "Steve", ma come fai a sapere se si applica?

Inoltre, hai deciso se i metadati stessi possono avere metadati? Ciò potrebbe cambiare la tua implementazione.

Al di là delle questioni semantiche, non è molto chiaro cosa stai facendo con i dati. Ho pensato che forse era molto scomodo avere il testo originale "inquinato" con qualsiasi markup, ma poi eri un po 'OK con valori ID in esso contenuti. Il che non ha molto senso se i metadati si applicano a una sezione di testo invece di essere inseriti in un punto nel testo.

La mia ipotesi è che per la maggior parte degli scopi l'archiviazione del testo con markup sia più semplice o, di seconda scelta, eseguire tutto l'SQL e avere il testo e il markup rappresentati da una gerarchia di nodi, sostanzialmente un DOM in forma di tabella. Se i tuoi dati sono gerarchici di quanto potrebbe essere più semplice usare XML e ottenere parser esistenti gratuitamente, invece di scriverne uno tuo.

È del tutto possibile che ci sia una soluzione abbastanza semplice che sia abbastanza buona per la tua situazione esatta, ma non posso dirti di cosa si tratta perché dipende in realtà da ciò che stai cercando di fare, in dettaglio.

Consiglio vivamente di incapsulare qualsiasi strategia scegliate il più possibile, anche se questo è abbastanza difficile da fare se gran parte della vostra implementazione deve essere visibile a molte query SQL.

Mi dispiace che la risposta sia così diffusa e così piena di "dipende", ma le domande sul design del mondo reale sono così.

Penso che il suggerimento del precedente risponditore, quello che menzioni sulla tua domanda) sia molto valido.

Si comporterebbe nello stesso modo in cui pubblichiamo collegamenti sui siti StackExchange, ma i dati delle informazioni sarebbero su un'altra tabella. I vantaggi sono che i dati sono separati e quindi interrogabili e indicizzabili. Al momento di modificare il testo, è possibile controllare gli ID dei metadati eliminati e pulire la tabella dei metadati.

L'unico piccolo problema come hai detto è l'analisi, ma puoi affrontarlo abbastanza facilmente.

Diciamo che ho un messaggio:

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

Aggiungo la nota in questo modo:

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 e il testo contrassegnato da questa nota si estende per le successive 2 parole (potrebbero essere caratteri (c ), frasi ( s), paragrafi ( p) o altro). La sintassi esatta può essere diversa, ovviamente.

Negli editor di testo semplice, il testo delle note può essere facilmente memorizzato alla fine del documento, proprio come con le note a piè di pagina di Markdown.

Negli editor Rich Text questo tipo di nota può essere visualizzata nel testo come icona e il testo contrassegnato può essere evidenziato in qualche modo. L'utente può quindi eliminare tali note proprio come i normali caratteri conDel oBackspace e modificarle con una sorta di modalità di modifica speciale. Immagino di ridimensionare le aree annotate con il mouse e di modificare il testo della nota con una finestra popup.

Professionisti:

• Va bene con "intersezioni" poiché si contrassegna un offset (implicitamente dalla posizione della nota nel testo) e una lunghezza per ogni nota.
• Supporta l'ambiente multiutente. (In realtà, questo richiede una ricerca più approfondita e probabilmente dovresti affrontare qualcosa come le trasformazioni operative di Google Wave , che il mio cervello non può gestire.)
• Può essere modificato sia con editor di testo semplice che rich.
• Puoi facilmente gestire le revisioni, dal momento che tutti i marcatori sono sul posto: quando modifichi il testo prima di un marcatore, il marcatore si sposta semplicemente insieme ad altro testo.
• Facile da analizzare.
• Non è necessario un DB esterno, ma è comunque possibile utilizzarne uno se lo si desidera.
• Può essere miscelato con Markdown o XML se si sceglie una sintassi discreta.

Contro per la modifica del testo normale:

• Non è possibile visualizzare le aree nel testo contrassegnate con le note (a meno che non si evidenzi il testo in chiaro, che è anche un'opzione), ma solo i punti in cui iniziano le note. Ciò è compensato dalla possibilità di scegliere unità di lunghezza arbitrarie: caratteri, parole, frasi, paragrafi.
• Puoi modificare il testo sotto una nota senza accorgertene, specialmente se una nota si estende abbastanza a lungo (ad es. 2+ paragrafi). Può essere compensato dal meccanismo di controllo del revison che confronta un testo sotto ogni nota con la sua versione precedente e avvisando un utente se è stato modificato.

Contro generici:

• Problemi con più utenti che modificano lo stesso testo, ma penso che non sia comunque evitabile. Non sono un esperto in questo campo.