pub struct Metadata {Show 17 fields
pub schema_version: String,
pub title: String,
pub authors: Vec<String>,
pub year: Option<i32>,
pub doi: Option<Doi>,
pub arxiv_id: Option<ArxivId>,
pub abstract_: Option<String>,
pub venue: Option<String>,
pub publisher: Option<String>,
pub issn: Option<String>,
pub isbn: Option<String>,
pub type_: Option<String>,
pub keywords: Vec<String>,
pub url: Option<String>,
pub pdf_path: Option<String>,
pub doiget: Option<DoigetExtension>,
pub other: BTreeMap<String, Value>,
}Expand description
Metadata for a single stored entry.
Reserved top-level fields per docs/STORE.md §2. schema_version is a
string of the form <MAJOR>.<MINOR>; the current version this build
writes is crate::SCHEMA_VERSION.
Unknown top-level fields and unknown tables are preserved verbatim
through the other field, so reading-and-rewriting an entry produced
by a future minor revision (or by BiblioFetch.jl) does not silently
drop data.
Fields§
§schema_version: StringSchema version of the form <MAJOR>.<MINOR>. See docs/STORE.md §3.
title: StringPaper title.
List of authors (preserve original ordering).
year: Option<i32>Publication year, if known.
doi: Option<Doi>DOI, if any.
arxiv_id: Option<ArxivId>arXiv id, if any.
abstract_: Option<String>Abstract; serialized as the bare abstract key (Rust keyword).
venue: Option<String>Venue (e.g. journal or conference).
publisher: Option<String>Publisher.
issn: Option<String>ISSN (for journals).
isbn: Option<String>ISBN (for books).
type_: Option<String>Crossref-taxonomy type. Serialized as the bare type key.
keywords: Vec<String>Free-form keywords.
url: Option<String>Canonical URL for the entry, if any.
pdf_path: Option<String>Path to the stored PDF, relative to the store root.
doiget: Option<DoigetExtension>doiget-specific extension table. BiblioFetch.jl ignores it.
other: BTreeMap<String, Value>All other top-level keys and tables (e.g. [bibliofetch]).
Per docs/STORE.md §8 we MUST tolerate unknown top-level fields and
unknown tables. Unknown entries are captured here so a read /
modify / write cycle does not silently drop them. Keys are stored in
a BTreeMap so re-serialization is alphabetically ordered, matching
the normalization rule in docs/STORE.md §7.