In my research at AGI Laboratory, I ran into an indexing problem for seed material.  I know there is a project online where you can have create these mind files and add your memories and other details to them.  The problem is I couldn’t find the actual file format details I need the ‘engineering’ level details to use this as the indexing format for the seed material going into system seeded for instances of ICOM both in mASI and AGI configurations.  (note that agi configurations are still just toys).  So here is the file format as we are occurring using it.  This is an XML-based format that can be serialized as ‘*.mffl’ files in both XML and JSON.  Here is the XML Schema (definition of the mile file format mark up language) version 1:

Figure 1. XSD XML Schema

An XML Schema like this is used to programmatically validate a given mind file to ensure it is the correct format or for validating a serialized version itself being in XML.  Take a look at this diagram:

Figure 2. Schema Hierarchy

This diagram is in a Schema explorer and it shows you the overall structure where you can see it is fundamentally simple.

Here is a short white paper on the format: 

The Mind File Format using Mind Extensible Markup Language (MFFL)
Definition and Usage

Abstract: The Mind File Format based on the Mind File Format Language or (MFFL) is an XML-based
markup language designed to structure metadata and relationships between document contextual
information used in modeling knowledge in a graph format, including import and mind modeling and
related activities. Specifically, this was designed to address the needs of the ICOM (Independent Core
Observer Model) research program at AGI Laboratory.

Keywords: ICOM, file type, XML, RDF, MFFL, Schema, Mind file

Version: 1.3

The mind file format or mind file format language (mffl) is designed for documenting contextual
experience, knowledge, and the metadata associated with a mind. This could be a knowledge item,
scientific paper, or experience. The theoretical uses would be for creating minds based on a set of
knowledge, creating AI seeds for AGI systems or chatbots, or modeling a person’s mind. In theory, the
Mind file format could be used to develop 3rd-degree level 3 instances of a mind that you don’t have
direct access to. The primary application in this definition paper is seed data for ICOM (Independent
Core Observer Model) based systems.

Note: Referring to copies or instances of a mind and for the purposes of this paper, a first-degree
instance is an original biological mind. A second-degree instance is a direct literal copy of a mind. A
third-degree instance or copy is abstracted with data and not a direct copy.
The audience for this document is technical and engineering people that can understand XML markup
languages and understand basic data principles around data import processing and graph databases.
This document is very technical and targeted to that audience.

Similar Formats

There are similar formats, even for similar purposes. A quasi-religious organization called Teresem
(Rothblatt) has a mind file project. Still, this organization was unresponsive when approached about
getting information about this format. (Duncan)

The following example is StarDogs RDF (StarDog)(Gandon) format, which has a W3C standard that
started off as an XML-based standard and is still published but popularly uses turtle syntax. RDF has a
standard for Turtle syntax as well. RDF primarily consists of lists of graph edges in the form of triples.
“The RDF data model is similar to classical conceptual modeling approaches (such as entity-relationship
or class diagrams). It is based on the idea of making statements about resources (in particular web
resources) in expressions of the form subject–predicate–object, known as triples. The subject denotes
the resource, and the predicate denotes traits or aspects of the resource, and expresses a relationship
between the subject and the object.” (Wiki)

Here is an example:

:The_Beatles      rdf:type :Band .
:The_Beatles      :name “The Beatles”.
:The_Beatles      :member :John_Lennon

Figure 1 – RDF Turtle Syntax  

While RDF could do the job, it is more geared to graph edge documentation and inconsistently uses XML
structures. The tendency towards usage is the turtle syntax, which has less tooling. A new XML-based
markup language allows for a more clean model with objects that will serialize for processing easier with
fewer transformations and without loading into a graph while still supporting a graph model. This can
then be made more human-readable while supporting a more complex JSON-based serialization for
transmitting MXL (Mind Extensible Markup Language) data. While it could be nice to have this
supported as a wider standard at the W3C level, it servers none of the requirements to do so.
MXL MIME Type “text/mffl.”

A MIME type is an identifier of the type of a given file is. For example, that file is of MIME type X, which
would tell you what kind of file it is and the type of data it contains. MFFL is an ASCII-based text format
using the MIME type. If popularized, it should be submitted to the Internet Assigned Numbers Authority
(IANA). The current usage of a MIME Type for MFFL is “text/mffl.” The associated file extension for this
MIME-type is *.mffl.

Basic XML Based MFFL Structure

The following is a basic Mind File Format document based on XML. This version is without a schema and
a newer version may have namespaces added as well as other minor features.

<?xml version=”1.0″ encoding=”UTF-8″?>
<mffl xsi:noNamespaceSchemaLocation=””
xmlns:xsi=”” version=”1.0″>
<Pattern />
<Created />
<Modified />
<Interest />
<Need />
<MetaData />
<Signed />
<Source><!– can have one –>
<Definition><!– can have many –>
AGI Laboratory, Copyright 2021
<Related><!– can have many –>
<Type><!– can have many –>
<ResponseType><!– can have many –>
<ResponseModel><!– can have many –>

Figure 2 – Sample MFFL file (Sample.mffl)

The MFFL format consists of 21 node types that can be nested only in a particular order, as
demonstrated in Figure 2. These can be validated, and any tool designed to process MFFL files will
reject any file that does not follow the nesting order and container types for each node. Here are the
definitions of each node and its nesting rules.

?xml – this node is an indicator that this is an XML-based format and indicates the encoding type. This
also indicates that a Schema should be used to validate the file and where the Schema exists.

<!– –> – this is an XML Comment node. This can be anywhere in the file between nodes and should be
ignored by any tools doing the processing of the MFFL file.

mffl – This is the MFFL root node and can only contain the property “version” and can contain a
Collection node.

Collection – The Collection node can contain 0 to N Context nodes.

Context – The Context node is the root of a given node in MFFL format. This is the fundamental unit of
data and is the root node of a knowledge graph or can be. The Context node has 14 nodes; it must
contain Pattern, Created, Modified, Plutchik, Interest, Need, MetaData, Source, Definition,
RelatedPatterns, Type, ResponseType, Signed, and ResponseModel nodes.

Pattern – This node can contain any possible pattern identifier from a GUID to binary CDATA section.

Created – This node contains a timestamp for when this node was created. This must be a valid
timestamp in the form of ticks.

Modified – This node contains a timestamp for when this node was last modified. This must be a valid
timestamp in the form of ticks.

Plutchik – This node must contain a valid set of 8 comma-delimited floating-point values. The default is
all zeros.

Interest – this node contains an interest score that is typically computer-generated but must be a
floating-point value or null.

Need – this node contains a need score that is typically computer-generated that is a floating-point

MetaData – this node can contain text, XML, or a binary CData section.

Signed – This public signing key indicates that this context node has been approved.
Source – this node can contain only a single ContextRef node indicating where the Context node came

Definition – this node is a collection that can have 0 to N ContextRef nodes. This collection of child
nodes defines this Context node.

Related – this node is a collection with 0 to N ContextRef nodes. This collection of child nodes indicates
related Context nodes.

Type – this node is a collection with 0 to N ContextRef nodes. This collection of child nodes should
indicate the type of the Context node.

ResponseType – this node is a collection with 0 to N ContextRef nodes. The collection of child nodes
indicates references to other Context nodes that define the response type for this Context node.

ResponseModel – this node is a collection that can have 0 to N ContextRef nodes. This collection of child
nodes references other context nodes that are other Context nodes that define the response model for
this Context node.

ContextRef – this node must have 3 node children, including Pattern, RefType, and Plutchik nodes.
These three child nodes point to a given additional ‘Context’ node that helps define a given collection in
which the ContextRef node is contained.

RefType – this node can contain any possible pattern identifier from a GUID to binary CDATA section.
Future versions may add additional nodes but should be backward compatible with this structure.
XML Schema

XML schemas use XML to define a markup language or data language and then do validation on a given
set of data to ensure referential integrity of the data. A basic Schema has been created and uploaded to but also is at the end of this document in Appendix A.
Serialization for Transmission

The preferred transmission structure over HTTP/HTTPS is via JSON which should follow the Schema
Structure but in JSON instead of XML. In JSON a Context node would look like this:

AGI Laboratory, Copyright 2021
“Pattern”:”[ data ]”,
“Created”:”[ data ]”,
“Modified”:”[ data ]”,
“Plutchik”:”[ data ]”,
“Interest”:”[ data ]”,
“Need”:”[ data ]”,
“MetaData”:”[ data ]”,
“Signed”:”[ data ]”,
“Source”:”[ collection of ContextRef objects]”,
“Defition”:”[ collection of ContextRef objects ]”,
“Related”:”[ collection of ContextRef objects ]”,
“Type”:”[ collection of ContextRef objects ]”,
“ResponseType”:”[ collection of ContextRef objects ]”,
“ResponseModel”:”[ collection of ContextRef objects ]”

Figure 3 – MFFL XML Serialized into JSON

This compressed format should be used in transmission. Still, the resting state should be in XML to be
more flexible for human readability.

Discussion and Further Related Work

The driving motivation for this work by the ICOM project at AGI Laboratory is better metadata,
cataloging, and analysis of seed data used to generate ICOM systems. The natural evolution of the
format will likely involve additional tooling such as a Windows-based generator that allows a person to
just fill out a form and have the file generated. This probably will be a WPF (Windows Presentation
Foundation) to run as a binary versus a UWP (Universal Windows Platform) application in the windows
store closed environment. At the time of writing, the expectation is a share that can be uploaded to
place seed data proposals and the associated MFFL files. A best practice will be to name the MFFL files
the same as the proposed file but with a different file extension. Depending on the MIME Type.

Duncan, B.; “lifenaut eternalize;”; Accessed 18 Nov 2021

Rothblatt, M.; “Terasem Faith – Personal Cyberconsciousness & Geoethical Nanotechnology for Human

Life Extension;”; (2018); Accessed 18 Nov 2021

Gandon, F.; Schreiber, G.; Beckett, D.; “WcC RDF 1.1 XML Syntax;” 25 Feb 2014;; Accessed 18 Nov 2021

Wiki; “Resource Description Framework;”; Accessed 18 Nov 2021

StarDog; “RDF Graph Data Model – Learn about the RDF graph model used by Stardog.;” 2018;; Accessed 18 Nov 2021