From cc0393de91301a29bd469e38519125a530b4472d Mon Sep 17 00:00:00 2001 From: Bryan Newbold Date: Wed, 24 Nov 2021 15:46:28 -0800 Subject: codespell fixes to original RFC --- fatcat-rfc.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) (limited to 'fatcat-rfc.md') diff --git a/fatcat-rfc.md b/fatcat-rfc.md index 13466df2..8b966bdf 100644 --- a/fatcat-rfc.md +++ b/fatcat-rfc.md @@ -63,7 +63,7 @@ to a rigid third-party ontology or schema. Microservice daemons should be able to proxy between the primary API and standard protocols like ResourceSync and OAI-PMH, and third party bots could -ingest or synchronize the databse in those formats. +ingest or synchronize the database in those formats. ## Licensing @@ -109,7 +109,7 @@ push through edits more rapidly (eg, importing new works from a publisher API). Bots need to be tuned to have appropriate edit group sizes (eg, daily batches, instead of millions of works in a single edit) to make human QA review and -reverts managable. +reverts manageable. Data provenance and source references are captured in the edit metadata, instead of being encoded in the entity data model itself. In the case of importing @@ -153,7 +153,7 @@ In comparison, 96-bit identifiers would have 20 characters and look like: work_rzga5b9cd7efgh04iljk https://fatcat.wiki/work/rzga5b9cd7efgh04iljk -A 64-bit namespace would probably be large enought, and would work with +A 64-bit namespace would probably be large enough, and would work with database Integer columns: work_rzga5b9cd7efg @@ -170,7 +170,7 @@ entity. Revisions are stored in their complete form, not as a patch or difference; if comparing to distributed version control systems, this is the git model, not the mercurial model. -The entity revisions are immutable once accepted; the editting process involves +The entity revisions are immutable once accepted; the editing process involves the creation of new entity revisions and, if the edit is approved, pointing the identifier to the new revision. Entities cross-reference between themselves by *identifier* not *revision number*. Identifier pointers also support @@ -327,7 +327,7 @@ Some special namespace tables and enums would probably be helpful; these could live in the database (not requiring a database migration to update), but should have more controlled editing workflow... perhaps versioned in the codebase: -- identifier namespaces (DOI, ISBN, ISSN, ORCID, etc; but not the identifers +- identifier namespaces (DOI, ISBN, ISSN, ORCID, etc; but not the identifiers themselves) - subject categorization - license and open access status -- cgit v1.2.3