Usul: Ayat dan Biblio

[Thaza-Kun]

Mengusulkan dokumentasi penggunaan kata dalam ayat serta maklumat bibliografi.

Cadangan bentuk datanya lebih kurang begini:

struct Lemma {
    // --snip
   kemunculan: Vec<Ayat>
}

struct Ayat {
    ayat: String,
    biblio: Biblio
}

struct Biblio {
    tahun: i64,
    penulis: Vec<String>,
    title: String,
     // --snip
}

Struct Biblio seharusnya diambil inspirasi dari pengurus rujukan seperti Zotero, Mendeley dan EndNote. Ia seharusnya boleh menguruskan media pelbagai termasuklah media cetak akademik, bukan akademik, media video, media sosial, dsb.

[Thaza-Kun]

Kajian Kes: Zotero

Zotero ialah pengurus rujukan bersumber terbuka. Data-datanya disimpan secara setempat dan boleh dibaca begitu sahaja.

Dengan membuka $ZOTERO_DIR/zotero.sqlite, aku dapati nilai 'field' dan 'value' dipisahkan dari 'item'. Maknanya data tahun, tajuk dan penerbit dikumpulkan dalam jadual 'value' dan medannya disimpan dalam jadual 'field' kemudian jadual perantara menghubungkan jadual 'value', 'field' dan 'item' untuk membentuk bibliografi penuh. Pendekatan ini membolehkan item 'field' berbeza jenis, contohnya ada yang wujud maklumat 'tempat' manakala ada yang wujud maklumat 'laman web'.

Ringkasnya, jadual itemnya boleh dibayangkan begini:

struct Items {
    id: i64,
    itemType: ItemType,
    // Daripada terus mentakrif data {tarikh: A, tajuk: B}, 
    // Zotero mentarkrif data sebagai [('tarikh', A), ('tajuk', B)]
    // untuk membolehkan jenis medan nilai mengikut `ItemType` berbeza, 
    // misalnya: [('tahun', A),('tajuk_buku', B)] untuk ItemType("Buku") 
    // dan [('tarikh', A), ('tajuk_rencana', B)] untuk ItemType("Rencana")
    values: Vec<(Field, Value)>,
    // Perkara yang sama juga untuk `Creator`.
    // Misalnya: [(A, 'penulis')] untuk ItemType("Buku")
    // dan [(B, 'pengarah')] untuk ItemType("Filem")
    creators: Vec<(Creator, CreatorType)>,
}
struct Field(String);
struct Value(String);
struct Creator(String);
struct ItemType(String);

struct CreatorType {
    itemtype: ItemType,
    name: String,
}

Rajah ERD

// -- Main Bibliographic item
Table items {
itemID integer [pk]
itemTypeID integer [ref: < itemTypes.itemTypeID]
}
// -- Item Data
Table ItemData {
itemID integer [pk, ref: > items.itemID]
fieldID integer [pk, ref: > fieldsCombined.fieldID]
valueID integer [ref: > itemDataValues.valueID]
}

Table fieldsCombined {
fieldID integer [pk]
fieldName string
label String
}

Table itemDataValues {
valueID integer [pk]
value string
}
// -- Creators Table
Table creators {
    creatorID integer [PK]
    firstName string
    lastName string
}
// --- Creator to Biblio Connector
Table itemCreators {
    itemID integer [pk, ref: > items.itemID]
    creatorID integer [pk, ref: > creators.creatorID]
    creatorTypeID integer [pk, ref: > creatorTypes.creatorTypeID]
    orderIndex integer [pk]
}
// -- Creator types (i.e. authors, directors, etc.) is tied to the item type
Table creatorTypes {
    creatorTypeID integer [pk]
    creatorType string
}

Table itemTypeCreatorTypes {
    itemTypeID integer [pk, ref: > itemTypes.itemTypeID]
    creatorTypeID integer [pk, ref: > creatorTypes.creatorTypeID]
    primaryField integer [note: "Main creator of this item type"]
}

Table itemTypes {
    itemTypeID integer [pk]
    typeName string
}

[Thaza-Kun]

Kajian Kes: Hayagriva

Hayagriva ialah format bibliografi moden yang menandingi BibTeX atau RIS. Daripada dokumentasinya (ditebalkan di sini),

Hayagriva aims to keep the number of fields it uses small to make the format easier to memorize and therefore write without consulting the documentation. Other contemporary literature management file formats like RIS and BibLaTeX use many fields to account for every kind of information that could be attached to some piece of media.

Disebabkan SQL tidak seanjal JSON dalam membolehkan data sembarangan bentuk, objektif untuk "keep the number of fields it uses small" itu sesuai untuk kegunaan kita.

Format Fail

Hayagriva menggunakan format yaml untuk menyusun datanya. Bentuk data nampaknya agak leper yang mudah untuk dipindahkan jadi jadual SQL melainkan beberapa nilai yang perlu dinormalkan semula. Bentuknya begini:

# [panduan baca]
# - <a> : ganti `a` dengan nilai
# - a | b : `a` atau `b`
# - a[] : senarai yang sejenis `a`.
# - {a: A, b: B}: dictionary (sila format balik ikut cara yaml)
<citekey>:
    type: string
    title: string
    author: string | string[]
    date: Date
    # a list of object with the same structure
    parent: Recursive[]
    ### -- Nampaknya nilai-nilai di bawah ini untuk jenis-jenis khusus 
    abstract: string
    genre: string
    editor: string | string[]
    # persons involved with the item that do not fit author or editor
    affiliated: {role: string, name: string | string[]}[]
    call-number: string
    publisher: string | {name: string, location: string}[]
    # location at which an entry is physically located or took place.
    location: string
    organization: string
    issue: numeric | string
    volume: numeric | string
    volume-total: numeric
    edition: numeric | string
    page-range: numeric | string # e.g. 812-847
    page-total: numeric
    # the time range within the parent this item starts and ends at
    time-range: timestamp range
    runtime: timestamp
    url: string | {value: string, date: date}
    serial-number: string | {<type>: string} # e.g. {doi: <doi value here>, arxiv: <arxiv value here>}
    language: string
    archive: string
    archive-location: string
    note: string