Menyimpan metadata dalam teks dalam struktur data diskrit


14

Saya mengembangkan aplikasi yang perlu menyimpan metadata inline , intext . Yang saya maksud dengan itu adalah sebagai berikut: katakanlah kita memiliki teks yang panjang, dan kami ingin menyimpan beberapa metadata yang terhubung dengan kata tertentu, atau kalimat dari teks tersebut.

Apa cara terbaik untuk menyimpan informasi ini?

Pikiran pertama saya adalah memasukkan dalam teks semacam Markdownsintaks yang kemudian akan diuraikan saat mengambil. Sesuatu yang terlihat seperti ini:

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.

Ini akan memperkenalkan dua masalah yang dapat saya pikirkan:

  1. Yang relatif kecil, adalah bahwa jika sintaks tersebut kebetulan kebetulan pada teks tersebut, itu dapat mengacaukan parsing.
  2. Yang paling penting adalah ini tidak mempertahankan metadata ini terpisah dari teks itu sendiri.

Saya ingin memiliki struktur data diskrit untuk menyimpan data ini, seperti Tabel DB yang berbeda di mana metadata ini disimpan, sehingga saya bisa menggunakannya dalam cara-cara yang berbeda: query, statistik, pengurutan, dan sebagainya.


EDIT: Karena penjawabnya menghapus jawabannya, saya pikir mungkin baik untuk menambahkan sarannya di sini, karena itu adalah saran yang bisa diterapkan yang diperluas pada konsep pertama ini. Poster menyarankan untuk menggunakan sintaks mirip, tapi untuk menghubungkan metadata ke PRIMARY KEYdari metadatatabel database.

Sesuatu yang akan terlihat seperti ini:

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

Di mana 15432akan ada IDbaris tabel yang berisi informasi yang diperlukan dan cukup, seperti contoh di bawah ini.


Pikiran kedua saya adalah untuk menyimpan informasi seperti ini di Tabel DB terlihat seperti ini:

TABLE: metadata

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

Dengan cara ini metadata akan memiliki id unik, a text_idsebagai kunci asing yang terhubung ke tabel yang menyimpan teks dan itu akan menghubungkan data dengan teks itu sendiri dengan menggunakan rentang offset karakter sederhana .

Ini akan melakukan trik untuk menjaga data terpisah dari metadata , tetapi masalah yang dapat saya segera lihat dengan pendekatan ini adalah bahwa teks pada dasarnya tidak dapat diedit . Atau, jika saya ingin mengimplementasikan pengeditan teks setelah penugasan metadata, pada dasarnya saya harus menghitung penambahan karakter, atau menghapus dibandingkan dengan versi sebelumnya, dan memeriksa apakah masing - masing modifikasi ini menambah atau menghapus karakter sebelum atau setelah masing-masing metadata terkait.

Bagi saya, ini kedengarannya seperti pendekatan yang benar-benar tidak penting.

Apakah Anda memiliki petunjuk atau saran tentang bagaimana saya dapat mendekati masalah?


Sunting 2: beberapa masalah XML

Menambahkan kasus lain yang akan membuat cukup penting untuk pemisahan data dan metadata ini terjadi.

  • Katakanlah saya ingin memungkinkan pengguna yang berbeda memiliki set metadata berbeda dari teks yang sama , dengan atau tanpa kemungkinan masing-masing pengguna benar-benar menampilkan metadata pengguna lain.

Solusi apa pun dari jenis penurunan harga (atau HTML, atau XML) akan sulit diterapkan pada titik ini. Satu-satunya solusi dalam hal ini yang dapat saya pikirkan adalah dengan memiliki DB Table lain yang akan memuat versi pengguna tunggal dari teks asli, yang terhubung ke tabel teks asli dengan menggunakan a FOREIGN KEY.

Tidak yakin apakah ini sangat elegan.

  • XML memiliki model data hierarkis: elemen apa pun yang berada di dalam batas elemen lain dianggap sebagai anaknya , yang paling sering tidak terjadi dalam model data yang saya cari; dalam XML setiap elemen anak - anak harus ditutup sebelum tag induk dapat ditutup, sehingga tidak ada elemen yang tumpang tindih.

Contoh:

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

Di sini kita memiliki dua masalah berbeda:

  1. Elemen yang berbeda tumpang tindih: Komentar pertama dimulai dalam not pertama, tetapi berakhir setelah akhir not pertama, artinya bukan anaknya.

  2. Elemen yang sama tumpang tindih: Nada terakhir dan huruf tebal bertumpang tindih; Namun, karena mereka adalah jenis elemen yang sama, parser akan menutup elemen yang terakhir dibuka pada penutupan pertama, dan elemen terbuka pertama pada penutupan terakhir, yang, dalam keadaan ini, bukan apa yang dimaksudkan.


3
Kedengarannya sedikit seperti Anda sedang menulis bahasa markup Anda sendiri. Anda dapat menggunakan HTML yang memiliki sistem parsing yang mapan dan Anda dapat mengedit teks Anda dengan memanipulasi pohon parsing yang dihasilkan. Untuk penyimpanan basis data, Anda dapat menggunakan db NoSQL, seperti Oracle XMLDB atau Mark / Logic.
ipaul

Masalahnya tidak begitu praktis, seperti konseptual. Maksud saya, saya bisa menggunakan HTML, atau Markdown, atau membangun bahasa markup yang sangat sederhana bersama dengan parser. Masalahnya adalah saya ingin memisahkan mereka. Pertahankan konten minimal, mungkin hanya menyimpan informasi teks kaya dasar di dalam konten, tetapi segala sesuatu yang lain harus terpisah.
Sunyatasattva

1
@Sunyatasattva apa manfaat dari menambahkan kompleksitas seperti itu?
Clement Herreman

@ClementHerreman Yang menambah kompleksitas? Maksud Anda kompleksitas tambahan menjaga data dan metadata terpisah?
Sunyatasattva

Apakah teks dimaksudkan sebagai dokumen hidup, yang dapat diubah atau diperbarui, dan metadata mana yang perlu dipertahankan lebih dari beberapa versi teks? Atau apakah teks yang diterapkan metadata itu murni statis dan tidak berubah?
Kyle Lowry

Jawaban:


5

Saya akan menggunakan campuran solusi Anda, tetapi saya akan menggunakan standar: XML. Anda akan memiliki sintaks seperti ini

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.

Mengapa XML

Jika Anda memikirkannya, ini adalah bagaimana keseluruhan web terstruktur : konten (teks aktual) yang membawa semantik - apa yang Anda panggil metadata - melalui tag html.

Dengan cara ini Anda memiliki dunia yang sangat keren yang membuka:

  • Parser gratis
  • Pertempuran diuji cara untuk menambahkan metadata ke konten
  • Kemudahan penggunaan (tergantung pada pengguna yang Anda targetkan)
  • Anda dapat dengan mudah mengekstrak teks mentah, tanpa metadata, karena ini adalah fitur standar pada parser XML. Itu sangat berguna untuk memiliki versi konten Anda yang dapat diindeks, jadi Lorem <note>ipsum</note>dimunculkan ketika Anda mencari lorem ips*misalnya.

Mengapa XML melebihi Markdown

Situs web seperti stackexchange menggunakan penurunan harga karena semantik yang disampaikan kontennya agak mendasar: penekanan, tautan / url, gambar, tajuk, dll. Tampaknya semantik yang Anda tambahkan ke konten adalah

  1. Lebih kompleks
  2. Dapat berubah atau harus diperpanjang

Jadi saya rasa penurunan harga bukan ide yang bagus. Juga penurunan harga tidak benar-benar standar, dan parsing / dumping itu mungkin menyebalkan, bahkan lebih sintaks penurunan harga lihat posting Jeff Atwood tentang WTF yang dia temui di parsing Markdown .

Pada pemisahan antara data dan metadata

Per se, pemisahan seperti itu tidak wajib. Saya menganggap Anda mencari keuntungan yang dibawanya:

  • Kemungkinan untuk memiliki konten mentah tanpa metadata
  • Pemisahan masalah: Saya tidak ingin memiliki efek samping / kerumitan overhead saat memanipulasi metadata karena data, dan sebaliknya.

Semua masalah ini dihapus oleh penggunaan XML. Dari XML, Anda dapat dengan mudah membuang konten yang dilucuti tag, dan data / metadata dipisahkan, sama seperti atribut dan teks aktual dipisahkan dalam XML.

Juga saya tidak berpikir Anda benar-benar dapat memiliki metadata Anda sama sekali tidak terikat pada data Anda . Dari apa yang Anda jelaskan, metadata Anda adalah komposisi data Anda, yaitu menghapus data mengarah ke penghapusan metadata. Di sinilah Anda metadata berbeda dari HTML / CSS biasa. CSS tidak menghilang ketika elemen html dihapus, karena itu dapat diterapkan ke elemen lain. Saya tidak merasa ini adalah kasus dalam metadata Anda.

Memiliki metadata yang dekat dengan data, seperti dalam XML atau Markdown, memungkinkan pemahaman yang mudah (dan mungkin debugging) dari data. Juga, contoh yang Anda berikan pada pemikiran kedua Anda menambah kompleksitas, karena untuk setiap data yang saya baca, saya perlu meminta tabel metadata untuk mendapatkan ini. Jika hubungan antara data Anda dan metadata Anda adalah 1: 1 atau 1: N, maka itu IMO jelas tidak berguna, dan hanya membawa kompleksitas (kasus yang baik dari YAGNI).


Keuntungan lain yang saya cari adalah dapat menggunakan metadata secara mandiri , ini berarti hanya meminta metadata, tanpa peduli dengan kontennya. Mengapa data hubungan: metadata 1: n “jelas tidak berguna” menurut pendapat Anda?
Sunyatasattva

Mari kita tambahkan kasus lain yang menggunakan metadata apa pun di dalam solusi data tidak berguna: Saya ingin memungkinkan satu teks memiliki metadata dari pengguna yang berbeda, yang mungkin (atau mungkin tidak), dapat melihat metadata pengguna lain .
Sunyatasattva

Saya sedikit menguraikan hal ini dalam edit baru saya.
Sunyatasattva

+1 Inilah yang dirancang untuk SGML dan XML.
Ross Patterson

Saya pikir masalahnya adalah, sejauh yang saya tahu, dalam XML elemen apa pun yang kebetulan berada di dalam elemen lain dianggap sebagai anak elemen, dan tumpang tindih tag tidak dimungkinkan (yaitu, Anda harus menutup anak-anak sebelum menutup induknya. ). Dalam kasus saya, tidak ada struktur hierarkis seperti itu, karena dua catatan tentu saja bisa tumpang tindih (contoh ditambahkan pada akhir jawaban saya).
Sunyatasattva

3

Solusinya Gunakan Kasing

Saya tidak setuju dengan beberapa jawaban lain, hanya karena, sementara solusi hebat, mereka mungkin bukan solusi Anda . Ya XML memiliki markup kata dalam akronim itu, tetapi mungkin tidak ideal untuk situasi Anda. Itu terlalu rumit, ia menawarkan sedikit bantuan dalam menjaga meta data terpisah dari teks asli. Pada dasarnya itu akan mengubah segalanya menjadi bentuk metadata, membuat satu set data yang kelebihan berat badan.

Karena kemungkinan tidak ada solusi atau pendekatan yang sepenuhnya benar, solusi terbaik menjawab pertanyaan:

Bagaimana data akan digunakan oleh sistem?

Juga, jika Anda mencoba dan bertanya, bagaimana desain solusi dapat secara inheren menambah nilai sistem, dengan cara yang akan digunakan, maka Anda lebih dekat untuk menemukan jawaban elegan Anda .

Memahami masalahnya

Ok komentar yang cukup, mari kita gali masalahnya. Ini adalah masalah yang saya pahami (jelas menambahkan ini akan bermanfaat):

  • Ada teks asli
    • Asumsi tentang teks asli ini:
    • Teks ini, mungkin atau mungkin tidak terdiri dari beberapa dokumen independen
    • Teks ini, mungkin atau tidak dapat diedit oleh satu atau lebih pengguna
    • Teks ini, berisi informasi terkait . Dengan itu saya berasumsi (koreksi saya jika saya salah) bahwa metadata terkait dan tidak deskriptif . Jadi ia menyimpan informasi yang terkait dengan teks asli, dan bukan informasi yang menggambarkan teks. Sehingga akan menyimpan catatan tentang teks asli, dan tidak dengan contoh menjelaskan bahwa teks adalah judul yang adalah berani dan merupakan link ke website, dll
    • Teks harus dengan mudah disaring berbeda dari metadata
    • Teks harus dilindungi dari rusak oleh, dan merusak metadata
  • Seharusnya ada cara untuk menyimpan informasi yang terkait dengan teks asli (metadata)
    • Metadata ini juga membutuhkan metadata sendiri (meta), yang akan menyimpan informasi seperti pengguna (atau grup?) Yang mana data meta relevan untuk, seperti deskripsi metadata, katakan cuaca itu adalah catatan, atau komentar, atau deskripsi dll.
    • Metadata ini (dan metadata itu) perlu menahan perubahan dalam teks asli, perubahan metadata dan perubahan data meta (meta)
    • Metadata (+ Meta-Metadata) perlu terstruktur dengan baik dan mudah ditanyakan, dan diindeks atau bahkan digabungkan dengan cara relasional ke kumpulan data lain. Sifat relasional metadata tidak hanya terbatas pada Queries, tetapi juga memfasilitasi pembaruan atau menulis kembali dan perubahan metadata sebagai hasil dari aktivitas data relasional.
    • Nilai metadata (+ Meta-Metadata) dalam sifatnya sangat terkait . Itu menjadi langsung kontra produktif saat kehilangan hubungannya dengan teks asli. Jadi integritas hubungannya dengan teks asli adalah keharusan desain wajib.
  • Asumsi lain tentang sifat masalah dan bagaimana itu akan digunakan adalah:
    • Akses sistem heterogen serentak. Dengan kata lain, pengguna mungkin ingin melihat teks dan mengedit metadata, pada saat yang sama dengan administrator (atau proses lain) melakukan kueri data relasional pada metadata terstruktur.
    • Sistem akan memiliki beberapa pengguna
    • Sistemnya modern. Artinya, itu tidak dibatasi oleh ruang penyimpanan, atau kecepatan pemrosesan, atau keharusan waktu nyata. Integritas dan fungsionalitas yang berfokus pada tujuan adalah prioritas yang lebih tinggi daripada keterbatasan sumber daya komputasi fisik.
    • Ada kemungkinan (walaupun rendah) bahwa penggunaan dan fungsionalitas sistem dapat berevolusi atau berubah, karena sistem digunakan.

Membangun desain solusi

Memahami masalah seperti yang telah saya uraikan di atas, saya sekarang akan mulai menyarankan solusi dan pendekatan yang mungkin yang bertujuan untuk memecahkan masalah di atas.

Komponen

Jadi saya akan melihat bahwa perlu ada sistem akses pengguna yang dibuat khusus. Itu akan menyaring metadata yang relevan dan tidak relevan dari teks asli. Ini akan memudahkan pengeditan dan tampilan metadata ke dalam teks. Itu akan memastikan integritas hubungan antara metadata dan teks aslinya. Ini akan menyusun metadata dan menawarkan sumber data ke sistem data relasional. Kemungkinan besar akan menyediakan sejumlah fungsi didorong tujuan lain.

Struktur

Jadi karena penting untuk menjaga integritas metadata ke teks asli, cara terbaik untuk memastikan hal ini, adalah menjaga metadata sejalan dengan teks asli. Ini akan menawarkan manfaat bahwa data asli dapat diedit dengan percaya diri tanpa merusak integritas ini.

Kekhawatiran dengan pendekatan ini adalah korupsi metadata oleh data asli dan sebaliknya. Pengindeksan dan penataan metadata yang memadai dan metadata (meta) sedemikian rupa sehingga memungkinkan untuk permintaan dan pembaruan serta akses yang efisien. Filter yang mudah dari metadata dari teks asli.

Dengan mengingat hal ini, saya akan menyarankan bahwa sebagian dari solusi didasarkan pada pendekatan menggunakan ESCAPE CHARACTERS dalam teks asli. Ini tidak sama dengan mendesain Bahasa Markup Anda sendiri atau menggunakan Bahasa Markup yang ada seperti XML atau HTML. Sangat mudah untuk merancang ESCAPE CHARACTER yang memiliki kemungkinan nol, atau hampir nol dalam teks asli.

Saran saya kepada Anda dalam hal ini adalah untuk dengan hati-hati mempertimbangkan data asli, dan mencoba dan menentukan sifat halaman kode yang menyimpannya dan kemudian mencari KARAKTER yang ideal atau URUTAN KARAKTER yang idealitu tidak mungkin atau tidak mungkin terjadi. Sebagai contoh di ASCII ada karakter kontrol bawaan dengan nilai byte yang tidak pernah digunakan dalam antarmuka pengguna standar. Hal yang sama dapat dikatakan untuk sistem informasi berbasis font atau data relasional. Berhati-hatilah dengan codec data biner. Bergantung pada sifat data asli, mungkin berharga untuk membuat parser yang mengonfirmasi penemuan urutan kontrol, mungkin dengan melihat data yang lolos dan memverifikasi integritasnya, baik dengan inspeksi sederhana terhadap struktur yang lolos. data, atau bahkan dengan memasukkan karakter kontrol yang dihitung untuk setiap urutan data yang lolos.

Contoh Data Dengan Escape Sequences

Ini adalah kisah tentang seorang pria. >>>> (#) Mengapa cerita ini tentang seorang pria bukan seorang wanita? (#) ( ) Userid :: 77367 ( ) Komentar Manajer ( ) DataID :: 234234234 >>>> Seorang pria yang pergi untuk memotong rumput, pergi untuk memotong rumput. Pria itu pergi dengan anjingnya >>>> (#) Tanyakan klien apakah cerita itu akan lebih baik dengan kucing sebagai gantinya (#) >>>> untuk memotong rumput. Jadi sekarang ini adalah kisah tentang seorang pria dan anjingnya yang pergi untuk memotong rumput.

Seorang pria dan anjingnya, pergi untuk memotong rumput, pergi untuk memotong rumput, sebuah padang rumput mencapai ke atas gunung. >>>> (#) Ini kedengarannya jauh lebih baik dengan hutan (**) Catatan Saran (#) >>>>

Laki-laki dan anjingnya dan misinya, untuk memotong rumput, padang rumput yang dicapai di atas gunung hanya tercapai ketika menyeberangi sungai.

Contoh Data Tanpa Urutan Escape

Ini adalah kisah tentang seorang pria. Seorang pria yang pergi untuk memotong rumput, pergi untuk memotong rumput. Pria itu pergi dengan anjingnya untuk memotong rumput. Jadi sekarang ini adalah kisah tentang seorang pria dan anjingnya yang pergi untuk memotong rumput.

Seorang pria dan anjingnya, pergi untuk memotong rumput, pergi untuk memotong rumput, sebuah padang rumput mencapai ke atas gunung.

Laki-laki dan anjingnya dan misinya, untuk memotong rumput, padang rumput yang dicapai di atas gunung hanya tercapai ketika menyeberangi sungai.

Jelas ini mudah diurai, tidak rumit sebagai bahasa Mark-up keseluruhan dan mudah beradaptasi dengan tujuan Anda.

Sudah Dipecahkan? Baiklah, saya akan mengatakan tidak. Solusi kami masih memiliki beberapa lubang. Akses pengindeksan dan terstruktur dari data ini buruk. Juga, tidak masuk akal untuk menanyakan file ini (atau beberapa file) bersamaan dengan mengeditnya.

Bagaimana kita bisa menyelesaikan masalah itu?

Saya akan menyarankan DATA ALOCATION TABLE sebagai header dokumen. Saya juga menyarankan untuk menerapkan TUE UPDATE TABLE UPDATE TRANSAKSI . Biarkan saya jelaskan. Perancang sistem file, khususnya sistem file disk rotasi, menghadapi tantangan desain yang serupa dengan yang telah Anda jelaskan di atas. Mereka perlu menanamkan informasi tentang file pada disk dengan, bersama dengan data. Solusi hebat untuk integritas hubungan data ini, adalah DUPLICATE dalam Tabel Alokasi File (FAT).

Ini berarti bahwa untuk setiap Item Metadata individual, ada entri yang sesuai di Tabel Alokasi Data . Jadi cepat, terstruktur dan relasional, dan independen dari data asli. Jika pertanyaan atau bergabung atau pembaruan perlu dilakukan pada metadata, maka itu mudah dilakukan dengan hanya mengakses Tabel Alokasi Data .

Jelas perhatian harus diberikan untuk memastikan bahwa metadata in-line asli adalah cerminan sejati dari data Tabel Alokasi Data. Di situlah Antrian Pembaruan Tabel Transaksional masuk. Setiap perubahan, penambahan atau penghapusan metadata, dilakukan bukan pada data itu sendiri, melainkan pada antrian. antrian kemudian akan memastikan bahwa semua perubahan dilakukan untuk data in-line dan tabel, atau tidak ada perubahan sama sekali. Ini juga memungkinkan pembaruan asinkron dilakukan, misalnya, semua metadata pengguna tertentu dapat dihapus dengan menjalankan perintah hapus pada antrian. Jika metadata inline dikunci dan digunakan, antrian tidak akan melakukan perubahan apa pun sampai bisa melakukannya untuk data Tabel dan data inline.


1
Halo Stephen dan selamat datang di Programer! Sementara saya menghargai antusiasme dalam jawaban Anda, saya harus menghapus komentar yang tidak relevan darinya. Kami lebih suka jawaban yang singkat, setepat dan setepat mungkin, agar lebih mudah diakses oleh audiens yang lebih luas.
yannis

Pertama-tama, saya harus mengatakan bahwa saya menyukai antusiasme dalam jawabannya, senang mendengar umpan balik yang baik. Sedangkan untuk jawabannya sendiri, saya harus mengatakan bahwa saya akan menentang sintaksis yang sama untuk membuka dan menutup tag; dan mungkin, untuk menghindari masalah XML yang saya jelaskan di atas dalam pembaruan terbaru saya, saya akan menentukan apa yang dibuka dan apa yang ditutup dalam tag itu sendiri; mungkin suka begitu: >>>>>(#1) Lorem ipsum (#1)>>>>>>. Juga, sepertinya pendekatan Anda dalam komentar intext akan membuat mereka mengikat ke posisi tetap tertentu, bagaimana cara kerjanya jika offset dipindahkan?
Sunyatasattva

Juga, bagaimana Anda akan pergi dan mendekati fakta mengikat komentar ke rentang offset daripada titik yang tepat? Last but not least: tabel alokasi data dan antrian pembaruan transaksional tampaknya konsep yang luar biasa. Saya melakukan riset tentang topik, tetapi bisakah Anda menguraikan sedikit tentang bagaimana Anda akan pergi dan menerapkan konsep-konsep dalam masalah arsitektur ini?
Sunyatasattva

1

Ini adalah jenis pertanyaan teknik yang khas karena semua opsi Anda memiliki pengorbanan yang berbeda, dan mana yang terbaik tergantung pada apa yang penting bagi Anda. Sayangnya, Anda belum memberikan informasi yang cukup untuk membuat keputusan.

Anda juga tampaknya belum mempertimbangkan masalah semantik yang penting. Katakanlah teks aslinya

Teman saya Bob meminjamkan saya lima dolar

Seseorang menambahkan komentar di sekitar pepatah "Bob"

Bob benar-benar idiot

Kemudian teks asli diedit ke

Jane meminjamkan Bob lima dolar yang kemudian dipinjamkannya kepadaku

Anda mungkin memahami kasus ini menggunakan algoritma pencocokan teks seperti apa yang digunakan untuk menampilkan file diff, tetapi offset karakter akan membuat metadata melampirkan ke "Jan" di "Jane".

Lebih buruk adalah jika teks diedit ke

Teman saya Steve meminjamkan saya lima dolar

Anda bisa mengetahui cara melampirkan metadata ke "Steve", tetapi bagaimana Anda tahu jika itu berlaku?

Juga, sudahkah Anda memutuskan apakah metadata itu sendiri dapat memiliki metadata? Itu mungkin mengubah implementasi Anda.

Di luar masalah semantik, tidak terlalu jelas apa yang Anda lakukan dengan data. Saya pikir mungkin sangat tidak nyaman untuk memiliki teks asli "tercemar" dengan markup apa pun, tetapi kemudian Anda tidak masalah dengan memiliki nilai ID di dalamnya. Yang tidak masuk akal jika metadata berlaku untuk bagian teks alih-alih dimasukkan ke titik dalam teks.

Dugaan saya adalah bahwa untuk sebagian besar tujuan menyimpan teks yang ditandai lebih mudah, atau, pilihan kedua, menggunakan semua SQL dan memiliki teks dan markup yang diwakili oleh hierarki simpul - pada dasarnya DOM dalam bentuk tabel. Jika data Anda hierarkis daripada mungkin lebih mudah menggunakan XML dan mendapatkan parser yang ada secara gratis, dibandingkan menulis sendiri.

Sangat mungkin bahwa ada beberapa solusi yang cukup sederhana yang cukup baik untuk situasi Anda yang sebenarnya, tetapi saya tidak dapat memberi tahu Anda apa itu karena itu benar-benar tergantung pada apa yang Anda coba lakukan, secara detail.

Saya sangat menyarankan Anda merangkum strategi apa pun yang Anda pilih sebanyak yang Anda bisa, meskipun ini cukup sulit dilakukan jika banyak dari implementasi Anda perlu terlihat oleh banyak pertanyaan SQL.

Maaf bahwa balasannya begitu tersebar dan begitu penuh dengan "itu tergantung", tetapi pertanyaan desain dunia nyata seperti itu.


Saya mengerti, dan saya tidak mencari jawaban yang tepat, benar, dan tepat. Tetapi untuk ide implementasi, analisis pengorbanan, atau mungkin saya pikir ada jawaban yang lebih baik daripada yang lain dan saya hanya tidak memikirkannya. Untuk menjawab pertanyaan yang Anda ajukan: tidak, dalam kasus saya metadata itu sendiri tidak akan memiliki metadata.
Sunyatasattva

Apa yang lebih baik tergantung pada apa yang Anda coba lakukan.
psr

Detail apa lagi yang menurut Anda tidak ada dalam pertanyaan saya untuk memberi Anda gambaran yang jelas?
Sunyatasattva

Lebih dari yang bisa Anda jelaskan. Seberapa penting memiliki metadata tentang bagian teks vs titik penyisipan, seberapa penting menjaga teks bersama dalam satu bidang dalam DB, seberapa sering masing-masing diedit, seberapa banyak pertanyaan akan dianalisis dalam SQL lurus vs menarik teks kemudian menganalisis kemudian dan apa tingkat kenyamanan Anda dengan masing-masing, apa skala ini terjadi, apa yang cenderung berubah dari waktu ke waktu, jika Anda pergi dengan markup apakah Anda nyaman menulis parser sederhana Anda sendiri atau akan Anda lakukan lebih baik dengan XML, yang kurang disesuaikan tetapi memiliki lebih banyak alat ...
psr

Itu sebabnya saya hanya bisa menawarkan panduan. Terutama karena jawabannya dimaksudkan untuk membantu orang lain dalam situasi yang sama, bukan hanya Anda.
psr

0

Saya pikir saran dari penjawab sebelumnya, yang Anda sebutkan pada pertanyaan Anda) adalah yang sangat bagus.

Itu akan berperilaku sama seperti kita memposting tautan di situs StackExchange, tetapi data info akan berada di tabel lain. Manfaatnya adalah, Anda memiliki data yang terpisah, dan karenanya dapat ditelusuri dan diindeks. Saat mengedit teks, Anda dapat memeriksa ID metadata yang dihapus dan membersihkan tabel metadata.

Satu-satunya masalah kecil seperti yang Anda katakan adalah penguraian, tetapi Anda bisa mengatasinya dengan mudah.


Apa jawaban sebelumnya? Urutan jawaban yang disajikan tidak dijamin dalam urutan apa pun - atau dalam hal ini, jawabannya mungkin diubah atau dihapus secara radikal untuk membuat jawaban Anda kurang berguna. Bisakah Anda mengubah pertanyaan Anda sedemikian rupa sehingga tidak perlu referensi jawaban lain?

Maksud saya, jawaban sebelumnya disebutkan oleh OP dalam pertanyaan
RMalke

0

Katakanlah saya punya teks:

Anda hanya perlu duduk dan menonton setiap bulan, dan tidak ada biaya tambahan untuk layanan ini seperti yang Anda miliki di sini, atau karena itu terkait dengan erat volutpat.

Saya menambahkan catatan seperti ini:

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

[@123,#456,2w]berarti: user_id = 123, note_id = 456, dan teks yang ditandai oleh note ini membentang untuk 2 kata berikutnya (bisa berupa karakter ( c), kalimat ( s), paragraf ( p) , paragraf ( ) atau apa pun). Sintaks yang tepat mungkin berbeda, tentu saja.

Dalam teks biasa editor catatan teks dapat dengan mudah disimpan di akhir dokumen, seperti halnya dengan catatan kaki Markdown.

Dalam editor teks kaya, catatan semacam ini dapat ditampilkan dalam teks sebagai ikon, dan teks yang ditandai dapat disorot dengan beberapa cara. Pengguna kemudian dapat menghapus catatan tersebut seperti karakter normal dengan Delatau Backspace, dan mengeditnya dengan semacam mode pengeditan khusus. Saya membayangkan mengubah ukuran area yang dicatat dengan mouse dan mengedit teks catatan dengan jendela sembulan.

Pro:

  • Sesuai dengan "persimpangan" karena Anda menandai offset (tersirat oleh posisi note dalam teks) dan panjang untuk setiap note.
  • Mendukung lingkungan multiuser. (Sebenarnya, ini membutuhkan penelitian lebih dalam dan Anda mungkin harus berurusan dengan sesuatu seperti transformasi operasional Google Wave , yang tidak bisa ditangani oleh otak saya.)
  • Dapat diedit dengan editor teks kaya dan polos.
  • Anda dapat dengan mudah menangani revisi, karena semua marker ada di tempat - saat Anda mengedit teks sebelum marker, marker hanya bergeser bersamaan dengan teks lainnya.
  • Mudah diurai.
  • Tidak perlu untuk DB eksternal, tetapi Anda masih bisa menggunakannya jika mau.
  • Dapat dicampur dengan penurunan harga atau XML jika Anda memilih beberapa sintaksis yang tidak mencolok.

Kontra untuk pengeditan teks biasa:

  • Anda tidak dapat melihat area dalam teks yang ditandai dengan catatan (kecuali jika Anda menyorot plaintext, yang merupakan opsi juga), tetapi hanya tempat di mana catatan dimulai. Ini dikompensasi oleh kemampuan untuk memilih satuan panjang sewenang-wenang: karakter, kata-kata, kalimat, paragraf.
  • Anda dapat mengedit teks di bawah catatan tanpa memperhatikan, terutama jika catatan itu cukup panjang (misalnya 2+ paragraf). Dapat dikompensasi oleh mekanisme kontrol revisi yang membandingkan teks di bawah setiap catatan dengan versi sebelumnya dan memberi tahu pengguna jika diubah.

Kontra umum:

  • Masalah dengan banyak pengguna mengedit teks yang sama, tapi saya pikir itu tidak bisa dihindari. Saya bukan ahli dalam bidang ini.

Apa yang menurut Anda pro untuk tidak menambahkan tag penutupan tetapi bekerja dengan offset? Bukankah ini terlalu berisiko? Bagaimana jika saya menambahkan kata di antara nonummydan nibh, bukankah itu akan mengacaukan offset saya?
Sunyatasattva

Ya, itu dapat mengacaukan offset dan masalah itu dapat diselesaikan dalam editor teks kaya dengan penanda akhir "virtual", yang bertindak persis seperti penanda awal, kecuali itu tidak dapat diedit secara eksplisit (hanya ada di sana untuk menandai suatu end-of-note, bergeser bersama dengan teks yang diedit) dan tidak disimpan dengan teks. Anda cukup memasukkannya saat mengedit dan kemudian menjatuhkannya saat menyimpan. Secara umum, saya pikir mungkin ada lebih banyak masalah dengan penanda awal dan akhir kemudian dengan hanya satu saja, tetapi tentu saja saya mungkin salah.
scriptin
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.