Postropolis as data framework supports the evaluation, problem-solving, design, and communication process that manifests in various ways using tools within and beyond the Postropolis platform.
To support this process-platform relationship for understanding patterns of actions exhibited over time by individuals and populations within their shared environments, there is a general need for a data framework that is flexible through its modularity and extensibility—especially when looking for ways to translate extant data from other research and assessment systems—with the data that are collected and analyzed using the Postropolis platform tools as part of any evaluation-communication process.
We’ve found that xAPI, or Experience API (formerly known as Tin Can API, born out of SCORM), is a good fit for this modularity and extensibility necessary in the Postropolis data framework.
xAPI
Perhaps it’s best to rely on the currently concise Wikipedia summary of xAPI as the best quick objective reference for the differentiation of xAPI from its predecessors, which gives some indication of its fit for Postropolis:
“The Experience API (Tin Can API) is meant to succeed SCORM, the Sharable Content Object Reference Model, which has been the de facto e-learning standard for packaging e-learning content. There are several drawbacks to SCORM. The new Experience API allows trainers to deploy several new capabilities that were not supported with SCORM, such as:
Taking e-learning outside of the web browser
E-learning in native mobile applications
More control over learning content
Solid security using OAuth
Platform transition; e.g. start e-learning on a mobile device, finish it on a computer
The ability to track games and simulations
The ability to track real-world performance
Team-based e-learning
Tracking learning plans and goals
The Experience API (Tin Can API) is an open source API. It is a Representational state transfer web service that uses JavaScript Object Notation (JSON) for its data format. The web service allows software clients to read and write experiential data in the form of ‘statement’ objects. In their simplest form, statements are in the form of ‘I did this’, or more generally ‘actor verb object’. More complex statement forms can be used. There is also a built in query API to help filter recorded statements, and a state API that allows for a sort of ‘scratch space’ for consuming applications.”
From an evaluation standpoint, the beauty of xAPI lies in the “actor-verb-object” model at its core. This is a human-scaled reference for activity that allows us to collect and analyze (measure and assess) data about our own actions (behaviors), as well as those of any other species, to seek out patterns of individuals and populations within any ecological context.
Another excellent resource for understanding xAPI is The Advanced Distributed Learning Initiative, or ADL, which is the organization responsible for the API:
“Broadly defined, the Experience API (xAPI) lets applications share data about human performance. More precisely, xAPI lets you capture (big) data on human performance, along with associated instructional content or performance context information. xAPI applies human (and machine) readable “activity streams” to tracking data and provides sub-APIs to access and store information about state and content. This enables nearly dynamic tracking of activities from any platform or software system—from traditional Learning Management Systems (LMSs) to mobile devices, simulations, wearables, physical beacons, and more.”
Additionally, the ADL provides a general specification of API via Github. Furthermore, Part One (About the Experience API) and Part Two (Experience API Data) of the specification are highly recommended reading. If you really want to dive into the procedural nuts and bolts, Part Three (Data Processing, Validation, and Security) is worth a look!
Hybrid Simulation
How can an actor-verb-object (action-based) Postropolis data framework be most useful as a foundation for the evaluation-communication processes supported by the tools of the Postropolis platform? Perhaps it’s best to consider the perspective that we humans, along with all other species (whether they know it or not), live in a hybrid simulation. Thanks to the information economy and the collective set of global digital platforms that exist to support our communications and interactions (consumption and production) within this economy, we currently co-exist with a simulation layer that appears atop, around, and infused with our physical reality as a flesh-based species moving about on an atmospherically-insulated water-covered rock floating through space.
If we conceive everything that happens between individuals of our species and all other species and entities on (and in) the rock, in the water, and in the atmosphere, coupled with everything that happens within and across this simulation layer, as a series of transactions (events) that can be measured and assessed as relationships between members of these two layers, we can begin to understand how to evaluate the past, present, and future “state of the state” of our global home in a more holistically contextualized fashion. As the next step in this evaluation process, we’ve established the Simulation Relationship Assessment framework, based on the xAPI actor-verb-object data structure.
Simulation Relationship Assessment
The Postropolis Simulation Relationship Assessment (SRA) Framework, shown below, is a catalog and matrix of generalizable categories of entities which can interact with each other amongst the combined physical reality and simulation layer.
Intended by default to be extensible, this current matrix of categories is rather high-level and is by no means exhaustive. There is already some debate as to whether the “Person” category should be subsumed under the “Animal” category.
As we continue to observe interspecific interactions within the physical layer, we can also begin to understand the relationships between the simulation layer and the individual and collective behaviors of our own species as well as others, including the effects these behaviors have—or rather the relationships that manifest as a result of our behaviors—upon. Let’s follow a rather simplified example series of transactions using the SRA.
Jamie Creates Grocery List (using a smartphone) = P-M → M-I, etc.
Jamie Travels to Grocery Store (using SUV) = P-M → M-I → I-M → M-Ge → M-At, etc.
Jamie Reads Grocery List (using a smartphone) = P-M → M-I → I-P, etc.
Jamie Selects Groceries = P-An → P-Pl → P-Fu, etc.
Jamie Buys Groceries (from human cashier, not self-checkout) = P-P → P-M → M-I, etc.
Jamie Travels Home (using SUV) = P-M → M-I → I-M → M-Ge → M-At, etc.
Jamie Makes Dinner (for Family) = P-M → P-An → P-Pl → P-Fu, etc.
Jamie Eats Dinner (with Family) = P-P → P-An → P-Pl → P-Fu, etc.
Clearly, each of these SRA transaction strings could be much more detailed.
Also, consider how we might track the transactions (and relationships) inherent in the pathways of existence and interaction many of the actors within the transactions shown arrived on the scene. How did the plants, animals, and fungi which became groceries get to the grocery store? How did the gasoline get into the tank of Jamie’s SUV? What path the materials of which Jamie’s smartphone is made take to get into the phone and into her hands? How many lives (human and non-human) were touched by these pathways and processes?