UK Government Design System

Mikes Notes

The UK Government has created a design system for building accessible websites. There is a wealth of templates, components, tools, code and guidance on how to do this.

I am using this design system as a starting point for making the Pipi User Interface (UI) fully accessible.

Please note: This blog is for a technical audience and is to help Mike (me), who has synesthesia (that's why everything is colour-coded), keep notes and share them with collaborators. This blog is not intended to be accessible.

User Testing

Assume every person is unique and allow for personalisation. W3C WCAG 2.1 is the standard to aim for. Accessibility testing is underway in English for,

The current testing process steps are,

  1. Speak to groups of people and their organisations with everyday accessibility needs. Ask for volunteers.
  2. Watch and learn from people who volunteer with accessible needs. How do they find using a computer to visit and use a website? What are the problems? What works?
  3. Use personalised handmade web pages for volunteers to test.
  4. Configure the Content Management System (CMS) to generate the web UI automatically to meet the individual accessibility needs of logged-in users.

UK Gov Design System

The UK government's design principles and examples of their use.

  1. Start with user needs
  2. Do less
  3. Design with data
  4. Do the hard work to make it simple
  5. Iterate. Then iterate again
  6. This is for everyone
  7. Understand context
  8. Build digital services, not websites
  9. Be consistent, not uniform
  10. Make things open: it makes things better
The Design System components are reusable parts of the user interface that have been made to support various applications.

  • Accordion
  • Backlink
  • Breadcrumbs
  • Button
  • Character count
  • Checkboxes
  • Cookie banner
  • Date input
  • Details
  • Error message
  • Error summary
  • Exit this page
  • Fieldset
  • File upload
  • Footer
  • Header
  • Inset text
  • Notification banner
  • Pagination
  • Panel
  • Phase banner
  • Radios
  • Select
  • Skip link
  • Summary list
  • Table
  • Tabs
  • Tag
  • Task list
  • Text input
  • Textarea
  • Warning text
Patterns are best-practice design solutions for specific user-focused tasks and page types.

Ask users for…
  • Addresses
  • Bank details
  • Dates
  • Email addresses
  • Equality information
  • Gender or sex
  • Names
  • National Insurance numbers
  • Passwords
  • Payment card details
  • Telephone numbers
Help users to…
  • Check if a service is suitable
  • Check answers
  • Complete multiple tasks
  • Confirm a phone number
  • Confirm an email address
  • Contact a department or service team
  • Create a username
  • Create accounts
  • Exit a page quickly
  • Start using a service
  • Recover from validation errors
  • Confirmation pages
  • Cookies page
  • Page not found pages
  • There is a problem with the service pages
  • Question pages
  • Service unavailable pages
  • Step-by-step navigation

Free Posters

The UK Home Office has free Accessibility design posters (PDF).

Smashing Magazine


System Design

Mikes Notes

NK has a website and weekly email newsletter to teach system design. These are excellent resources and beautifully written with great diagrams. 

The System Design website gives architectural deep dives and system design fundamentals.

The weekly newsletter gives simplified case studies, curated valuable resources and a feed of recent posts.

Here is a recent selection of links to his articles that arrived in my inbox today.
A full list is here

Using ColdFusion as a Static Site Generator

Static site generators (SSGs) are engines that use text input files (such as Markdown, reStructuredText, AsciiDoc and JSON) to generate static web pages.

Static sites generated by static site generators do not require a backend after site generation, making them first-class citizens on content delivery networks (CDNs).

Some of the most popular static site generators are Jekyll, Hugo, Next.js (JavaScript) and Angular (TypeScript). SSGs are typically for rarely-changing, informative content, such as product pages, news websites, (software) documentation, manuals, and blogs.

Mikes Notes

Pipi also has its own static site generator (SSG).

Pipi 2

From 2000 to 2001, Pipi 2 used templates written in Visual Basic and stored in "Backpage", an Access Database, to render thousands of HTML web pages. I did the database design, Matthew Carter wrote the VB, and Graeme Cook gave helpful advice about MS Access. Many separate Access Databases store the data the templates use to create each page.

Pipi 4

From 2005 to 2008, Pipi4 used templates written in ColdFusion CFML code to render 25,000 static HTML pages from data stored in an MS SQL 6 database. Each week, on a Wednesday morning, it took 2 hours to render every page. The logic was stored in a library of 550 class objects.

The book "The Content Management Bible" by Bob Boiko was a great help to me in figuring out how to build the CMS and the rendering engine.

Pipi 9

Now, in Pipi 9, the Pipi 7 CMS has been rebuilt, and CFML templates have been added to automatically create a series of linked Wiki articles (like Wikipedia) that give an overview of each system and subsystem and a set of classically framed "PipiDocs" (a bit like JavaDocs) that drill into the minute detail of each system. 

The Wiki and Docs are also cross-linked. The next stage enables direct editing of the parameters of the underlying systems that the Wiki and Docs then self-document. A reverse loop of sorts.

During testing in October 2023, 1200 static Wiki web pages of 300 systems were rendered in 7 seconds. I was surprised by how fast it was. A significant 500x performance improvement on Pipi 4. 


The CFML templates are nested and use a rule engine to determine where, when and how they are used. As in Bob Boiko's book, I use content-type templates. In some ways, it's similar to Jekyll but much more powerful. CFML is straightforward to use and makes for fast prototyping.

The Data-Centric Revolution: Best Practices and Schools of Ontology Design

Mikes Notes
An excellent article on different schools of Ontology by Dave McComb, Co-founder of Semantic Arts. There is a list of articles by Dave here.
(Published on TDAN on December 20, 2023) 

I was recently asked to present “Enterprise Ontology Design and Implementation Best Practices” to a group of motivated ontologists and wanna-be ontologists. I was flattered to be asked, but I really had to pause for a bit. First, I’m kind of jaded by the term “best practices.” Usually, it’s just a summary of what everyone already does. It’s often sort of a “corporate common sense.” Occasionally, there is some real insight in the observations, and even rarer, there are best practices without being mainstream practices. I wanted to shoot for that latter category. 

As I reflected on a handful of best practices to present, it occurred to me that intelligent people may differ. We know this because on many of our projects, there are intelligent people and they often do differ. That got me to thinking: “Why do they differ?” What I came to was that there are really several different “schools of ontology design” within our profession. They are much like “schools of architectural design” or “schools of magic.” Each of those has their own tacit agreement as to what constitutes “best practice.”

Armed with that insight, I set out to identify the major schools of ontological design, and outline some of their main characteristics and consensus around “best practices.” The schools are (these are my made-up names, to the best of my knowledge none of them have planted a flag and named themselves — other than the last one ):

  • Philosophy School
  • Vocabulary and Taxonomy School
  • Relational School
  • Object-Oriented School
  • Standards School
  • Linked Data School
  • NLP/LLM School
  • Data-Centric School

There are a few well known ontologies that are a hybrid of more than one of these schools. For instance, most of the OBO Life Sciences ontologies are a hybrid of the Philosophy and Taxonomy School, I think this will make more sense after we describe each school individually.

Philosophy School

The philosophy school aims to ensure that all modeled concepts adhere to strict rules of logic and conform to a small number of well vetted primitive concepts.


The Basic Formal Ontology (BFO), DOLCE and Cyc are the best-known exemplars of this school.  Each has a set of philosophical primitives that all derived classes are meant to descend from. 

How to Recognize

It’s pretty easy to spot an ontology that was developed by someone from the philosophy school. The top-level classes will be abstract philosophical terms such as “occurrent” and “continuant.”

Best Practices

All new classes should be based on the philosophical primitives. You can pretty much measure the adherence to the school by counting the number of classes that are not direct descendants of the 30-40 base classes.

Vocabulary and Taxonomy School

The vocabulary and taxonomy school tends to start with a glossary of terms from the domain and establish what they mean (vocabulary school) and how these terms are hierarchically related to each other (taxonomy school). The two schools are more alike than different.

The taxonomy school especially tends to be based on standards that were created before the Web Ontology Language (OWL). These taxonomies often model a domain as hierarchical structures without defining what a link in the hierarchy actually means. As a result, they often mix sub-component and sub-class hierarchies.


Many life sciences ontologies, such as SNOMED are primarily taxonomy ontologies, and only secondarily philosophy school ontologies. Also, the Suggested Upper Merged Ontology is primarily a vocabulary ontology, it was mostly derived from WordNet and one of its biggest strengths is its cross reference to 250,000 words and their many word senses.

How to Recognize

Vast numbers of classes. There are often tens of thousands or hundreds of thousands of classes in these ontologies.

Best Practices

For the vocabulary and taxonomy schools, completeness is the holy grail. A good ontology is one that contains as many of the terms from the domain as possible. The Simple Knowledge Organization System (SKOS) was designed for taxonomies. Thus, even though it is implemented in OWL, it is designed to add semantics to taxonomies that often are less rigorous, using generic predicates such as broaderThan and narrowerThan rather than more precise subclass or object properties such as “part of.” SKOS is a good tool for integrating taxonomies with ontologies.

Relational School

Most data modelers grew up with relational design, and when they design ontologies, they rely on ways of thinking that served them well in relational.


These are mostly internally created ontologies.

How to Recognize

Relational ontologists tend to be very rigorous about putting specific domains and ranges on all their properties. Properties are almost never reused. All properties will have inverses. Restrictions will be subclass axioms, and you will often see restrictions with “min 0” cardinality, which doesn’t mean anything to an inference engine, but to a relational ontologist it means “optional cardinality.” You will also see “max 1” and “exactly 1” restrictions which almost never imply what the modeler thought, and as a result, it is rare for relational modelers to run a reasoner (they don’t like the implications).

Best Practices

For relational ontologist best practices are to make ontologies that are as similar to existing relational structures as possible. Often, the model is a direct map from an existing relational system.

Modelers in the relational school (as well as the object-oriented school coming up next) tend to bring the “Closed World Assumption” (CWA) with them from their previous experience. CWA takes a mostly implicit attitude that the information in the system is a complete representation of the world. The “Open World Assumption” (OWA) takes the opposite starting point: that the data in the system is a subset of all knowable information on the subject.

CWA was and is more appropriate in narrow scope, bounded applications. When we query your employee master file looking for “Dave McComb” and don’t get a hit, we reasonably assume that he is not an employee of your enterprise. When TSA queries their system and doesn’t get a hit, they don’t assume that he is not a terrorist. They still use the X-ray and metal detectors. This is because they believe that their information is incomplete. They are open worlders. More and more of our systems combine internal and external data in ways that are more likely to be incomplete.

There are techniques for closing the open world, but the relational school tends not to use them because they assume their world is already closed.

Object-Oriented School

Like the relational school, the object-oriented school comes from designers who grew up with object-oriented modeling. 


Again, a lot of object-oriented (OO) ontologies are internal client projects, but a few public ones of note include eCl@ss and eCl@ss is a standard for describing electrical products. It has been converted into an ontology. The ontology version has 60,000 classes, which combine taxonomic and OO style modeling. is an ontology for tagging web sites that Google promotes to normalize SEO. It started life fairly elegant. It now has 1300 classes, many of which are taxonomic distinctions, rather than real classes.

How to Recognize

One giveaway for the object-oriented school is designing in SHACL. SHACL is a semantic constraint language, which is quite useful as a guard for updates to a triple store. Because SHACL is less concerned with meaning and more concerned with structure, many object-oriented ontologists prefer it to OWL for defining their classes.

Even those who design in OWL have some characteristic tells. OO ontologists tend to use subclassing far more than relational ontologists. They tend to declare which class is a subclass of another, rather than allowing the inference engine to infer subsumption. There is also a tendency to believe that the superclass will constrain subclass membership. 

Best Practices

OO ontologies tend to co-exist with Graph QL and focus on json output. This is because the consuming applications are object oriented, and this style ontology and architecture have less impedance mismatch with the consuming applications. The level of detail tends to mirror the kind of detail you find in an application system. Best practices for an OO ontology would never consider the tens of thousands or hundreds of thousands of classes in a taxonomy ontology, nor would they go for the minimalist view of the philosophy or data-centric schools. They tend to make all distinctions at the class level.

Standards School

This is a Janus school, with two faces, one facing up and one facing down. The one facing down is concerned with building ontologies that others can (indeed should) reuse. The one facing up is the enterprise ontologies that import the standard ontologies in order to conform.


Many of the most popular ontology standards are produced and promoted by the W3C. These include DCAT (Data Catalog Vocabulary), the Ontology for Media Resources, Prov-O (an ontology of provenance), Time Ontology, and Dublin Core (an ontology for metadata, particular around library science).

How to Recognize

For the down facing standards ontology, it’s pretty easy. They are endorsed by some standards body. Most common are W3C, OMG and Oasis. ISO has been a bit late to this party, but we expect to see some soon. (Everyone uses the ISO country and currency codes, and yet there is no ISO ontology of countries or currencies.) There are also many domain-specific standard ontologies that are remakes of their previous message model standards, such as FHIR from HL7 in healthcare and ACORD in insurance.

The upward facing standards ontologies can be spotted by their importing a number of standard ontologies each meant to address an aspect of the problem at hand.

Best Practices

Best practice for downward facing standards ontologies is to be modular, fairly small, complete and standalone. Unfortunately, this best practice tends to result in modular ontologies that redefine (often inconsistently) shared concepts.

Best practice for upward facing standards ontologies is to rely as much as possible on ontologies defined elsewhere. This usually starts off by importing many ontologies and ends up with a number of bridges to the standards when it’s discovered that they are incompatible.

Linked Open Data School

The linked open data school promotes the idea of sharing identifiers across enterprises. Linked data is very focused on instance (individual or ABox) data, and only secondarily on classes.


The poster child for LOD is DBPedia, the LOD knowledge graph derived from the Wikipedia information boxes. It also includes the direct derivatives such as WikiData and the entire Linked Open Data Cloud.

I would put the Global Legal Entity Identifier Foundation (GLEIF) in this school as their primary focus is sharing between enterprises and there are more focused on the ABox (the instances).

How to Recognize

Linked open data ontologies are recognizable by their instances, often millions and in many cases billions of instances. The ontologies (TBox) is often very naïve, as they are often derived directly from informal classifications made by text editors in Wikipedia and its kin.

You will see many adhoc classes raised to the status of a formal class in LOD ontologies. I just notice the classes dbo:YearInSpaceFlight and yago:PsychologicalFeature100231001.

Best Practices

The first best practice (recognized more in the breach) is to rely on other organizations IRIs. This is often clumsy because historically, each organization invented identifiers for things in the world (their employees and vendors for instance) and they tend to build their IRIs around these well-known (at least locally) identifiers.

A second best practice is entity resolution and “owl:sameAs.” Entity resolution can determine if two IRIs represent the same real-world object. Once recognized, one of the organizations can choose to adopt the others IRI (previous paragraph best practice) or continue to use their own, but recognize the identity through owl:sameAs (which is mostly motivated by the following best practice).

LOD creates the opportunity for IRI resolution at the instance level. Put the DBPedia IRI for a famous person in your browser address bar and you will be redirected to DBPedia resolution page for that individual, showing all that DBPedia knows about them. For security reasons, most enterprises don’t yet do this. Because of this, another best practice is to only create triples with subjects whose domain name you control. Anything you state about a IRI in someone else’s name space will not be available for resolution by the organization that minted the subject URI.

NLP/LLM School

There is a school of ontology design that says turn ontology design over to the machines. It’s too hard anyway.


Most of these are also internal projects. About every two to three years, we see another startup with the premise that ontologies can be built by machines. For most of history, these were cleverly tailored NLP systems. The original works in this area took large teams of computational linguists to master.

This year (2023), they are all LLMs. You can ask ChatGPT to build an ontology for [fill in the blank] industry, and it will come up with something surprisingly credible looking.

How to Recognize

For LLMs, the first giveaway are hallucinations. These are hard to spot and require deep domain and ontology experience to pick out. The second clue is humans with six fingers (just kidding). There aren’t many publicly available LLM generated ontologies (or if there are they are so good we haven’t detected that they were machine generated).

Best Practices

Get a controlled set of documents that represent the domain you wish to model. This is better than relying on what ChatGPT learned by reading the internet.

And have a human in the loop. This is an approach that shows significant promise and several researchers have already created prototypes that utilize this approach. Consider that the NLP / LLM created artifacts are primarily speed reading or intelligent assistants for the ontologist.

In the broader adoption of LLMs, there is a lot of energy going into ways to use knowledge graphs as “guard rails” against some of LLMs excesses, and the value of keeping a human in the loop. Our immediate concern there are advocates of letting generative AI design ontologies, and as such it becomes a school of its own.

Data-Centric School

The data-centric school of ontology design, as promoted by Semantic Arts, focuses on ontologies that can be populated and implemented. In building architecture, they often say “It’s not architecture until it’s built.” The data-centric school says, “It’s not an ontology until it has been populated (with instance level, real world data, not just taxonomic tags).” The feedback loop of loading and querying the data is what validates the model.


Gist, an open-source owl ontology, is the exemplar data-centric ontology. SchemaApp, Morgan Stanley’s compliance graph, Broadridge’s Data Fabric, Procter & Gamble’s Material Safety graph, Schneider-Electric’s product catalog graph, Standard & Poor’s commodity graph, Sallie Mae’s Service Oriented Architecture and dozens of small firms’ enterprise ontologies are based on gist.

How to Recognize

Importing gist is a dead giveaway. Other telltale signs include a modest number of classes (less than 500 for almost all enterprises) and eschewing inverse and transitive properties (the overhead for these features in a large knowledge graph far outweigh their expressive power). Another giveaway is delegating taxonomic distinctions to be instances of subclasses of gist:Category rather than being classes in their own right.

Best Practices

One best practice is to have non primitive classes have “equivalent class” restrictions that define class membership and are used to infer the class hierarchy. Another best practice is to have domains and ranges at very high levels of abstraction (and often missing completely) in order to promote property reuse and reduce future refactoring.

Another best practice is to load a knowledge graph with data from the domain of discourse to prove that the model is appropriate and at the requisite level of detail.


One of the difficulties in getting wider spread adoption of ontologies and knowledge graphs is that if you recruit and/or assemble a group of ontologists, there is a very good chance you will have members from multiple of the above-described schools. There is a good chance they will have conflicting goals, and even a different definition of what “good” is. Often, they will not even realize that their difference of opinion is due to their being members of a different tribe.

There isn’t one of these schools that is better than any of the others for all purposes. They each grew up solving different problems and emphasizing different aspects of the problem.

When you look at existing ontologies, especially those that were created by communities, you’ll often find that many are an accidental hybrid of the above schools. This is caused by different members coming to the project from different schools and applying their own best practices to the design project.

Rather than try to pick which school is “best,” you should consider what the objectives of your ontology project are and use that to determine which school is better matched. Select ontologists and other team members who are willing to work to the style of that school. Only then is it appropriate to consider “best practices.”


I want to acknowledge Michael Debellis for several pages of input on an early draft of this paper. The bits that didn’t make it into this paper may surface in a subsequent paper. 

Mikes Notes

Pipi will be importing and digesting a lot of ontologies.
  • Run this list of "schools of thought" past the Ontolog Forum for comment
  • Treat these schools as types
  • Use the types to catalogue and then guide the ontology import process

Essential Life-Learnings from 14 Years of Brain Pickings

Copied from here 



UPDATE 2021: Thoughts on growth and self-discovery in becoming The Marginalian — after 15 years, Brain Pickings reborn.

Brain Pickings* was born on October 23, 2006, as a short email to seven friends. Seven years and several incomprehensible million readers into its existence, I began what has since become an annual tradition — a distillation of the most important things I have learned about living while reading and writing my way through life; private learnings offered in the public commons, in the hope that these thoroughly subjective insights of a single consciousness might be of succor or salve to another. It is the only overtly personal writing I do on Brain Pickings. (Though, of course, the whole of it remains a deeply personal exercise in processing my own life and annealing my own ideas through the lives and ideas I celebrate in writing.) We are, after all, made of the same stuff.

Part of the Milky Way, from a study made between 1874 and 1876

One of Étienne Léopold Trouvelot’s pioneering 19th-century astronomical paintings. (Available as a print and as a face mask, benefiting the endeavor to build New York City’s first public observatory.)

Each year, I have drawn one new learning from that particular season of life. Each year, it has swelled into an existential challenge to prune the vastness, the lushness, the interleaved complexity of experience into a single blade of simple but not simplistic insight into the nature of life, glimpsed from the solitary pinhole of this one life. The challenge has never been more colossal than this past year — the most trying I have lived through, by orders of magnitude. Depression has lowered its leaden cloudscape over me again and again since I was fifteen, but no other year has lidded life more ominously, as the staggering collective grief we are living through together densified the black fog of private loss. In such seasons of life, one is pressed against the limits of one’s being, pressed eventually against the understanding — no, more than understanding and less than understanding: the blind elemental fact — that no matter the outer atmosphere of circumstance, one must lift the inner cloudscape by one’s own efforts, or perish under it.

I chose, by that blind instinct of survivalism we mistake for choice, to lift.

Art by Dorothy Lathrop, 1922. (Available as a print and as stationery cards.)

Against this contextual backdrop, here is the central learning drawn from a year so discomposing yet so vital and transformative a verse from the poetry of life. (You can read the previous thirteen here.)

14. Choose joy. Choose it like a child chooses the shoe to put on the right foot, the crayon to paint a sky. Choose it at first consciously, effortfully, pressing against the weight of a world heavy with reasons for sorrow, restless with need for action. Feel the sorrow, take the action, but keep pressing the weight of joy against it all, until it becomes mindless, automated, like gravity pulling the stream down its course; until it becomes an inner law of nature. If Viktor Frankl can exclaim “yes to life, in spite of everything!” — and what an everything he lived through — then so can any one of us amid the rubble of our plans, so trifling by comparison. Joy is not a function of a life free of friction and frustration, but a function of focus — an inner elevation by the fulcrum of choice. So often, it is a matter of attending to what Hermann Hesse called, as the world was about to come unworlded by its first global war, “the little joys”; so often, those are the slender threads of which we weave the lifeline that saves us.

Delight in the age-salted man on the street corner waiting for the light to change, his age-salted dog beside him, each inclined toward the other with the angular subtlety of absolute devotion.

Delight in the little girl zooming past you on her little bicycle, this fierce emissary of the future, rainbow tassels waving from her handlebars and a hundred beaded braids spilling from her golden helmet.

Delight in the snail taking an afternoon to traverse the abyssal crack in the sidewalk for the sake of pasturing on a single blade of grass.

Delight in the tiny new leaf, so shy and so shamelessly lush, unfurling from the crooked stem of the parched geranium.

I think often of this verse from Jane Hirshfield’s splendid poem “The Weighing”

So few grains of happiness
measured against all the dark
and still the scales balance.

Yes, except we furnish both the grains and the scales. I alone can weigh the blue of my sky, you of yours.

UPDATE 2021: After 15 years, Brain Pickings was reborn as The Marginalian, with some thoughts on self-discovery and self-reinvention across a lifetime.

Model Driven User Interfaces

In 2023, putting a User Interface (UI) on the front end of Pipi 9 has been challenging. I wanted it to be

  • Model-driven
  • Adaptive to the users' device
  • Automated
  • Meet the individual needs of each logged-on user

Resources used


Interaction Flow Modelling Language (IFML) is an abstract user interface (AUI) modelling language adopted as a standard by the OMG in March 2013. IFML supports;
  • UI general structure
  • Content
  • Events
  • Event handlers
  • I/O parameters bound to specific view components

CAMELEON Reference Framework (CRF)

The FP5 CAMELEON (Context Aware Modeling for Enabling and Leveraging Effective interactiON) project was carried out by a consortium of universities and research groups in the EU from about 2000-2010?? CHAMELEON has three layers: Abstract UI, Concrete UI and Final UI.


User Interface Description Language (UIDL) examples include
  • Maria XML
  • usiXML
  • UIML
  • XUL
  • XAML
  • WasabiXML

W3C Model-based UI Incubator

Architectural Decisions

  • The USI engine is in charge
  • Use Workflow Patterns to describe/breakdown tasks
  • Use IFML to describe the AUI layer
  • Keep the usiXML version of CUI and FUI layers
  • Use Open-sourced UI Component Libraries to  populate CUI and FUI
  • I added two more layers: a Locale UI and a Personalisation UI.
  • The UI generator process is DDD > Wfl > AUI > CUI > FUI > LUI > PUI
  • CAMELEON was initially meant to run both ways. I made it generative only, driven by DDD workflows.
  • Use Design Tokens with a CCS framework to make "look" highly tweakable.

Current Status

  • All the different layers work independently but don't work together.
  • Initial user testing is with hand-built web pages.
  • HTML 4 and HTML 5 will be the initial output.
  • Once basic assumptions have been tested and corrected, live pages will be produced for testing, working backwards from PUI to AUI.
  • I'm using the namespace engine (NSP) to reorganise the 30+ internal systems of the USI engine into compartments.

User Testing

Assuming every person is unique, allowing for personalisation. W3C WCAG 2.1 is the standard. Accessibility testing is underway in English for

  • Braille Devices for the Deaf-Blind
  • Screen Readers
  • Screen Magnifiers
  • Low Vision
  • Irlen's
  • Colour Blindness
  • Dyslexia
  • Autism
  • Epilepsy
  • Synethesia
  • Older adults requiring simpler UI
  • Muscular Dystrophy (large buttons)

How to deal with parameters for whole-cell modelling

Mikes Notes

Pipi has thousands of parameters. The parameters constitute a significant challenge to finely adjust for desired system-level emergent properties.

How to Deal With Parameters for Whole-Cell Modelling is a paper published in 2017 in the Journal of the Royal Society. I found the paper listed in the publications from the Theoretical Systems Biology Group at Melbourne University led by Prof. Michael Stumpf. They are dealing with the same issues. This Research Group could be a great resource.


Most models in cell biology are either based on simple networks or stoichiometric metabolic models, or deal only with small pathways. Ultimately we will require models of whole cells. We are interested in combining approaches from text-mining, bioinformatics, comparative genomics, statistical inference, machine learning, and mathematical modelling to arrive at models for whole cells. In the first instance, we are focusing on bacteria.

Ultimately such models are 

  1. the most stringent test of our understanding; and 
  2. an essential prerequisite for applying rational design and engineering approaches to biological systems. Maintaining the balance of model complexity to explanatory power is a conceptually hugely exciting problem, and tackling parameter inference for thousands of parameters is technically equally exciting.

Representative Publications

Incorporating languages for i18n

One of the significant challenges this year was enabling any language or writing system (script) to be used by the Pipi 9 Content Management System (CMS).

The decision was made to alter the architecture to save future rework even though English will be the only language available initially.

Some of the critical resources used were

Unicode Consortium

The Unicode Consortium describes its overall purpose as:

...enabling people around the world to use computers in any language by providing freely available specifications and data to form the foundation for software internationalization in all major operating systems, search engines, applications, and the World Wide Web. An essential part of this purpose is to standardize, maintain, educate and engage academic and scientific communities and the general public about, make publicly available, promote, and disseminate to the public a standard character encoding that provides for an allocation for more than a million characters.


UTF-8 is able to store every character from every writing system so Pipi uses UTF-8. Each writing system gets a 4-character code. 1000 spots are available. About 178 scripts are listed so far, with many more being added.

For example, Latn is the 4-character code for the Latin Alphabet.


The Common Locale Data Repository (CLDR) is a project of the Unicode Consortium to provide locale data in XML format for use in computer applications. CLDR contains locale-specific information that an operating system will typically provide to applications. CLDR is written in the Locale Data Markup Language (LDML).

Among the types of data that CLDR includes are the following:

  • Translations for language names
  • Translations for territory and country names
  • Translations for currency names, including singular/plural modifications
  • Translations for weekday, month, era, and period of the day, in full and abbreviated forms
  • Translations for time zones and example cities (or similar) for time zones
  • Translations for calendar fields
  • Patterns for formatting/parsing dates or times of day
  • Exemplar sets of characters used for writing the language
  • Patterns for formatting/parsing numbers
  • Rules for language-adapted collation
  • Rules for spelling out numbers as words
  • Rules for formatting numbers in traditional numeral systems (such as Roman and Armenian numerals)
  • Rules for transliteration between scripts, much of it based on BGN/PCGN romanisation

The information is currently used in International Components for Unicode, Apple's macOS, LibreOffice, MediaWiki, and IBM's AIX, among other applications and operating systems.

SIL International

ISO 639-3, maintained by SIL International, is a list of 7,000 + languages described by 3-letter language codes.

For example, eng is the code for English.


An IETF BCP 47 language tag is a standardized code or tag used to identify human languages on the Internet (a language code). The tag structure has been standardized by the Internet Engineering Task Force (IETF) in Best Current Practice (BCP) 47; the subtags are maintained by the IANA Language Subtag Registry.

To distinguish language variants for countries, regions, or writing systems (scripts), IETF language tags combine subtags from other standards such as ISO 639, ISO 15924, ISO 3166-1 and UN M.49. For example, the tag "en" stands for English; "es-419" for Latin American Spanish; "rm-sursilv" for Romansh Sursilvan; "sr-Cyrl" for Serbian written in Cyrillic script; "nan-Hant-TW" for Min Nan Chinese using traditional Han characters, as spoken in Taiwan; and "gsw-u-sd-chzh" for Zürich German. In accordance with ISO 639-3, however, it does not provide codes for distinguishing between Arabic-based scripts and maintains two duplicate codes for Punjabi, as well as a number of dubious or non-existent language distinctions made by its parent's standard.

It is used by computing standards such as HTTP, HTML, XML and PNG.


Simple examples include
  • en-NZ
  • en-US
  • en-UK

IANA Language Subtag Registry 

W3C Internationalisation

Language Strings

The initial experiment used string sets from the Media Wiki translation effort

  • English (4,000+ strings)
  • French (4,000+ strings)
  • Spanish (4,000+ strings)
  • German (4,000+ strings)
  • Paiwan (Taiwan) (600+ strings)
  • Abkhazian (Abkhazia) (425 strings)
  • Maori (New Zealand) (128 strings)

Other sources of string libraries so far discovered 

Examples of some standard UI strings;
  • Login
  • Logout
  • Username
  • Password
  • Help
  • File
  • Edit
  • Forgot password
  • Change password
  • Save
  • Delete

Translating help documents, the actual content, and scientific terms is a much bigger problem and will require a different solution.

Architecture Decisions

  • The underlying master language is English.
  • The Locale user interface (LUI) engine is responsible.
  • Subsystems include Region, Language, Script, Calendar, UOM, Person Naming, Strings, etc.
  • LUI is automatically updated by Unicode, CLDR, ISO 693-3, and IANA Language Subtag Registry, etc.
  • Strings are stored in a database structure mapped to the English string.
  • At render time, strings are substituted to create code or static web pages in a particular language and script.
  • Some sort of translation process by volunteers will eventually become necessary.
  • Expect these assumptions to change a lot following experimental evidence.