notes/TODO

3 files changed, 110 insertions, 19 deletions

diff --git a/TODO b/TODO
index db059f15..e30c7028 100644
--- a/TODO
+++ b/TODO
@@ -1,20 +1,50 @@
 
-- tests are picking up config.py instead of using setUp()
+high-level this weekend:
+- test: create "rich" work (all entities; group approve), all via API
+- test: merge two rich works, all via API
+- naive API-based import scripts for: journals (norwegian), orcid, crossref
 
-helpers/ORM and test
-x files
-x containers
-- citations
-x create from crossref dict (naive)
-- "hydrated" get: release, creator, container
-- populate_random_edit; push edit to live
-- helpers with change logging (hook?)
+helpers/ORM
+- method to "approve" edit_group
+- helpers to deal with edits and edit groups
+
+api
+- expose all models (like work)
+- expose edit_group and editor
+
+tests
+- create "rich" work (all entities) via edit mechanism (incl. approve)
+- modify existing release via edit mechanism (and commit)
+- merge two releases
+- update (via edit) a redirect release
+- merge two works (combining releases)
+- api: try to reuse an accepted edit group
+- api: try to modify an accepted edit
+- api: multiple edits, same entity
 
 review
-- should release point to work? I think not
-- remove 'state' and 'redirect_id' from all revision tables
+- hydrate in files for releases... nested good enough?
+- add a 'live' (or 'immutable') flag to revision tables
+- how to encode proposed redirects? history goes in changelog
+    => proposed_ident_action table, which points to edits
+    => ident in edit as a partial solution (not redirects)
+    => extend edit object to have "to/from" info, and be per-entity
+
+views
+- my edits/groups
+- oldest edits/edit-groups
 
 later:
+- "hydrate" files (and maybe container/authors/refs) in release
+- transclude primary_release in work
 - crossref json import script/benchmark
     => maybe both "raw" and string-dedupe?
 - public IDs are UUID (sqlite hack?)
+
+## High-Level Priorities
+
+- manual editing of containers and works/releases
+- bulk loading of releases, files, containers
+- accurate auto-matching matching of containers (eg, via ISSN)
+- full database dump and reload
+
diff --git a/notes/data_model.md b/notes/data_model.md
index fe21b533..94716b00 100644
--- a/notes/data_model.md
+++ b/notes/data_model.md
@@ -1,12 +1,20 @@
 
+Entity list:
+
+    work
+    release
+    creator
+    container
+    file
+
 ## Cookbook
 
-To create a new works:
+To create a new work:
 
     login/create account
 
-    match/lookup on first work; if found, modify not create
-    TODO: match/lookup on files?
+    match/lookup on first work; check if update actually needed
+    ? match/lookup on files
 
     new edit group (under account; wip)
     new edit (under group)
@@ -47,12 +55,30 @@ To edit, eg, a contributor:
 
 Accept edit group:
 
-    for each edit:
-      update entity ident state (activate, redirect, delete)
-      ? mark revision/edit as immutable
-      ? append log/changelog row
+    for each entity type:
+      for each edit:
+        update entity ident state (activate, redirect, delete)
+    append log/changelog row
     update edit group state
 
+
+Bulk/Fase Import Crossref:
+
+    lookup work by identifier; if exists done
+    lookup journals by ISSN
+    lookup authors by ORCID
+    create new work
+      => stub container and authors if we can't find them
+    create new release
+    submit edit group
+
+
+Import Journals (same for authors):
+
+    lookup journal by ISSN
+    create new container
+    submit edit group
+
 ## Entity Schema
 
 Each entity type has tables:
@@ -68,7 +94,7 @@ Each entity type has tables:
       represents change metadata for a single change to one ident
       needed because an edit alwasy changes ident, but might not change rev
 
-    _log
+    _log (NOT IMPLEMENTED)
       history of when edits were actually applied
       allows fast lookups of history of an entity (ident)
       unnecessary if we keep a log of edit group accepts?
@@ -90,3 +116,37 @@ Each entity type has tables:
 
     "wip redirect" or "wip deleted" are invalid states
 
+## Entity Endpoints/Actions
+
+Actions could, in theory, be directed at any of:
+
+    entities (ident)
+    revision
+    edit
+
+A design decision to be made is how much to abstract away the distinction
+between these three types (particularly the identifier/revision distinction).
+
+Top-level entity actions (resulting in edits):
+
+    create (new rev)
+    redirect
+    split
+    update (new rev)
+    delete
+
+On existing entity edits (within a group):
+
+    update
+    delete
+
+An edit group as a whole can be:
+
+    create
+    submit
+    accept
+
+Other per-entity endpoints:
+
+    match (by field/context)
+    lookup (by external persistent identifier)
diff --git a/notes/url_structure.txt b/notes/url_structure.txt
index 8c3d8ff1..14a3e41d 100644
--- a/notes/url_structure.txt
+++ b/notes/url_structure.txt
@@ -36,3 +36,4 @@ Workflow requires sessions to hold, eg, current edit group.
 /                   some sort of about page, html?
 /v0/...
 /graphql/v0/...     ?
+