aboutsummaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
-rw-r--r--fatcat-rfc.md10
1 files changed, 5 insertions, 5 deletions
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