spellcheck

17 files changed, 55 insertions, 48 deletions

diff --git a/mmm/mmmfs/plugins/cites.moon b/mmm/mmmfs/plugins/cites.moon
index 8bd7b12..10fd874 100644
--- a/mmm/mmmfs/plugins/cites.moon
+++ b/mmm/mmmfs/plugins/cites.moon
@@ -21,8 +21,7 @@ format_full = () =>
   tt = title @
   dot, com = if @title\match '[.?!]$' then '', '' else '.', ','
 
-  -- @author = deandify @author if @author
-  -- @editor = deandify @editor if @editor
+  @author or= 'N. N.'
   
   switch @_type
     when 'book', 'article'
@@ -41,9 +40,10 @@ format_full = () =>
         \insert "#{dot} #{@publisher}" if @publisher
     when 'web', 'online'
       span with setmetatable {}, __index: table
-        \insert "#{@author} (#{@year}), " if @author and @year
+        \insert "#{@author}"
+        \insert " (#{@year})" if @year
+        \insert ", "
         \insert tt
-        \insert " (#{@year})" if @year and not @author
         \insert "#{com} #{@url}"
         \insert " from #{@visited}" if @visited
     else
diff --git a/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md
index 549ea99..010f861 100644
--- a/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md
+++ b/root/articles/mmmfs/ba_log/2019-10-10/text$markdown.md
@@ -30,7 +30,7 @@ That means that when the root fileder is rendered, currently 120MB of data have
 Now that the client can render content within the web browser again, that would be even worse due to the network delay.
 
 To solve this, the Fileder implementation now lazy-loads \[[`9632233`][9632233]\].
-When a Fileder is created, it initially knows only its path, but doesn't know which factes or children it contains.
+When a Fileder is created, it initially knows only its path, but doesn't know which facets or children it contains.
 As soon as that data is attempted to be accessed, the fileder loads in the list of its children and facets from the datastore.
 The facet contents are loaded only when they are actually needed to fulfill a data request or conversion.
 
diff --git a/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md b/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md
index 9656562..4119d21 100644
--- a/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md
+++ b/root/articles/mmmfs/ba_log/2019-10-29/text$markdown.md
@@ -1,4 +1,4 @@
-Today i implemented updating/saving content in the server, and bridged the feature to the client.
+Today I implemented updating/saving content in the server, and bridged the feature to the client.
 In the inspector there is now a `save changes` button that (attempts to) save the content on
 the server's filesystem \[[`4b8d9be`][4b8d9be]\].
 
diff --git a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
index 70b8df5..27181a8 100644
--- a/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/evaluation/text$markdown+sidenotes.md
@@ -25,7 +25,7 @@ separately from its parent and context in most cases. This has made the implemen
 than initially anticipated.
 
 ### 6.1.2 pinwall
-The pinwall example shows some strenghts of the mmmfs system pretty convincingly.
+The pinwall example shows some strengths of the mmmfs system pretty convincingly.
 The type coercion layer completely abstracts away the complexities of transcluding different types of content,
 and only positioning and sizing the content, as well as enabling interaction, remain to handle in the pinwall fileder.
 
@@ -80,7 +80,7 @@ while others may be intrinsic limitations in the approach taken.
 In the current system, there is only a single, global set of *converts* that can be potentially applied to facets
 anywhere in the system.
 Therefore it is necessary to encode behaviour directly (as code) in facets wherever exceptional behaviour is required.
-For example if a fileder conatining multiple images wants to provide custom UI for each image when viewed independently,
+For example if a fileder containing multiple images wants to provide custom UI for each image when viewed independently,
 this code has to either be attached to every image individually (and redundantly), or added as a global convert.
 To make sure this convert does not interfere with images elsewhere in the system, it would be necessary to introduce
 a new type and change the images to use it, which may present even more problems, and works against the principle of
@@ -94,7 +94,7 @@ Additionally it could be made possible to use this mechanism to locally override
 further up in the tree, for example to specialize types based on their context in the system.
 
 <mmm-embed wrap="marginnote" path="../references/alternatives-to-trees">See also </mmm-embed>
-The biggest downside to this approach would be that it  presents another pressure factor for, while also reincforcing,
+The biggest downside to this approach would be that it  presents another pressure factor for, while also reinforcing,
 the hierarchical organization of data, thereby exacerbating the limits of hierarchical structures.
 
 ### 6.2.2 code outside of the system
@@ -109,7 +109,7 @@ This weakness represents a failure to (fully) implement the quality of a "Living
 *Ink and Switch*<mmm-embed path="../references/inkandswitch" wrap="sidenote"></mmm-embed>.
 
 In general however, some portion of code may always have to be left outside of the system.
-This also wouldn't necessarily represent a problem, but in this case it is particularily relevant
+This also wouldn't necessarily represent a problem, but in this case it is particularly relevant
 for the global set of *converts* (see above), as well as the layout used to render the web view. 
 Both of these are expected to undergo changes as users adapt the system to their own content types and
 domains of interest, as well as their visual identity, respectively.
@@ -148,7 +148,7 @@ viewable HTML markup, but it is hardly possible to propagate changes to the view
 This particular instance of the problem might be solvable using a Rich-Text editor, but the general problem worsens when
 the conversion path becomes more complex: If the markdown source was fetched via HTTP from a remote URL (e.g. if the
 facet's type was `URL -> text/markdown`), it is not possible to edit the content at all, since the only data owned by
-the system is the URL string itself, which is not part of the viewable representation. Similarily, when viewing output
+the system is the URL string itself, which is not part of the viewable representation. Similarly, when viewing output
 that is generated by code (e.g. `text/moonscript -> mmm/dom`), the code itself is not visible to the user, and if the
 user wishes to change parts of the representation, the system is unable to relate these changes to elements of the code
 or assist the user in doing so.
diff --git a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md
index d32b0db..0a82a51 100644
--- a/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/examples/implementation: text$markdown+sidenotes.md
@@ -12,22 +12,22 @@ This makes it suitable for denoting formatted-text titles and other small string
 The problem of embedding other content together with text comfortably is also solved easily,
 because Markdown allows embedding arbitrary HTML in the document.
 This made it possible to define a set of pseudo-HTML elements in the Markdown-convert,
-`<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmm.
+`<mmm-embed>` and `<mmm-link>`, which respectively embed and link to other content native to mmmfs.
 
-### 5.1.2 scientific publishing
+### 5.1.2 academic publishing
 <div class="sidenote" style="margin-top: 1.25rem">
 One of the 'standard' solutions, <a href="https://www.latex-project.org/">LaTeX</a>,
 is arguably at least as complex as the mmm system proposed here, but has a much narrower scope,
 since it does not support interaction.
 </div>
 
-Scientific publishing is notoriously complex, involving not only the transclusion of diagrams
+Academic publishing is notoriously complex, involving not only the transclusion of diagrams
 and other media, but generally requiring precise and consistent control over formatting and layout.
 Some of these complexities are tedious to manage, but present good opportunities for programmatic
 systems and media to do work for the writer.
 
 One such topic is the topic of references.
-References appear in various formats at multiple positions in a scientific document;
+References appear in various formats at multiple positions in a academic document;
 usually they are referenced via a reduced visual form within the text of the document,
 and then shown again with full details at the end of the document.
 
@@ -44,9 +44,9 @@ remote corrections.
 
 ## 5.2 pinwall
 In many situations, in particular for creative work, it is often useful to compile resources of
-different types for reference or inspiration, and arrange them spacially so that they can be viewed
+different types for reference or inspiration, and arrange them spatially so that they can be viewed
 at a glance or organized into different contexts etc.
-Such a pinwall could serve for example to organise references to articles,
+Such a pinwall could serve for example to organize references to articles,
 to collect visual inspiration for a moodboard etc.
 
 As a collection, the Pinwall is primarily mapped to a Fileder in the system.
@@ -75,7 +75,7 @@ advanced (and rewound) one by one using keypresses.
 The implementation of this is rather straightforward as well.
 The slideshow as a whole becomes a fileder with a script that generates a designated viewport rectangle,
 as well as a control interface with keys for advancing the active slide.
-It also allows putting the browser into fullscreen mode to maximise screenspace and remove  visual elements
+It also allows putting the browser into fullscreen mode to maximize screen space and remove  visual elements
 of the website that may distract from the presentation, and register an event handler for keyboard accelerators
 for moving through the presentation.
 
diff --git a/root/articles/mmmfs/framework/text$markdown+sidenotes.md b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
index 81acb02..0df28c4 100644
--- a/root/articles/mmmfs/framework/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/framework/text$markdown+sidenotes.md
@@ -17,7 +17,7 @@ end-user programming<mmm-embed path="../references/inkandswitch" wrap="sidenote"
   and in particular the ability to make changes at different levels of depth in the system with
   very short feedback loops and a feeling of direct experience.
 - *In-place toolchain*, denoting the availability of tools to customize and author the experience,
-  as well as a certain accesibility of these tools, granted by a conceptual affinity between the
+  as well as a certain accessibility of these tools, granted by a conceptual affinity between the
   use of the tools and general 'passive' use of containing system at large. 
 
 These serve as guiding principles for the design and evaluation of computer systems for end-users, but are by nature
@@ -33,6 +33,7 @@ paradigm pioneered in the creation of the Unix operating system at the AT&T Bell
 concepts are considered quite influential and are still notably applied in the Linux community. Many attempts at
 summaries exist, but the following includes the pieces that are especially relevant even today:
 
+<mmm-embed path="../references/unix" wrap="marginnote"></mmm-embed>
 > Even though the UNIX system introduces a number of innovative programs and techniques, no single program or idea makes
 > it work well. Instead, what makes it effective is the approach to programming, a philosophy of using the computer.
 > Although that philosophy can't be written down in a single sentence, at its heart is the idea that the power of a
@@ -52,7 +53,7 @@ directly to the concept of *Embodiment* described by Ink & Switch.
 3.3 content transclusion
 ------------------------
 
-The strengths of modular architectures should similarily extend also into the way the system will be used by users.
+The strengths of modular architectures should similarly extend also into the way the system will be used by users.
 If users are to store their information and customized behaviour in such an architecture, then powerful tools need to be
 present in order to assemble more complex solutions out of such parts. Therefore static content should be able to be
 linked to (as envisioned for the *Memex*, see above), but also to be <mmm-embed wrap="marginnote"
@@ -61,7 +62,7 @@ separate document, possibly stored remotely, by reference rather than by duplica
 </mmm-embed>*transcluded*,
 to facilitate the creation of flexible data formats and interactions, such that e.g. a slideshow slide can include
 content in a variety other formats (such as images and text) from anywhere else in the system. Behaviours also should be
-able to be transcluded and reused to facilitate the creation of ad-hoc sytems and applets based on user needs. For
+able to be transcluded and reused to facilitate the creation of ad-hoc systems and applets based on user needs. For
 example a user-created todo list should be able to take advantage of a sketching tool the user already has access to.
 
 By forming the immediately user-visible layer of the system out of the same abstractions that the deeper levels of the
diff --git a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
index 812d751..c022021 100644
--- a/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/historical-approaches/text$markdown+sidenotes.md
@@ -8,9 +8,10 @@ other systems at the time, as well as the systems we use currently, is that the
 directly known to the system.
 
 In a retrospective analysis of the Xerox Star's impact on the computer
-industry<mmm-embed path="../references/xerox-star" wrap="sidenote"></mmm-embed>, the desktop metaphor is described as
+industry, the desktop metaphor is described as
 follows:
 
+<mmm-embed path="../references/xerox-star" wrap="marginnote"></mmm-embed>
 > In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs.
 > They do not "invoke a text editor", they "open a document".
 > The system knows the type of each file and notifies the relevant application program when one is opened.
@@ -28,7 +29,7 @@ surely been lost.
 Another design detail of the Star system is the concept of "properties" that are stored for "objects" throughout the
 system (the objects being anything from files to characters or paragraphs). These typed pieces of information are
 labelled with a name and persistently stored, providing a mechanism to store metadata such as user preference for
-ordering or the defaut view mode of a folder for example.
+ordering or the default view mode of a folder for example.
 
 <mmm-embed path="star-graph" facet="note" wrap="marginnote" style="margin-top: 1rem;"></mmm-embed>
 <mmm-embed path="star-graph" nolink></mmm-embed>
@@ -47,7 +48,7 @@ true or inspired  ....
 One of the most innovative elements of Bush's predictions is the idea of technologically cross-referenced and
 connected information, which would later be known and created as *hypertext*. While hypertext powers the majority of
 today's internet, many of the advantages that Bush imagined have not carried over into the personal use of computers.
-There are very few tools for creating personal, highly-interconnected knowledgebases, even though it is technologically
+There are very few tools for creating personal, highly-interconnected knowledge bases, even though it is technologically
 feasible and a proven concept (exemplified for example by the massively successful online encyclopedia
 *Wikipedia*<mmm-embed path="../references/wikipedia" wrap="sidenote"></mmm-embed>).
 
diff --git a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
index 28030d7..883af51 100644
--- a/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/mmmfs/text$markdown+sidenotes.md
@@ -1,4 +1,4 @@
-# 4. mmmfs
+# 4. system description
 
 `mmmfs` is a newly developed personal data storage and processing system. It was developed first as a tool for
 generating static websites, but has been extended with live interaction and introspection, as well as embedded
@@ -7,12 +7,12 @@ editing capabilities as part of this work.
 mmmfs has been designed with a focus on data ownership for users. One of the main driving ideas is to unlock data
 from external data silos and file formats by making data available uniformly across different storage systems and
 formats. Secondly, computation and interactive elements are also integrated in the paradigm, so that mmmfs can be
-seemlessly extended and molded to the users needs.
+seamlessly extended and molded to the users needs.
 
 The abstraction of data types is accomplished using two major components, the *Type System and Coercion Engine* and
 the *Fileder Unified Data Model* for unified data storage and access.
 
-## 4.1 the fileder unified data model
+## 4.1 data storage model
 The Fileder Model is the underlying unified data storage model.
 Like many data storage models it is based fundamentally on the concept of a hierarchical tree-structure.
 
@@ -59,7 +59,7 @@ In mmmfs, the example above might look like this instead:
 
 Superficially, this may look quite similar: there is still only two types of nodes (referred to as *fileders* and
 *facets*), and again one of them, the *fileders* are used only to hierarchically organize *facets*. Unlike *files*,
-*factes* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*, that
+*facets* don't only store a freeform *name*, there is also a dedicated *type* field associated with every *facet*, that
 is explicitly designed to be understood and used by the system.
 
 Despite the similarities, the semantics of this system are very different: In mainstream filesystems, each *file* stands
@@ -77,7 +77,7 @@ Semantically a *fileder*, like a *directory*, also encompasses all the other *fi
 (recursively). Since *fileders* are the primary unit of data to be operated upon, *fileder* nesting emerges as a natural
 way of structuring complex data, both for access by the system and its components, as well as the user themself.
 
-## 4.2 the type system & coercion engine
+## 4.2 type system and coercion engine
 As mentioned above, *facets* store data alongside its *type*, and when a component of the system requires data from a
 *fileder*, it has to specify the *expected type* (or a list of these) that it requires the data to be in. The system
 then attempts to coerce one of the existing facets into the *expected type*, if possible. This process can involve many
@@ -95,7 +95,7 @@ Here are some common MIME-types that are also used in mmmfs:
 - `image/png`
 - `image/jpeg`
 
-While these types allow some amount of specifity, they fall short of describing their content especially in cases where
+While these types allow some amount of specificity, they fall short of describing their content especially in cases where
 formats overlap: Source code for example is often distributed in `.tar.gz` archive files (directory-trees that are first
 bundled into an `application/x-tar` archive, and then compressed into an `application/gzip` archive). Using either of
 these two types is respectively incorrect or insufficient information to properly treat and extract the contained data.
@@ -148,7 +148,7 @@ they return depend on the input type, as is required often when nested types are
     }
 
 This *convert* accepts an `application/gzip` *type* wrapping any other *type*, and captures that nested type in a
-pattern group. It then uses the substituion syntax to specify that nested type as the output of the conversion.
+pattern group. It then uses the substitution syntax to specify that nested type as the output of the conversion.
 For an input *type* of `application/gzip -> image/png` this *convert* would therefore generate the type `image/png`. 
 
 This last example further demonstrates the flexibility of this approach:
@@ -166,11 +166,11 @@ In addition to the attributes shown above, every *convert* is also rated with a
 roughly estimate both the cost (in terms of computing power) of the conversion, as well as the accuracy or immediacy of
 the conversion. For example, resizing an image to a lower size should have a high cost, because the process is
 computationally expensive, but also because a smaller image represents the original image to a lesser degree.
-Similarily, an URL to a piece of content is a less immediate representation than the content itself, so the cost of a
+Similarly, an URL to a piece of content is a less immediate representation than the content itself, so the cost of a
 *convert* that simply generates the URL to a piece of data should be high even if the process is very cheap to compute.
 
 Cost is defined in this way to make sure that the result of a type-coercion operation reflects the content that was
-present as accurately as possible. It is also important to prevent some nonsensical results from occuring, such as
+present as accurately as possible. It is also important to prevent some nonsensical results from occurring, such as
 displaying a link to content instead of the content itself because the link is cheaper to create than completely
 converting the content does.
 
diff --git a/root/articles/mmmfs/motivation/app-types/text$markdown.md b/root/articles/mmmfs/motivation/app-types/text$markdown.md
index aac79d7..aedef1c 100644
--- a/root/articles/mmmfs/motivation/app-types/text$markdown.md
+++ b/root/articles/mmmfs/motivation/app-types/text$markdown.md
@@ -1,3 +1,3 @@
 While there can be a distinction between *Native Applications* and *Web Applications* or *Cloud Services*, the following
-arguments apply to all different technicalal implementations of this same concept. The problems associated
-specifically with Web- and Cloud-based application models will be discussed separately below.
+arguments apply to all different technical implementations of this same concept. The problems associated specifically
+with Web- and Cloud-based application models will be discussed separately below.
diff --git a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
index 9bfdea5..e2e6550 100644
--- a/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
+++ b/root/articles/mmmfs/motivation/text$markdown+sidenotes.md
@@ -4,7 +4,7 @@
 ------------------------------
 
 The majority of users interact with modern computing systems in the form of smartphones, laptops or desktop PCs,
-using the mainstream operating systems Apple iOS and Mac OS X, Microsoft Windows or Android.
+using the mainstream operating systems Apple iOS and Mac&nbsp;OS&nbsp;X, Microsoft&nbsp;Windows or Android.
 
 <mmm-embed path="app-types" wrap="marginnote"></mmm-embed>
 All of these operating systems share the concept of *Applications* (or *Apps*) as one of the core pieces of their
@@ -12,8 +12,8 @@ interaction model. Functionality and capabilities of the digital devices are bun
 as applications. This focus on applications as the primary unit of systems can be seen as the root cause of multiple problems.
 
 For one, since applications are produced by private companies on the software market,
-developers compete on features integrated into their applications. To stay relevant, monlithic software or software
-suites tend to accrete features rather then modularise and delegate to other software<mmm-embed wrap="sidenote"
+developers compete on features integrated into their applications. To stay relevant, monolithic software or software
+suites tend to accrete features rather then modularize and delegate to other software<mmm-embed wrap="sidenote"
 path="../references/appliances"></mmm-embed>. This makes many software packages more complex and unintuitive than
 they need to be, and also cripples interoperability between applications and data formats.
 
@@ -52,9 +52,9 @@ other than through a standardized set of interactions (e.g. selecting a file via
 video from a webcam, opening another website).
 
 Cloud software, as well as subscription-model software with online-verification mechanisms, are additionally subject
-to license changes, updates modifiying, restricting or simply removing past functionality etc. Additionally, many cloud
+to license changes, updates modifying, restricting or simply removing past functionality etc. Additionally, many cloud
 software solutions and ecosystems store the users' data in the cloud, often across national borders, where legal and
-privacy concerns are intransparently handled by the companies. If a company, for any reason, is unable or unwanting to
+privacy concerns are intransparently handled by the companies. If a company, for any reason, is unable or unwilling to
 continue servicing a customer, the users data may be irrecoverably lost (or access prevented). This can have serious
 consequences<mmm-embed path="../references/adobe" wrap="sidenote"></mmm-embed>, especially for professional users, for
 whom an inability to access their tools or their cloud-stored data can pose an existential threat.
@@ -65,11 +65,11 @@ whom an inability to access their tools or their cloud-stored data can pose an e
 Cragg coins the term "inert data"<mmm-embed path="../references/super-powers" wrap="sidenote"></mmm-embed> for the data
 created and left behind by apps and applications in the computing model that is currently prevalent: Most data today
 is either intrinsically linked to one specific application, that controls and limits access to the actual information,
-or, even worse, stored in the cloud where users have no direct access at all. In the latter case users depend soley on
+or, even worse, stored in the cloud where users have no direct access at all. In the latter case users depend solely on
 online tools that require a stable network connection and a modern browser and could be modified, removed, or otherwise
 negatively impacted at any moment.
 
-Aside from being inaccesible to users, the resulting complex proprietary formats are also opaque and useless to other
+Aside from being inaccessible to users, the resulting complex proprietary formats are also opaque and useless to other
 applications and the operating system, which often is a huge missed opportunity: 
 The .docx format for example, commonly used for storing mostly textual data enriched with images and on occasion videos,
 is in fact a type of archive that can contain many virtual files internally, such as the various media files contained
@@ -110,7 +110,7 @@ To avoid facing this dilemma, a more sensible system could leave the task of pos
 different types to one software component, while multiple different software components could be responsible for editing
 the individual pieces of content, so that the most appropriate one can be chosen for each element. While creating the
 technological interface between these components is certainly a challenge, the resulting system would greatly benefit
-from the exponentially-growing capabilties resulting from the modular reuse of components across many contexts: A rich
+from the exponentially-growing capabilities resulting from the modular reuse of components across many contexts: A rich
 text editor component could be used for example not just in a mixed media collection as proposed above, but also for
 an email editor or the input fields in a browser.
 
@@ -121,7 +121,7 @@ deeply understanding the software they use and the data they own, from customizi
 interactions, and from properly owning, contextualising and connecting their data.
 
 Interestingly, these deficits do not appear throughout the history of today's computing systems, but are based in rather
-recent developments in the field. In fact the most influental systems in the past aspired to the polar opposites, as i
+recent developments in the field. In fact the most influential systems in the past aspired to the polar opposites, as I
 will show in the next section.
 
 <!--
diff --git a/root/articles/mmmfs/references/acm-dl/text$bibtex b/root/articles/mmmfs/references/acm-dl/text$bibtex
index ab7b9db..8fb36a2 100644
--- a/root/articles/mmmfs/references/acm-dl/text$bibtex
+++ b/root/articles/mmmfs/references/acm-dl/text$bibtex
@@ -1,4 +1,5 @@
 @online{acm-dl,
   title = {ACM Digital Library},
   url = {https://dl.acm.org},
+  year = {n. d.},
 }
diff --git a/root/articles/mmmfs/references/adobe/text$bibtex b/root/articles/mmmfs/references/adobe/text$bibtex
index fccef37..55904aa 100644
--- a/root/articles/mmmfs/references/adobe/text$bibtex
+++ b/root/articles/mmmfs/references/adobe/text$bibtex
@@ -3,6 +3,6 @@
   url = {https://www.theverge.com/2019/10/7/20904030/adobe-venezuela-photoshop-behance-us-sanctions},
   publisher = {The Verge},
   author = {Lee, Dami},
-  year = {2019},
+  year = {2019, October 7},
   visited = {2019-12-18},
 }
diff --git a/root/articles/mmmfs/references/linux-exec/text$bibtex b/root/articles/mmmfs/references/linux-exec/text$bibtex
index d514613..e0e415f 100644
--- a/root/articles/mmmfs/references/linux-exec/text$bibtex
+++ b/root/articles/mmmfs/references/linux-exec/text$bibtex
@@ -4,4 +4,5 @@
   publisher = {stackoverflow.com},
   note = {answered by osgx},
   visited = {2019-12-18},
+  year = 2014,
 }
diff --git a/root/articles/mmmfs/references/osx-files/text$bibtex b/root/articles/mmmfs/references/osx-files/text$bibtex
index f0b28cb..7c70a87 100644
--- a/root/articles/mmmfs/references/osx-files/text$bibtex
+++ b/root/articles/mmmfs/references/osx-files/text$bibtex
@@ -3,4 +3,5 @@
   url = {https://discussions.apple.com/thread/6740790},
   publisher = {Apple Communities},
   visited = {2019-12-27},
+  year = 2014,
 }
diff --git a/root/articles/mmmfs/references/renaming/text$bibtex b/root/articles/mmmfs/references/renaming/text$bibtex
index a4aa714..660bc2c 100644
--- a/root/articles/mmmfs/references/renaming/text$bibtex
+++ b/root/articles/mmmfs/references/renaming/text$bibtex
@@ -2,5 +2,6 @@
   title = {Why is it possible to convert a file just by renaming it?},
   url = {https://askubuntu.com/q/166602},
   publisher = {askubuntu.com},
+  year = 2012,
   visited = {2019-12-18},
 }
diff --git a/root/articles/mmmfs/references/wikipedia/text$bibtex b/root/articles/mmmfs/references/wikipedia/text$bibtex
index 0fa3437..d88d58c 100644
--- a/root/articles/mmmfs/references/wikipedia/text$bibtex
+++ b/root/articles/mmmfs/references/wikipedia/text$bibtex
@@ -3,4 +3,5 @@
   url = {https://en.wikipedia.org/wiki/Hyperlink#Wikis},
   publisher = {wikipedia.org},
   visited = {2019-12-18},
+  year = {n. d.},
 }
diff --git a/root/articles/mmmfs/table-of-contents/text$html+frag.html b/root/articles/mmmfs/table-of-contents/text$html+frag.html
index f349c1e..10004f0 100644
--- a/root/articles/mmmfs/table-of-contents/text$html+frag.html
+++ b/root/articles/mmmfs/table-of-contents/text$html+frag.html
@@ -49,10 +49,10 @@
           <li><a href="#33-content-transclusion">3.3 content transclusion</a></li>
           <li><a href="#34-end-user-programming">3.4 end-user programming</a></li>
       </ol>
-      <li><a href="#4-mmmfs">4. mmmfs</a></li>
+      <li><a href="#4-system-description">4. system description</a></li>
       <ol style="list-style: none;">
-          <li><a href="#41-the-fileder-unified-data-model">4.1 the fileder unified data model</a></li>
-          <li><a href="#42-the-type-system--coercion-engine">4.2 the type system & coercion engine</a></li>
+          <li><a href="#41-data-storage-model">4.1 data storage model</a></li>
+          <li><a href="#42-type-system-and-coercion-engine">4.2 type system and coercion engine</a></li>
       </ol>
       <li><a href="#5-example-use-cases">5. example use-cases</a></li>
       <ol style="list-style: none;">