Balisage Paper: Metaphors We Code By

Metaphors in Use: A Wee Analysis

To see what kinds of metaphors we use to talk about markup, I started by performing a quick analysis of the vocabulary used in the papers from the Balisage Series on Markup Technologies.

There are about two million words in this corpus and about forty thousand distinct words^[1]. Filtering out stop words, the top ten ignoring case are XML, document, element, data, model, language, markup, text, information, process, and content, so indeed this corpus concerns itself with markup, as advertised.

The corpus was loaded into a document database (MarkLogic) as HTML and then converted to XML using tidy. Despite the irony of back-converting something that was originally XML into XML, analyzing XHTML actually makes things easier, as the content is almost entirely wrapped in p elements.

Two methods were used to probe the popularity of particular metaphors. Seven different metaphors were probed, which we will look at in more detail later on: documents, trees, construction, paths, fluids, textiles, and music.

The first method tokenized and gathered counts of each distinct word from the text nodes of every document in the corpus. A separate set of counts were gathered for each distinct stem of each word.

xquery version "1.0-ml"; (: MarkLogic-specific extensions :)
declare namespace xh="http://www.w3.org/1999/xhtml";

let $counts := map:map()
let $_ :=
  for $word in 
    (for $p in //xh:p return cts:stem(cts:tokenize($p)[. instance of cts:word]))
  let $wordcount := map:get($counts,$word)
  return
    if (empty($wordcount))
    then map:put($counts,$word,1)
    else map:put($counts,$word,$wordcount + 1)
for $word in map:keys($counts)
let $wordcount := map:get($counts,$word)
order by $wordcount descending
return ($word||" "||$wordcount||"
")

An awk script then summed up the counts for vocabulary items related to the specific metaphor.

BEGIN {
    IGNORECASE=1;
    document=0;
    tree=0;
    construction=0;
    path=0;
    fluid=0;
    textile=0;
    music=0;
}

/document|book|scroll|page|file|folder|archive|directory/ {
    document += $2;
    documentlist[$1] = $0;
}

/tree|leaf|root|branch|trunk|wood|forest|jungle/ {
    tree += $2;
    treelist[$1] = $0;
}

/construct|build|built|architect|carpenter|carpentry|brick|concrete/ {
    construction += $2;
    constructionlist[$1] = $0;
}

/road|track|navigate|navigation|path|journey|steps|movement|climb|walk/ {
    path += $2;
    pathlist[$1] = $0;
}

/flow|pipeline|stream|slide|volume|pour|plumbing|leak|drip|drop|fluid/ {
    fluid += $2;
    fluidlist[$1] = $0;
}

/weave|textile|thread|woven|cloth|fabric|clothes|clothing|knit/ {
    textile += $2;
    textilelist[$1] = $0;
}

/song|melody|tune|music|notes|tune|harmony|counterpoint|chord|rhythm/ {
    music += $2;
    musiclist[$1] = $0;
}

END {
    print "document="document;
    for (w in documentlist) print documentlist[w];
    print "================================="
    print "tree="tree;
    for (w in treelist) print treelist[w];
    print "================================="
    print "construction="construction;
    for (w in constructionlist) print constructionlist[w];
    print "================================="
    print "path="path;
    for (w in pathlist) print pathlist[w];
    print "================================="
    print "fluid="fluid;
    for (w in fluidlist) print fluidlist[w];
    print "================================="
    print "textile="textile;
    for (w in textilelist) print textilelist[w];
    print "================================="
    print "music="music;
    for (w in musiclist) print musiclist[w];
    print "================================="
}

This method is quick and easy, but a little crude — there are plenty of usages of certain of these terms that have little to do with the metaphor in question — but it gives a broad view of overall patterns.

The second method made use of more complex full-text search capabilities, allowing the probes to exclude some of the usages that were irrelevant to the metaphor being probed. This method also allowed the selection of some utterances, below. It also means that we're counting the number of paragraphs in which the terms occur rather than the number of distinct instances of the term. It turns out that this doesn't much change the relative or absolute distributions.

xquery version "1.0-ml"; (: MarkLogic extensions :)
declare namespace xh="http://www.w3.org/1999/xhtml";

declare variable $DOCUMENT := 
  ("document NOT_IN documentation", "book", "scroll",
    "page NOT_IN p:bibliomixed",
    "file", "folder", "archive", "directory"
  );

declare variable $TREE :=
  ("tree", "leaf", "root", "branch", "trunk NOT_IN a:trunk", 
   "wood NOT_IN a:wood", "forest", "jungle");

declare variable $CONSTRUCTION :=
  ("construct", "construction", "build", "builder", 
   "architect", "architecture",
   "carpentry", "carpenter NOT_IN Carpenter[unstemmed]",
   "brick NOT_IN Brick[unstemmed]", "concrete");

declare variable $PATH :=
  ("road", "track NOT_IN (tracking[unstemmed] OR tracked[unstemmed])",
   "navigate", "navigation", "path", "journey", "steps[unstemmed]", 
   "movement", "climb", "walk");

declare variable $FLUID :=
  ("flow", "pipeline", "stream", "slide", "volume NOT_IN p:bibliomixed",
   "pour", "plumbing", "leak", "drip", "drop", "fluid");

declare variable $TEXTILE :=
  ("weave", "thread", "woven", "cloth", "fabric", "clothes", 
   "clothing", "knit");

declare variable $MUSIC :=
  ("song", "melody", "tune", "notes", "harmony", "counterpoint",
   "chord", "rhythm");

declare variable $BINDINGS :=
  map:new((
    (map:entry("p", function($op,$val,$opts) {
      cts:element-attribute-value-query(
        xs:QName("xh:p"), xs:QName("class"), $val, $opts)
    }),
    map:entry("a", function($op,$val,$opts) {
      cts:element-query(xs:QName("xh:a"), $val, $opts)
    })
  ));

declare variable $SAMPLE_SIZE := 5;

declare function local:sample($subquery as xs:string)
{
  let $query := cts:parse($subquery,$BINDINGS)
  let $results := cts:search(//xh:p, $query, "score-random")
  let $count := count($results)
  let $sample :=
    (for $res in $results
     let $rand := xdmp:random($count idiv $SAMPLE_SIZE)
     where $rand <= 1
     return $res)[1 to $SAMPLE_SIZE]
  let $highlighted :=
    for $s in $sample return cts:highlight($s,$query,<xh:b>{$cts:text}</xh:b>)
  return <subquery><q>{$subquery}</q><count>{$count}</count><sample>{$highlighted}</sample></subquery>
};

declare function local:analyze($label as xs:string, $subqueries as xs:string*)
{
  let $results :=
    for $q in $subqueries return local:sample($q)
  let $count := sum($results/count)
  return (
    "
===="||$label||" "||$count, <sample>{$results/sample/*}</sample>
  )
};

local:analyze("DOCUMENT", $DOCUMENT),
local:analyze("TREE", $TREE),
local:analyze("CONSTRUCTION", $CONSTRUCTION),
local:analyze("PATH", $PATH),
local:analyze("FLUID", $FLUID),
local:analyze("TEXTILE", $TEXTILE),
local:analyze("MUSIC", $MUSIC) 

Each of the following sections discusses a particular metaphor. Sample utterances illustrate the application of the metaphor. They all come from this very conference series.

DATA IS DOCUMENTS, PROCESSING DATA IS CLERKING

The document metaphor dominates our understanding of computer data. An astonishing one percent of all the words used in the corpus relate to this metaphor. The other metaphors hover around one or two permille at best. We store documents on the file system in directories, we archive them, or convert the information into records. We page and scroll through them and create bookmarks. Our software is put into libraries, our data is indexed, our file systems are organized into volumes. Our user interfaces show us little pictures of books and folders and animations of pages flying by as we copy data from one slice of spinning magnetic domains to another.

What is the story we tell ourselves about our data with this metaphor?

Data is authored and divided into useful and coherent units. It is finite in extent, and scaled to something a human could read in a reasonable amount of time — minutes, a hour or so, perhaps a day. It is organized and categorized: it is comprehensible. It contains human text. Data is visual: it is something to be read. Data is developed, and then done. Books are written. A new edition may come out, but it is a new edition. It is also the natural state of books to be read and shared.

This is not to say all these properties are true of any particular collection of data. Rather, these are the properties we inchoately assume and understand when tell ourselves that data is documents, even when that data in no way is an electronic representation of a physical document.

The metaphor steers us towards thinking about certain things, and steers us away from thinking about others. When a social media feed is understood through the lens of documents, we think about editorial discretion, we think that it is something people produce. We think about human scales and timeframes. We don't think about mobs of bots generating posting swarms. A different metaphor, around pest-control or epidemiology, would better serve us in that case.

What would it mean to take the document metaphor seriously? It is so pervasive, one could hardly take this metaphor more seriously, it would seem.

Still, there are documents and there are documents. The Book of Kells is not your weekly shopping list. One is a treasured artifact, carefully protected, where modern copies are valued at tens of thousands of dollars. The other lies crumpled in your wastebasket, or rotting in the lint trap of your dryer. A document is an impermanent artifact whose inks fade and whose pages brittle with age and are eaten by beetle and moth larvae. To take the document metaphor more seriously would be to seriously consider the impermanence of things and the need for active curation and preservation and which documents need our care and which should be thrown out. This is hard to do when all documents look alike in our electronic spaces.

Make no mistake, electronic documents also need active curation and preservation. Large swathes of data gathered during the Apollo missions, at the cost of much treasure and some lives, rotted on tapes that became obsolete, then unreadable, and then lost.

When you think about your data through the document metaphor, what should you think about to counter the implicit bias of that metaphor? What are the blind spots?

For example, think of the assumptions built into a classic search engine: indexing happens in an incremental and lazy fashion, on timescales of hours after data is changed. Search engines in the 80s and 90s assumed it was OK to completely rebuild the search index when the set of documents changed. These are all assumptions based on a data is documents way of thinking.

DATA IS TREES, PROCESSING DATA IS FORESTRY

The metaphor of the tree is largely a metaphor based on a similarity of structure, albeit one typically drawn tilted on its head, so that roots are in the air and branches lie below. It derives from a long history in computer science data structures and a metonymous application of the data structure for the data.

The story we tell when we use this metaphor is one of structure: there is one starting point, the root, from which branches diverge all the way to the leaves. The branches never come back together. There is a unique starting point. Leaves differ in some fundamental way from branches and branch points. Overlap doesn't happen.

Again, it doesn't mean all of this is true about our data; only that this is what we know in our bones when we speak of our data in this way.

Let's push the metaphor a bit, and think about trees, real living trees. We should start by considering the full tree, not just what we see above ground. Trees spread their roots wide and deep: their true shape is not a widening triangle, but two triangles meeting: the visible and the invisible. The trees do not live in isolation but, as Peter Wohllenben teaches us in The Hidden Life of Trees, in communities and families with mycorrhizal networks linking their roots together.

What, if anything, is the metaphorical application of this invisible triangle of roots? Roots whisper to us of unseen riches nourishing the whole. What could that tell us about our data? Here, perhaps, we have metadata which has its own hierarchy of organization all feeding into the visible base of the tree and which links one piece of data to other pieces, one tree to another. To take that part of the metaphor on board is to intuit that metadata is a complex and extensive as data, not just a few simple tags.

Trees, real trees, do not live alone, but in woodlands and forests. What kind of forest do we understand this to be? To think about different kinds of communities of trees is to have a different understanding of what our job is in processing that data.

A woodland with one a single kind of tree, all the same? A farm of trees, carefully grown to spec? Our data processing task is one of managing the production in a careful way, fending off pests, and harvesting the results at the appropriate time. There is uniformity, and few surprises. One document is nothing special, just a cash crop. Sensor records are trees of this kind.

A wild and untamed jungle with trees of many shapes and kinds and a profusion of growth? Our data processing task is one of beating back unchecked abundance, hacking with machete, burning with fire. The jungle will always come back: our job is to keep a little of it under control, for a time. Data is understood as something that happens to us, not something we make. Social media data, perhaps? Maybe we should consider scorching a few acres from time to time to clear it out. Notice, however, the jungle metaphor is a way of hiding human responsibility: the jungle is self-creating, so no one is reponsible for perpetuating or preventing any harms. Saying Twitter is a jungle is saying that the company has no responsibility for what happens there.

A woodland filled with old and twisted trees that have accumulated centuries of accidents and contingencies to create their own unique shapes? Our data processing job here is preservation and understanding the unique needs of each individual. Each tree is old and precious. Digital archives are woodlands of this type, the Staverton Thicks of markup, with layers of annotations from generations of scholars.

Perhaps we have a well managed woodland, with coppices or pollards and livestock roaming the understory? Most of the "wild" forests of Europe were woodlands of this sort. Our data processing job here is to be the woodcutter, venturing into the wood to cut beech and oak to the ground, to gather the wood and encourage growth for the future. Or perhaps we are the swineherd, setting the pigs lose to root through the humus and keep down the underbrush. Data is something that we manage, collect, and put to use and something that grows somewhat of its own accord. Business records live in this kind of forest.

Forests, unlike isolated trees, are a little scary. In the wonderful book Gossip from the Forest, Sara Maitland points out that the forests of our fairytales and our imaginings are places where, above all else, you get lost. We may hope to find a friendly woodcutter, but we're probably on our own and the wolves are tracking us. We can lose ourselves in our data forests too, if we're not careful. They extend far into the hills and it's dark in there. Best keep an eye out for the wolves.

How can we respond to the biases of the tree or forest metaphor? Even if your markup formalism doesn't admit to non-tree-structured data, thinking about the way in which your data is not logically a tree may lead you to adding mechanisms to represent that.

For example, when we think about our data as trees, cross-cutting relationships or overlaps are weird and exceptional. When you model the same information as RDF, notions of hierarchy, overlap, or parallel representation disappear entirely. Modeling data with a mix of XML and RDF can allow for a richer view. What is the appropriate metaphor for that?

DATA IS BUILDINGS, PROCESSING DATA IS CONSTRUCTION

The metaphor of data as a building tells us a story of intention and artifice. Data is created with deliberation and a design for a particular human purpose. It is robust, solid, durable. It is singular: a thing, not some stuff. It is regular in form, not some wild organic wolf-infested thing. It is made, not grown. It doesn't happen to you, you happen to it. Data is a tangible thing, something to be grasped.

To be a builder is to execute a plan. There are blueprints from the architect. There is a project to be managed, coordinating the work of carpenters and roofers, electricians and plumbers. There are building codes to be followed and inspections to pass.

To take the metaphor more seriously would be to seriously consider what the building codes are for our projects as well. Serious data processing projects do have building codes: schemas and standards and rules. The building inspector is the validator.

Buildings may be used by many, but we don't think of them as shared by many in the same way a book is shared. Books circulate. Buildings stand. We visit them, and then leave again.

Like trees, buildings do not exist purely in isolation. They are grouped into towns and cities. Like trees, there are underground linkages: the shared infrastructure. What is the shared infrastructure for our data constructs? There are differences in scale in various assemblages that affect interactions and usage. A village has different security and privacy considerations than a megalopolis. What is the scale of your building project?

As there are different kinds of forests, there are different kinds of buildings and building projects. Banging together a tree house is not the same as putting up a cathedral.

What kind of construction is your project?

The prefab shed in the back yard can get put up by a couple of guys in an afternoon. The hard work was done back in the factory and designing any separate pieces so they are easy to fit together. Data processing has been streamlined for us, and we just need to use some basic tools and follow a simple plan. The data processing work for the factory is to make a plan and pieces that can be put together simply. Success depends on tightly constraining what is possible, limiting the tools needed, and the kinds of interactions pieces can have. In the data realm, I think this is a goal more often aspired to than accomplished, but it is crucial for the empowerment of non-technical folks.

What one sees more often is the dry stone wall of data: when executed by a master, beautiful, solid, effective, each component fit together just so; when executed by a novice, a heap of stones that sort of does the job. Maintenance by someone other than the master is hopeless, and likely to cause more damage than repair. The lesson of wall-building in the real world is that standardization of parts and methods — bricks and mortar, so to say — makes wall-building accessible to folks other than master craftsmen. Not as strong, not as efficient, not as beautiful, but more widely possible. What are our markup bricks? HTML elements, perhaps.

One also sees skyscraper projects, where the construction of the support machinery is an undertaking in its own right. Making the stylesheets to generate the stylesheets to make the XML. The mistake we sometimes make is not to plan the support infrastructure properly, or to fail to ensure that it too follows building codes. The crane comes crashing to the ground, to the great dismay of all.

And we have our cathedrals: long-term projects consuming generations of graduate students to complete, complete with their gargoyles and stained glass, and the extra buttressing on the west wall, just to be sure.

The building metaphor centers human agency and planning; countering its bias is to think about ways in which things might happen outside of human intentions.

For example, you may have some nicely constructed documents, and still want to bring a folksonomy to the party to help with user-centered organization, even though it is unplanned and ever-changing.

DATA IS A PLACE, PROCESSING DATA IS A JOURNEY

The story we tell ourselves with the metaphor of the path is that we are heading somewhere: there is a starting point and a destination, and if we keep moving forwards we can get there. Data is a space to navigated. It isn't made. It doesn't grow. It just is. Our job is to find or make the path that gets us to our journey's end.

The thing about paths, too, is that they are shared. Once the trail is blazed, others may follow. So the metaphor of the path tells a story about reuse. It may also tell a story about return: There and back again. Making a path is about marking a path: markup as signposts. "This way to Llanelli." "This way to footnote 5."

To speak of paths is to focus on what you do with the data, not on the data itself.

Data as a place also tells us a story about enclosure and boundaries: my data, your data, their data. The data is bounded, and owned. You might need fences or (fire)walls to protect it.

When data is a place, you fear invasion. There are those who belong in that place and those who don't. Locking up books is censorship. Locking your front door is prudence. There can be real-world policy consequences about how we talk about our data.

The path metaphor puts the focus on interactions with data rather than on the data itself. It may be helpful to remember that shaping the data also shapes the possible navigations through it.

For example, where data may change, references used to point to particular points in a document through a path must be stable for the paths to be reused. If ids are useds to anchor places in the path, the ids must be stable. If tumblers count children, the number of children cannot change. There are plenty of document production systems that rely on ids on anchors to point to places in the TOC, where those ids are randomly generated, and therefore not consistent when the documents are edited. Unfortunate.

DATA IS A FLUID, PROCESSING DATA IS PLUMBING

The story of pipelines is a story of change. You never step in the same river twice. There is a sense of abundance and continuity, of inexorableness and endlessness. You data is pouring through your channels, and you can direct it, guide it, pen it up for a time: but it keeps on flowing. Once you start it off, there's no holding it back. You can no more stop your data than Canute can stop the tide. It's a little frightening too. You might drown in it.

In the data as fluid metaphor, our job is the job of plumbers, to set up the valves and conduits so the flow follows its proper path. Data is tangible, but it is stuff, something to be put in a container. Water runs everywhere. It isn't so much shared as distributed.

The language of leaks and breaches is also a means of removing agency and abdicating responsibility. The data is somehow responsible for its own actions rather than some person.

When you imagine your data pipelines, what kind of fluid do you imagine it to be?

Is it something benign and harmless like water from start to finish? We are the builders of aqueducts and canals, spreading the life-giving water to the parched plain. Heroes! This is a job of distribution and sharing. To take it seriously is to consider and measure how we are partitioning the data, how much is coming in, how much is going out, where it is going, where it is not.

Or is this a sewage treatment plant, where you start off with something horrid, and end up with something sparkling and clean? Our job is one of continual refinement, adding ever finer filters and treatments to ensure a good result. To take this view seriously is to make sure we are sampling our outputs to know that nothing harmful has made it through.

Or is this more of a chemical plant kind of scenario, where there are complex and dangerous interactions that might explode and endanger the townspeople if they don't go right? Is this crude oil where a leak creates a toxic mess?

If our data fluid is a volatile or harmful chemical, we should import the lessons of chemical process control. Maybe we should identify and record the critical process parameters, the inputs to the process. Maybe we should identify and monitor the critical quality attributes, the metrics on how processing is proceeding that tell us what is happening and where it is starting to fail. Chemical plants are filled with complex interactions and non-linear effects, making them difficult to control and manage safely (Perrow99). Sometimes data behaves that way too: you didn't expect there to be more than one of those kinds of elements, and you didn't check, and now your whole process misbehaves. Best have gauges measuring what you need at key junctures.

Certainly if the data we are pushing through our plumbing is of a sensitive nature — health care or banking records, for example — the cost of a leak can be extensive. A double-walled hull for the transport may not be too much to ask. Or, in the lingo of security folks, security in depth.

Maybe we need to pay attention to the effluvium that is not the primary output, but that may be dangerous if it propagates into the environment. We all may wish FaceBook had thought of their data releases in this way.

Thinking about different kinds of fluids makes us think about different kinds of pipeline steps. Cleaning is about filtering and narrowing flows. Single inputs and single outputs. Distribution is selection and about divergent flows. Chemical processing is about convergent flows, refractionation, and feedbacks.

The data as fluid metaphor removes human agency from the picture; counter its bias by thinking about human responsibilities and actions. This metaphor also removes the identity of pieces of data as distinct artifacts from view; counter that bias by thinking about the ways in which different data needs different handling.

Sometimes embracing a metaphor can help us grasp something more firmly. For example, we can understand the risks of deanonymization through the metaphor of data as fluid: mixing two chemicals that aren't dangerous in themselves can create a dangerous situation.

DATA IS A TEXTILE, PROCESSING DATA IS WEAVING

Textiles and software go way back: Hollerith punched cards are an evolution from Jacquard punched cards, after all. The words text and textile are cousins, coming from the Latin verb texere (weaving). Knitting patterns are programs in a domain-specific instruction set, designed for humans to execute.

Textiles tell a story of unity in complexity, of interacting and entangled structures. Data is made, with skill and artistry. Taking the sewing side of the metaphor over the weaving side: data is pieced together from specifically cut pieces, again, with skill and artistry, hiding the seams. Data is flexible, within limits. It is finite and put to some deeply human purpose. There is a plan. There are measurements. We are not afraid of our textile data. There is a sense of fragility: weavings can be unravelled or torn. Data is tangible, something to be draped, something to be worn. Soft and pliable, but not freely intermixed.

Textiles are holistic but singular. They don't blur and mix like fluids. What matters isn't individual stitches, but the pattern as a whole.

As with buildings, there are plans, and patterns of various levels of complexity. But textiles are more personal. You don't share your socks.

Textiles are flexible, but they are not ever-changing. Change is about mending and patching, not fundamentally reshaping what we have.

What do different kinds textiles teach us?

Weaving teaches us that the interactions of strands create patterns of their own. Overlap not only happens, it is essential.

Knitting patterns teach us that short and simple generation instructions can produce complex results. It might be better to store the generator rather than the instance.

Embroidery speaks of annotations, adding layers of meaning.

White work teaches us that we can create complex information patterns by removing threads and creating voids.

Quilting teaches us that we can create mash-ups from disparate data sources to produce something new.

Like the building metaphor, the textile metaphor centers human agency and planning. Countering that bias is to think about what happens outside human intentions. Like the document metaphor, the textile metaphor lends itself to assumptions about human scales in time and size, and thinking about inhuman scales is a useful counterpoint.

RDF data is often conceptualized as a graph, but textile metaphors work well too. There are threads of different colours knotted and linked together to form a complex whole. The difficulties of multiple roots or overlaps or concurrency just don't come up: it is the pattern as a whole that matters.

DATA IS MUSIC, PROCESSING DATA IS PERFORMING

The musical metaphor gets hardly any traction: less than one half permille of this corpus, and most of those usages in the corpus are about actual music, not metaphorical at all.

One place where music does get taken more seriously in the context of data is sonification. Sonification is the rendering of data as literal music. It works because humans are better at hearing subtle patterns in complexity than seeing them. Wordless information of various kinds (EKGs, gravity waves, Geiger counters) has been effectively sonified. What would sonification of markup look like?

The story this metaphor could tell is one of creating a beautiful unity out of richness. Data is created as an act of cooperation and blending together disparate voices and instruments. Music carries emotion of all kinds. Like the fluid metaphor, there is continuity and things happening over time. Music itself is often understood through the metaphor of flowing water. Like the construction metaphor, this is a planned activity. There is a composer and score and a conductor. Like the textile metaphor this is an intimate, deeply human craft. Data is not visual to be read, not tangible to be grasped, but audible, to be heard. Change is encoded in the very structure of the music itself: present, but part of the pattern. Sharing too is intrinsic in the concept of music: but the sharing of experience. Music is ephemeral.

What would markup be like if we thought of it as scoring? We wouldn't think of overlap as a problem at all, but as our essential task. Our representations would be representations of parallel tracks, our words arranged in time rather than space.

The data as music metaphor can itself be a useful alternative viewpoint to more common metaphors. What if we liked our data? What if it were a participatory activity, not an artifact? What if the goal of security weren't keeping secrets but preserving the usefulness and integrity of the performance? The musical metaphor might encourage us to consider the emotional impact of data and structure our systems accordingly.