Universal XML-data representation for future SuperMemos

What should this XML design accomplish:

  • universal XML data exchange format for future SuperMemos on all platforms
  • blending on-line, desktop and handheld applications
  • possibility of establishing a global knowledge system in the future
  • universal identification of users,  pieces of knowledge, and sources
  • resistance to errors through redundancy and duplication (e.g. the same knowledge of the same user held on two devices/media/locations)
  • availability of shared knowledge via search engines

Basic XML elements that form SuperMemo XML data:

  • User/Student [tentative name alternatives] - description of individual students, their knowledge, their memory, their preferences, etc.
  • SuperMemoElement - individual pieces of knowledge, their content, children (nested SuperMemoElement's in knowledge tree structure), and their global parameters (e.g. source, user count, global difficulty, global popularity, global reliability, etc.)
  • SuperMemoCollection - set of elements and its attributes (e.g. author, source, description, library catalog position/code, element count, etc.)
  • LearningData - description of learning parameters specific for a given SuperMemoElement for a given User/Student
  • StudentKnowledge - a super-collection mastered by a single User/Student, its element's Learning data, and other parameters (e.g. learning statistics)
  • GlobalKnowledge - description and parameters of the global system of knowledge; all SuperMemoCollections and all knowledge sets (mutually intersecting)

Accessory elements:

  • StudentMemory - an "attribute" of User/Student with all data that helps characterize his memory (in the future, I believe this will be redundant -- as soon as a universal mathematical description of memory is completed with all emphasis shifted to data and their behavior/interpretation in individual user memory)
  • SuperMemoElement/Content - located anywhere in the world on any device, possibly duplicated on different devices, or dual (local copy of a remote resource). May include attributes such as format (Q&A, HTML, Excel, SMWin), date (e.g. for content updates), source, etc.
  • StudentID - unique identifier (e.g. birthdate, platform ID, registration number for platform, random no) (e.g. 62.03.06.03.134213.392832)
  • ID - unique identifier (author ID, number of element) (short form: AID.2321)
  • StudentList - list of students using a given element (e.g. in on-line applications)

Same Elements may be organized in a different way. For example export from SuperMemo for Windows could result in the nested tree structure of SuperMemoElement's, their content and learning data, list of elements, list of content and list of learning data in separate files, elements and the knowledge tree, etc.. LearningData may link to SuperMemoElement/Content while SuperMemoElement may link to LearningData.

Elements can be located anywhere in the world, learning data can also be remote or local.

Wherever possible Elements on the web must be indexable by search engines!

Components
  • anywhere in the world (remote or local)
  • indexable by search engines
  • text (HTML, plain, RTF, and others supported by web browsers), images (supported by web browsers), sound (supported by web browsers), video (supported by web browsers), OLE, executable, SMWin script, and others
  • content attributes: display bits (question, answer, etc.), display mode (e.g. spelling test)

Core implementation:

Single text files organized as follows:

  1. Student element (optional)
  2. SuperMemoCollection element (optional)
  3. Nested structure of SuperMemoElement's with SuperMemoElement/Content and Learning data (optional)

We should allow of SuperMemoCollection being a child of Student as well as Student being a child of SuperMemoCollection (circular dependencies).

Repetition history may need to be stored on handhelds to retain continuity with SMWin.

Contents as XML, one element can belong to many branches, one branch can belong to many branches! Circularity will not be a problem as the user can dig as deep as (s)he wants, and the whole tree does not ever need to be displayed.

1.3.50