Context
The discussion began with questions about how to model copyright metadata, specifically regarding the handling of publication dates and the structure of metadata fields, referencing the BibTeX format commonly used in academic publishing.
Initial Questions
Gabo — 10/12/24
Is it common use to use only the year as the publishing time? Are month and day ever added to metadata too?
Regarding copyright metadata: should we allow open-ended labels, or can we define them at the protocol level to standardize them?
Answers and Discussion
mwra — 11/12/24
Using only year is a legacy of the print era. BibTeX for journals sometimes includes month or quarter, but standards are inconsistent.
It’s better to capture as much date information as is available. It’s harder to add missing details later than to ignore extra ones.
codeEric — 11/12/24
Proposed separating fields:
originalPublishDate (full date if known)
originalPublishYear (year-only if full date is unknown).
Alex Burdiyan — 12/12/24
Raised concern about data integrity: what if both fields are filled but conflict?
Emphasized the importance of consistency, especially in an open format.
Gabo — 12/12/24
Highlighted inconsistencies across academic organizations' BibTeX formatting standards.
Suggested allowing open key-value metadata as an option, possibly as linked data objects.
Proposed creating plugins or linters to ensure formatting correctness.
mwra — 12/12/24
Agreed that inconsistencies stem from the legacy transition from print to digital.
Recommended always capturing DOIs or permalinks for reliable referencing.
Emphasized the importance of metadata useful to readers (human and AI), not merely following outdated traditions.
Gabo — 12/12/24
Suggested that Seed Hypermedia could attempt to auto-find and validate metadata by querying index databases during import.
Oleg — 12/12/24
Suggested modeling dates with a decomposed structure {year, month, day, hour, minute, second} where components can be nullable.
Emphasized flexible and lossless storage of temporal data.
Deeper Reflections on BibTeX and Metadata Formats
mwra — 12/12/24
Critiqued BibTeX’s relevance today, noting its print-era origins and incomplete adaptation to web-based references.
Argued that JSON could be more practical than BibTeX.
Recommended designing Seed Hypermedia’s metadata to be a richer superset of traditional reference formats to ensure compatibility and future-proofing.
Oleg — 12/12/24
Clarified that "using BibTeX" could mean adopting its schema (field structure) but serializing it in JSON.
Noted that permanency of URIs is inherently fragile in distributed systems but duplication improves resilience.
Suggested keeping metadata minimal but sufficient to generate references for major standards (APA, MLA, Chicago, IEEE).
Moving Toward Schema Governance
Gabo — 12/12/24
Proposed allowing users to enter their own key-value pairs to preserve original metadata formatting.
Suggested allowing communities or site owners to define schemas and enforce them across members.
Alex Burdiyan — 12/12/24
Warned that fully freeform metadata (arbitrary keys) could cause chaos (e.g., typos).
Suggested letting communities define their own schemas and select keys from controlled vocabularies.
Supported the idea of mapping Seed metadata to popular citation formats.
Gabo — 12/12/24
Emphasized that communities like Hypertext Academia should define their own schemas without external imposition.
Proposed a waterfall permission pattern for schemas: parent documents define schemas for child documents.
Alex Burdiyan — 12/12/24
Cautioned about the complexity of inheritance systems.
Suggested keeping schema complexity bounded for practical maintainability.
Summary
Date fields should support both complete and partial information, preserving maximum precision when possible.
Metadata structure should balance openness with standardization: communities can define schemas, but freeform key entry should be discouraged.
BibTeX is outdated; a modern JSON-based schema inspired by but not constrained by BibTeX should be preferred.
Schemas can be defined per community, possibly inherited, but complexity must be carefully managed.