GIS mapping options

Mike's Notes

Some thoughts about adding Geographic Information Systems (GIS) mapping to Pipi 10, the next major release of Pipi.

Spacetime

An unresolved issue is how to integrate GIS with 4D spacetime. See the work of Ontologists Chris Partridge on BORO and NATO, and Matthew West on 4Dism, Shell Oil Refineries, and the Ontological foundations behind the UK Digital Twin Project for Built Infrastructure. Chris Partridge also raised a related question in the Ontolog Forum recently.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

09/02/2026

GIS mapping options

By: Mike Peters
On a Sandy Beach: 08/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Pipi 4 (2005-2008)

NZERN, with the help of Parker Jones at Eagle Technology, secured an ESRI Conservation GIS grant to add GIS mapping capabilities.

I gave a live demo and presentation of Pipi 4 at an NZ ESRI User Conference held in Wellington. The head of engineering at ESRI was in the audience. In a few weeks, over NZ$600,000 worth of ESRI software was on its way.

ESRI gave us everything they had. Multiple (up to 10) licenses at version 8.2

  • ArcIMS
  • ArcSDE
  • Workstation
  • All the extensions.
  • Everything!
There was so much boxed software that it came on a pallet.

The plan was to provide free, dedicated, and customised web map hosting for every conservation project in NZ that wanted it. The smallest mapped project was 1500 sq m, scaling up to large landscape-scale, whole catchment projects. Every project was different, so the provided GIS was customised to meet their needs. There was even a visit by an ESRI staff member who proposed enabling NZERN to extend this to conservation efforts in the Pacific Island states, by providing training using ESRI-supplied laptops.

I got to create all the GeoDatabases and hack JTX to run in reverse to manage user map-edits history.

It was going very well, and many individual projects were getting dedicated dynamic web maps with all their data and GIS layers. All labour was donated (Ten thousand hours). 

QE2 National Trust and other national conservation-related organisations were also interested in using this shared GIS system.

Then the government funding that covered the core annual running costs dried up.

Core costs included;

  • Power
  • Bandwidth
  • Hardware
  • Repairs
  • Software books

Then the Key government came in, followed by the Christchurch Earthquake.
What a waste of opportunity for conservation.

After that, governments love to reinvent the wheel, so there have been many well-funded attempts to develop GIS for biodiversity/stream health for community use in NZ. None of them has been as good as Pipi, and most of them disappear after a while. So we are going to do something about that, except it will be available globally in many human languages, across many industries, and will use open-source GIS software.

Parker Jones, with Bonita, went on to create a GIS for Conservation organisation in NZ, and has done a great job. All power to them.

Pipi 9 (2023 - )

GIS Plugins include

  • Apple Map
  • ArcGIS Map
  • Azure Map
  • Google Map

Pipi 10

Customers will be able to integrate Pipi with their own ESRI GIS account deployments. Pipi GIS will use OGC standards. I have to say here that I love ESRI software, and the Eagle Technology people were great, but it is far too expensive and restrictive for this social-enterprise startup.

Options

Use open-source; it's free, and DIY everything.

Default Option

  • QGIS
  • GeoServer 3
  • GeoNode
  • PostGIS + PostgreSQL

Open Geospatial Consortium (OGC) 

These products are mature and conform to the OGC standards.

Geospatial Libraries

  • FDO – API (C++, .Net) between GIS application and sources; for manipulating, defining and analysing geospatial data.
  • GDAL/OGR – Library between GIS applications and sources; for reading and writing raster geospatial data formats (GDAL) and simple features vector data (OGR).
  • GeoTools – Open source GIS toolkit (Java); to enable the creation of interactive geographic visualization clients.
  • GEOS – A C++ port of the Java Topology Suite (JTS), a geometry model.
  • MetaCRS – Projections and coordinate system technologies, including PROJ.
  • Orfeo ToolBox (OTB) – Open source tools to process satellite images and extract information.
  • OSSIM: Extensive geospatial image processing libraries with support for satellite and aerial sensors and common image formats.
  • PostGIS – Spatial extensions for the PostgreSQL database, enabling geospatial queries.

Desktop Applications

  • QGIS – Desktop GIS for data viewing, editing and analysis — Windows, Mac and Linux.
  • GRASS GIS – an extensible GIS for image processing and analysing raster, topological vector and graphic data.
  • OSSIM – Libraries and applications used to process imagery, maps, terrain, and vector data.
  • Marble – Virtual globe and world atlas.
  • gvSIG – Desktop GIS for data capturing, storing, handling, analysing and deploying. Includes map editing.
  • uDIG - 

Web Mapping Server

  • MapServer – Fast web mapping engine for publishing spatial data and services on the web; written in C.
  • Geomajas – Development software for web-based and cloud-based GIS applications.
  • GeoServer – Allows users to share and edit geospatial data. Written in Java using GeoTools.
  • deegree – Java framework
  • PyWPS – implementation of the OGC Web Processing Service standard, using Python
  • pygeoapi - A Python server implementation of the OGC API suite of standards for geospatial data.

Web Mapping Client

  • GeoMoose – JavaScript Framework for displaying distributed GIS data.
  • Mapbender – Framework to display, overlay, edit and manage distributed Web Map Services using PHP and JavaScript.
  • MapGuide Open Source – Platform for developing and deploying web mapping applications and geospatial web services. Windows-based, native file format.
  • MapFish – Framework for building rich web-mapping applications based on the Pylons Python web framework.
  • OpenLayers – an AJAX library (API) for accessing geographic data layers of all kinds.

Hosting

The GeoServer and PostGIS + PostgreSQL Geodatabase will need to be deployed in the Pipi Data Centre and used by the spatial agent engine. Providing hosted GIS to customers will require Ajabbi to purchase or lease bare-metal servers to host open-source GIS Web Servers.

GeoServer 3 will be available in Docker. All doable.

Support

Sponsor open-source and pay for support from GeoSolutions, etc.

By , No comments:
Tags ,

Using Google Blogger API v3

Mike's Notes

On a Sandy Beach is a publication of Ajabbi Research.

Changes needed

Enable other people at Ajabbi Research to also contribute to On a Sandy Beach using the Workspaces for Research UI.

It looks very straightforward. This job will be done once the Workspaces for Research are available for researchers to use.

Preparation

Last year, all existing blog posts were reformatted.

New setup

The Pipi CMS Engine (cms) will format, store in a database, and export content to On a Sandy Beach, hosted on Google Blogger, using the Blogger API ver 3.

Either XML/Atom or JSON can be used.

Steps

  1. Import the existing blog posts into the CMS Engine via the Blogger API
  2. Reformat every post (see 4th resource link below)
  3. Store in the CMS database
  4. Render posts
  5. Export back to Blogger via the Blogger API.
  6. All future posts will be created by a human using a workspace, transferred to the CMS Engine, processed, and then published to Google Blogger.

Notes

Here are some initial notes taken from the Google Blogger API documentation and other sites, tweaked using Gemini and rewritten by Grammarly.

These notes will be presented using slides at tomorrow night's online Open Research Group meeting.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

09/02/2026

Using Google Blogger API v3

By: Mike Peters
On a Sandy Beach: 07/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Blogger supports manual import and export of blog content via the Blogger dashboard or the Blogger API. The export file format for both methods is Atom, an XML-based format that includes all posts and comments. 

Blogger API for Import/Export

Developers can use the Blogger API (v3 is the current version) to programmatically manage blog content. The export file generated via the manual process uses the same Atom format as the API's feed requests. 

Key Points for API Use

  • Authentication: All operations for private data (including import/export) require authentication, typically using OAuth 2.0.
  • Format: The API uses REST APIs and JSON for standard operations. The specific import/export functions rely on the raw XML/Atom format described in the developer guides.
  • Functionality: The API allows retrieving, creating, updating, and deleting posts, comments, and pages, enabling the creation of custom import/export tools. For example, you can use API clients for Python, Java, or Node.js to manage content programmatically.
  • Custom Import Scripts: Developers can write scripts (e.g., in PHP or Python) to import content from other sources into Blogger via the API, which involves parsing the source data and making POST requests to Blogger API endpoints. 

For detailed API documentation, refer to the Blogger API Developer site.

REST

The Blogger API is a RESTful interface provided by Google that allows developers to integrate Blogger content and functionality into their own applications. It enables programmatic access to resources such as blogs, posts, comments, pages, and users via HTTP requests and JSON. 

Key Features and Concepts

  • Resources: The API revolves around five core resource types:
    • Blogs: The central container for all content and metadata.
    • Posts: The primary published content items, meant to be timely.
    • Comments: User reactions to specific posts.
    • Pages: Static content (e.g., about me, contact info).
    • Users: Represents a non-anonymous person interacting with Blogger, as an author, admin, or reader.
  • Operations: Developers can perform various operations on these resources, including list, get, insert (create), update, patch, and delete.
  • Authentication:
    • Public Data: Requests for public data (e.g., retrieving a public blog post) only require an API key.
    • Private Data: Operations involving private user data (e.g., creating a post, editing a comment) must be authorised using OAuth 2.0 tokens.
  • API Version: The latest recommended version is Blogger API v3. Support for the older v2.0 API ended on September 30, 2024, so applications must be updated to continue functioning. 

How to Access the API

Google recommends using their client libraries, which handle much of the authorisation and request/response processing for you. Libraries are available for a variety of programming languages: 

  • Go
  • Java (get started with the Java client library)
  • JavaScript
  • .NET (install the Google APIs NuGet package)
  • Node.js
  • PHP
  • Python (install the client library using pip install google-api-python-client)
  • Ruby 

Alternatively, you can interact with the API directly using RESTful HTTP requests. The Google APIs Explorer tool lets you test API calls in your browser. 

  • Pipi API Engine (api)  using CFML
  • BoxLang API using BX

For full documentation and developer guides, visit the official Blogger API documentation site on Google for Developers. 

Older Data API (v1/v2) Format: Atom XML 

The previous versions of the Blogger API relied heavily on the Atom Publishing Protocol (AtomPub) and Google Data API feeds for managing blog content. The API used standard HTTP methods (GET, POST, PUT, DELETE) to transport Atom-formatted XML payloads. 

Important: Support for the v2.0 Google Data API ended on September 30th, 2024, so applications must use the latest version to continue functioning. 

Exporting and Accessing Feeds via XML

Blogger still uses Atom XML for blog syndication and content backup: 

  • Public Blog Feed: Every Blogger blog has a public Atom feed, typically at an address like yourblogname.blogspot.com/feeds/posts/default or://yourblogname.blogspot.com.
  • Content Backup: Users can back up their blog's posts and comments as a single .xml file from the Blogger dashboard.

    • Sign in to Blogger.
    • Select your blog.
    • Go to Settings > Manage Blog.
    • Click Back up content and Download XML file. 
    • This downloaded file is in a specific Atom format for import and export. 

REST in the Blogger API

The supported Blogger operations map directly to REST HTTP verbs, as described in Blogger API operations.

The specific format for Blogger API URIs are:

  • https://www.googleapis.com/blogger/v3/users/userId
  • https://www.googleapis.com/blogger/v3/users/self
  • https://www.googleapis.com/blogger/v3/users/userId/blogs
  • https://www.googleapis.com/blogger/v3/users/self/blogs
  • https://www.googleapis.com/blogger/v3/blogs/blogId
  • https://www.googleapis.com/blogger/v3/blogs/byurl
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/bypath
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/search
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId/comments
  • https://www.googleapis.com/blogger/v3/blogs/blogId/posts/postId/comments/commentId
  • https://www.googleapis.com/blogger/v3/blogs/blogId/pages
  • https://www.googleapis.com/blogger/v3/blogs/blogId/pages/pageId

The full explanation of the URIs used and the results for each supported operation in the API is summarised in the Blogger API Reference document.

Examples

List the blogs that the authenticated user has access rights to:

  • GET https://www.googleapis.com/blogger/v3/users/self/blogs?key=YOUR-API-KEY

Get the posts on the code.blogger.com blog, which has blog ID 3213900:

  • GET https://www.googleapis.com/blogger/v3/blogs/3213900?key=YOUR-API-KEY

REST from JavaScript

You can invoke the Blogger API from JavaScript using the callback query parameter and a callback function. When the browser loads the script, the callback function is executed, and the response is passed to it. This approach allows you to write rich applications that display Blogger data without requiring server-side code.

The following example retrieves a post from the code.blogger.com blog, after you replace YOUR-API-KEY with your API key.

<html>
  <head>
    <title>Blogger API Example</title>
  </head>
  <body>
    <div id="content"></div>
    <script>
      function handleResponse(response) {
        document.getElementById("content").innerHTML += "<h1>" + response.title + "</h1>" + response.content;
      }
    </script>
    <script     src="https://www.googleapis.com/blogger/v3/blogs/3213900/posts/8398240586497962757?callback=handleResponse&key=YOUR-API-KEY"></script>
  </body>
</html>

Data format

JSON (JavaScript Object Notation) is a common, language-independent data format that provides a simple text representation of arbitrary data structures. For more information, see json.org.

Blogger API operations

You can invoke a number of different methods on collections and resources in the Blogger API, as described in the following table.

Operation Description REST HTTP mappings
list Lists all resources within a collection. GET on a collection URI.
get Gets a specific resource. GET on a resource URI.
getByUrl Gets a resource, looking it up by URL. GET with the URL passed in as a parameter.
getByPath Gets a resource by looking it up by its path. GET with the Path passed in as a parameter.
listByUser Lists resources owned by a User. GET on a user owned collection.
search Search for resources, based on a query parameter. GET on a Search URL, with the query passed in as a parameter.
insert Create a resource in a collection. POST on a collection URI.
delete Deletes a resource. DELETE on a resource URI.
patch Update a resource, using Patch semantics. PATCH on a resource URI.
update Update a resource. PUT on a resource URI.

The table below shows which methods are supported by each resource type. All list and get operations on private blogs require authentication.

Resource Type Supported Methods
list get getByUrl getByPath listByUser search insert delete patch update
Blogs N Y Y N Y N N N N N
Posts Y Y N Y N Y Y Y Y Y
Comments Y Y N N N N N N N N
Pages Y Y N N N N N N N N
Users N Y N N N N N N N N
By , No comments:
Tags , , , , ,

The Workspace Issue

Mike's Notes

This is a copy of the January issue of Ajabbi Research.

It is a historical overview of the effort to create a workspace-based UI for Pipi.

Ajabbi Research is published on SubStack on the first Friday of each month, and subscriptions are free.

Each issue is a broad historical overview of a research topic, serving as an index to dozens of previously posted related articles. There are now over 600 articles/posts.

This copy of the issue will be updated with additional information as it becomes available. Check the Last Updated date given below.

Eventually, each issue will be reused on the separate Ajabbi Research website as an introduction to a research area comprising multiple research projects.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

31/03/2026

The Workspace Issue

By: Mike Peters
Ajabbi Research: 02/01/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

This is the story of how Pipi got a workspace-based User Interface (UI). The steps taken have been part of Pipi's development since 2007, spanning 5 versions.

The NZERN Pipi 2003-2005 Development Plan started it all.

Pipi 4 (2005-2008)

The story starts with Pipi 4. It was a big, successful system that supported community-driven Ecological Restoration in NZ. Here is a history of that Pipi version.

Due to very rapid scaling, a no-code approach was required to build the UI.

NetSuite was the original inspiration. A database-based framework was constructed to store user interface components, and another database to store the information being displayed and edited.

Recently, an archive of Pipi 4 help documentation was discovered and is now available for viewing. It is incomplete, but it gives an idea of how it worked.

Pipi 6 (2017-2019)

When Pipi was rebuilt from memory, the monolithic architecture was refactored into loosely coupled modules. Many new modules were created to support a rich UI. Each module had its own database.

Pipi 7 (2020)

Pipi was converted to microservices. Pipi could self-document. Static HTML mockups of workspaces were created as experiments. They were generic and could be applied to any subject domain, e.g., space, health, film, or experiments.

Pipi 8 (2021-2022)

System-wide namespaces were introduced, making Pipi headless, and the microservices were converted into autonomous agents (Engines). Self-documentation broke as a result.

More agents were created to manage each other. Some were merged, and others split. These agents are large, with 10,000 lines of code common, and they maintain internal, complex databases, messaging, and workflows, all of which maintain state. None of them is stateless.

Pipi 9 (2023-2026)

Many of the internal engines were aggregated into complex systems. Some contained up to 20 different engines, all operating independently and interacting. These systems were then combined into more extensive systems, etc. So far, there are 300+ different engines (with multiple copies), and Pipi 9 has emerged.

Key problems needed to be solved to enable a workspace-based UI to emerge from Pipi. These included;

  • Ontology-driven constraints
  • Domain modelling
  • Model-driven UI to provide automatic accessibility
  • Self-documenting
  • Structured learning
  • i18n for every human language and writing system.
  • Design system
  • Security and permissions
  • Useful URL patterns
  • Naming conventions
  • Ribbon menu

Ontology-driven constraints

The Ontolog Forum was a great help. BORO was hacked to run in reverse. This drives the system-wide constraints. The BORO Engine (bor) can also autonomously run forward if needed, similar to the KREB's cycle. This means ontologies can be imported into Pipi by the Ontology Engine (ont) to help provide world models based on primitives supplied by the Physical Law Engine (plw).

In the Reductionist System (red), the Domain Engine (dmn) and Module Engine (mod) create data models using Domain-Driven Design (DDD) from ontologies.

Model-driven UI

The User Interface Description Language (UIDL) was an EU-funded project that was abandoned in 2010 after 10 years of excellent work. It was to enable accessibility on different screens and devices. The research results were reverse-engineered to build a User Interface Engine (usi) that would run in reverse to generate accessibility solutions for Pipi. The CSS Engine (css) replaced some redundant components of the UIDL project. Additional engines for localisation and personalisation were created.

Self-documenting

With the help of Alex Shkotin from the Ontolog Forum, templates were designed for the Wiki Engine (wik) and Docs Engine (doc) to automatically populate and generate system documentation from hundreds of agents and thousands of processes. There are some test examples to look at.

Structured learning

IEEE Learning Objects were an inspiration for the Learning Object Engine (lob). This engine was used to structure learning materials using Diataxis to address users' diverse learning needs. The Help Engine (hlp) takes the same material to provide in-context help in the UI.

i18n for every human language and writing system

Using SIL and Unicode naming conventions, the Language Engine (lng) stores UI translations in multiple languages and writing systems, enabling Pipi capable of supporting all 7,000 known languages. Then the Locale User Interface Engine (lui) creates localised UI.

Design System

A Design System Engine (dsg) was built to handle multiple design systems, including a default one for the initial workspace UI. The design system includes UI components and design tokens.

Security and permissions

Role-based Access Control (RBAC) was implemented to manage security and user permissions. This applies to different types of user accounts and to finer-grained access.

Useful URL patterns

Clear URL patterns were established.

Naming conventions

A naming convention was adopted for output directories and filenames based on simple predictive rules.

Ribbon menu

A ribbon navigation menu (Tab Group) outline was created that could also be a non-ribbon navigation. One source, many formats.

Workspace Version 1 (October - November 2025)

A roadmap was first created to provide focus and clarity.

Batch processes created 15,000 files and directories to form workspaces containing static HTML web pages for testing. Each workspace had a ribbon menu and used iframes to organise navigation and content. Testing is successful.

The  industry-based enterprise workspaces created for testing were:

The Workspace Version 1 trial revealed that the UI is a thin wrapper around Pipi.

Workspace Version 2 (April 2026)

Changes to Workspace Version 2 include;

Additional role-based user account types were added.

Changes to the workspace engine model.

Changes to deployment naming convention.

Documentation for standard Enterprise workspaces.

Documentation for customer support.

Documentation for account settings.

Documentation for Developer Account.

Documentation for Agent Account.

The Render Engine (rnd) then uses a database to create workspaces made of static HTML web pages.

  • Test
  • Feedback
Setting up data centre automation has revealed that workspace deployments need to be performed in this order of account types due to the permissions cascade.
  • Agent Accounts (to admin Pipi)
  • Researcher Accounts (to edit UoM, ontologies and physical laws)
  • Developer Accounts (to create enterprise workspaces)
  • Personal Accounts (to sort out personal profiles - UI fonts, etc)
  • Enterprise Accounts (to test and use the system for work)
  • etc

Workspace Version 3 (May 2026)

The Render Engine (rnd) uses a database to generate workspace ribbon menus as static HTML web pages.

  • Test
  • Feedback

Workspace Version 4 (June 2026)

The Render Engine (rnd), Learning Object Engine (lob) and Help Engine (hlp) use databases to generate workspace user in-context documentation as static HTML web pages.

  • Test
  • Feedback

Workspace Version 5 (July 2026)

The Render Engine (rnd) and Form Engine (frm) use databases to generate workspace forms as static HTML web pages. See the Pipi 4 example, which will also be used here.

Workspace Version 6

The Render Engine (rnd), Form Engine (frm) and Docs Engine (doc) use databases to generate a complete HTML workspace demo with connected initial developer documentation rendered without errors.

  • Test
  • Feedback

Workspaces for Pipi & Developers

Working Workspaces for System Admin and DevOps use are deployed in the Pipi Core Data Centre. This will speed up development and production x10.

Then

The process of providing cloud workspaces for customers will begin.

Whaikaha Access Activator

An application to attend the 8-week Whaikaha Access Activator 2026 May intake is being submitted to kick this off. Using the Govt.UK Design System as an example, a simple paper-based process to design and test workable UI templates for;

  • Autism
  • Colour-blind
  • Irlen
  • Dyslexia
  • Physical or Motor Disability
  • Epilepsy
Blind and deaf folks will be catered for with later separate projects.

By , No comments:
Tags , ,

How Intel Gave Stephen Hawking a Voice

Mike's Notes

I hope that Pipi CMS can provide an AAC (picture language) interface as one of its accessibility options.

…we have a moral duty to remove the barriers to participation, and to invest sufficient funding and expertise to unlock the vast potential of people with disabilities. - Stephen Hawking

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subject > Accessibility
  • Home > Handbook > 

Last Updated

05/02/2026

How Intel Gave Stephen Hawking a Voice

By: João Medeiros
Wired: 13/01/2015

João Medeiros is Features Director for Wired magazine. He was born in Portugal, and came to the UK at eighteen. He has a PhD in theoretical physics at Imperial College. He has written widely for publications including The Economist, GQ and Nature.

Stephen Hawking first met Gordon Moore, the cofounder of Intel, at a conference in 1997. Moore noticed that Hawking’s computer, which he used to communicate, had an AMD processor and asked him if he preferred instead a “real computer” with an Intel micro-processor. Intel has been providing Hawking with customized PCs and technical support since then, replacing his computer every two years.

Stephen Hawking

Wired January 2015, Relates to special feature on Stephen Hawking, Hawking sits in his personalised special electric wheelchair, text in foreground from him screenMarco Grob/WIRED UK

Interview

There is a 17-minute interview behind the paywall.

Other Notes

The "Equalizer" is a 1980s computer program developed by Words Plus CEO Walter Woltosz to help his mother-in-law, who had ALS. It enabled Professor Stephen Hawking to communicate by selecting letters, words, and phrases on an Apple II computer via a hand switch, later upgraded to a cheek-switch sensor. 

Key Details of the Equalizer:

  • Purpose: Developed to assist patients with ALS who lost the ability to speak and write.
  • Usage: Hawking utilized this software, later integrated onto his wheelchair, to produce up to 15 words per minute.
  • Operation: The user interface allowed for selecting words from a database or spelling them out, which were then converted to speech using a Speech Plus CallText 5010 synthesizer.
  • Development: Walter Woltosz co-founded Words Plus in 1981 and created the software to provide a voice for those with communication disabilities. 

Stephen Hawking and the Technology that allowed him to continue his research18/03/2018

Stephen Hawking, who sought to explain the origins of the universe, the mysteries of black holes and the prospect of time travel, died today aged 76. Hawkings body was ravaged by the wasting motor neurone disease (ALS) he developed age 21 and spent most of his life confined to his wheelchair.

Hawking’s incredible mind probed the very limits of human understanding both in the vastness of space and in the sub-molecular world of quantum theory, which he claimed could predict what happens at the beginning and end of time.

In his 2013 memoir “My Brief History” he explained how at first he “felt it was very unfair” and often questioned “why should this happen to me.” With time and technology, he went from concern that his life was over and his potential never realised to now, 50 years later, feeling quietly satisfied with his life and achievements.

How Intel gave Hawking his voice.

In 1986, aged 44, Hawking lost his voice to save his life after an attack of pneumonia. For a while, he used a spelling card to communicate, patiently indicating letters and forming words by raising his eyebrows. Although this gave Hawkings the ability to communicate the process was slow. From then on, he spoke through a computer synthesiser on the arm of his wheelchair.

A chance encounter with Gordon Moore, the co-founder of Intel, at a conference in 1997 led to a relationship that would see Intel providing Hawking with customised PCs and technical support, replacing his computer every 2 years.

Martin King, a physicist who had been working with Hawking on a new communication system, contacted a California-based company called Words Plus, whose computer program Equalizer allowed the user to select words and commands on a computer using a hand clicker. Words Plus CEO Walter Woltosz had created a earlier version of the speech equalizer to her help his mother-in-law who also suffered from ALS.

Equalizer first ran on an Apple II computer linked to a speech synthesizer made by a company called Speech Plus. This system was then adapted by David Mason, the engineer husband of one of Hawking’s nurses, to a portable system that could be mounted on one of the arms of a wheelchair. With this new system, Hawking was able to communicate at a rate of 15 words per minute.

However, the nerve that allowed him to move his thumbs kept degrading. By 2008, Hawking’s hand was too weak to use the clicker. His graduate assistant at the time then devised a switching device called the “cheek switch.” Attached to his glasses, it could detect, via a low infrared beam, when Hawking tensed his cheek muscle. Since then, Hawking has achieved the feat of writing emails, browsing the internet, writing books and speaking using only one muscle. Although this system worked it was still slow… enter SwiftKey. With SwiftKey integrated, the system could learn from Hawking and predict the characters and words he planned to type next based on historical patterns, with this data funnelled through to his speech synthesiser. SwiftKey has also tapped Hawking’s historical works to help it more accurately predict his next words in this bespoke version of the software.

The technology that enabled Stephen Hawking to speak.

As you might expect, it is not just one piece of equipment that is involved here. Many technologies combined to allow Hawking to communicate.

  • Lenovo Yoga 260 provided by Lenovo and Intel, Intel® Core™ i7-6600U CPU
  • 512GB Solid-State Drive
  • Windows 10
  • ACAT interface software provided by Intel

Speech Synthesisers (3 copies):

  • Manufacturer – Speech Plus (Incorporated 1988, Mountain View, CA)
  • Model – CallText 5010
  • Speaker and amplifier provided by Sound Research
  • Permobil F3 wheelchair provided by Permobil

It is undoubtedly the incredible technology that enabled Hawking to speak again that gave him the hope and drive to continue with his work. Hawking was an Ambassador of Science and showed us what determination looks like.

What happened to Stephen Hawking?

Stephen Hawking died on March 14, 2018, aged 76. In itself, an incredible achievement, but Stephen did much more than simply survive for 76 years. His life was an inspiration to so many people. Interestingly, he didn’t believe in God or the afterlife. He called heaven “a fairy story.”

In his final, posthumous book “Brief Answers to the Big Questions.” he wrote “there is no God”. and “no one directs the universe.” He had disputed the existence of God for many years before his death.

he wrote, “The question is: Is the way the universe began chosen by God for reasons we can’t understand, or was it determined by a law of science? I believe the second,”

Hawking believed that “spontaneous creation” was the reason for existence, writing “it is not necessary to invoke God to light the blue touch paper and set the universe going.”

He will be remembered for many years.

By , No comments:
Tags , ,
Subscribe to: Posts (Atom)