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:
- Student element (optional)
- SuperMemoCollection element (optional)
- 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.