Update: Comments are go!

I just realized that I had taken out comments in my design of this site, never intending to “blog” with it. Well, indeed, I’ve been doing just that, so I’ll add them back into the theme for all categories under the umbrella of “Blog”.

If you had anything deep to say, check back tomorrow.

Justin Ouellette, creator of the wonderful (though eventually shut-down) mixtape-sharing site Muxtape, has created ihardlyknowher.com, a wonderful browser for Flickr images. Really, this is the ONLY way to view Flickr images.

The reason that I bring it up is that it’s so simple: something which most of us could have implemented. A good idea goes a long way.

Also, for the first time, I feel that I can share my Flickr without some of the experience being lost. Go to http://ihardlyknowher.com/organisciak and scroll to the very bottom to change the size from “smaller” to “larger”. Share your own Flickr sets in the comments.

With the text as an “ordered hierarchy of content object”  theory still fresh in my mind, I wanted to share something perhaps strange: my favourite object notation model. The reason that I want to share is to show how powerful and encompassing such a simple structure can be. What I want to talk about is JSON.

JSON (JavaScript Object Notation) is simply a collection of arrays and objects. I’ll describe what those are momentarily, but what you need to know is that they are simply incrementally more complex values. A value is simply one item. For example:

hamburger

That’s it. If you want to set it to a variable (a saved, named value; think of the use of letters in algebra as placeholders for numbers or formulae), it would something like the following:

myLunch="hamburger";

Note that I added quotation marks, to show that the value is a string. This way, the computer will not confuse it for another variable.The semi-colon also shows that it is the end of the  formula: I’ll get  to the significance of this later.

Moving on,  an array is a list of values rather than simply one. In JavaScript, such lists exist within square brackets, as such:

myLunch = ["buns", "patty", "tomato"', "lettuce"];

To reach a specific item in an array, one simply has to ask for the index location. Each value is numbered, starting with zero, so to ask JavaScript for myLunch[2], JavaScript will tell give you “tomato”.

While an array is a simple list, separated by commas, an object is a list where each value is labelled. These are called “name-value pairs”, because each value is combined with a name. In JavaScript, and therefore JSON, the two are separated with a colon. So, this would be an object:

myLunch = {"ingredient1":"buns", "ingredient2":"patty", "ingredient3":"tomato", "ingredient4":"lettuce"};

Here, instead of requiring an index place for finding a value, you simply need to know its name. So instead of myLunch[2], using myLunch.ingredient3 would return “tomato”. Note also that curly braces are used for objects, while arrays used square brackets.

Now, JSON is not only simply, it’s intended to be easy to read. As a result, line breaks and tab stops make no difference. This is why the semi-colon is important: simply pressing Enter won’t end your formula. So, the above object can be written as:

myLunch = {

"ingredient1":"buns",
"ingredient2":"patty",
"ingredient3":"tomato",
"ingredient4":"lettuce"

};

Note how nesting is used to show a heirachy.

Okay, so now we have arrays and objects, either of which can be put in place of a single value. JSON simply combines all of this in a neat back, replace values with objects or arrays when necessary.

Here’s an example:

myLunch = {

"type":"hamburger",
"ingredients": [

"patty",
"tomato",
"lettuce"
]

};

Note that the first value in the object (for”type”) is only one value, while “ingredients” has an array in the same place. This can be expanded as such ad nauseum.

The idea behind JSON is that it is extremely lightweight (consider the parallel it would have in XML), permanently stable (so no versions), and is easier for computers to understanding. What’s great about it is that conveys very easily how objects can be contained in such structures. For example, if I had a file that belong in a folder (I use the folder example because it’s the most common hierarchy that we encounter in computing). Now, say I have two different folders that this item belongs to. So where do you put the item? The answer is in neither place; rather, you’d link it to both folders. So it’s not that our JSON structure would be follow folder structures, but rather it would be based around the items, which would list their locations. Overlapping hierarchies are a concern when you’re thinking of computing’s outdated physical metaphors; the sort of tree model that you find in XML and JSON is not actually constrained as a “box within a box within a box”.

In my last post, I included a link to a page with e.e. cummings poetry, with the text “e.e.cummings” being the only text for the link. As I thought about whether a deeper explanation was necessary, it struck me how wonderfully open-ended the choice was. While there may be  best practises, there are no rules on how I can and cannot link, meaning that I can do it as is appropriate to me.

I’m fascinated  by the nature of an HTML link because, well, it’s not really a “link”. A web link is not a relationship, it’s a reference. It simply points to a different location, with no obligation by the referred to reciprocate. It’s not elegant, but the simplicity has it’s own beauty. The Internet has grown exactly because of such lenience, giving more control to users in developing the web.

Ted Nelson’s Xanadu project, a complex early hypertext system, attempted to show relationships in a reciprocal fashion. Links in his system would have been would be more uniform, predictable, and never broken. Our lesson can be seen in how the relatively archaic World-Wide Web left Xanadu in the dust. However, we still see relational links where they are more appropriate: social networks and social networking sites. A link to a friend is two-way. Thus, to sever a tie, two friends are lost, one on end of the relationship.

Thinking about this freedom, I’m reminded of Myspace. Early in its history, an exploit was discovered that allowed Myspace users to inject custom CSS. Rather than patching the “problem”, Myspace left it alone, neither stopping nor encouraging the practice. What resulted is that the site hit a chord with youth users, this exploit feeding the tendency of content creation that today’s teenagers have (see “Teen Content Creators” from the Pew Internet and American Life Project). This little site design huccup has often been cited as a reason for Myspace’s growth, while other early social networks floundered.

What strikes me when considering the nature of text is how variant it is. For this reason, in reading Renear et al.’s examination of the theory of texts as an “ordered hierarchy of content objects” (OHCO), I cannot shake a feeling of complete weariness with the discourse.

A text is not something that can readily be defined. Texts do not undergo a strict assessment of their warrant as texts to earrn the designation; consequently, the definition follows the objects. There can be a remarkable range in the breadth and granularity of a ‘text’ definition, simply because it becomes a judgement call in drawing the line. We generally agree on only a few identifiers, such as the use of an alphabet, usually a language based structure, and oftentime adherence to a visual template (in our culture’s example, top to bottom, left to right rows).

So, does visual poetry qualify as a text? The poetry of e.e. cummings would face little opposition. A few, I would guess, might argue deeper visual poetry, where language is no longer used and the poetry is actually a image derived from the shapes and interplay of the different characters. Now, what about ASCII art? It’s simply a more complex parallel to forms of visual poetry. The Digital Mona Lisa, circa 1964: is it a text or simply art? What about if you start incorporating colour and size (e.g. CSS Homer Simpson) or time (e.g. Star War Asciimation).

I’m not trying to advocate a fully relativist view of text, nor am I a fan of slippery slipe arguments. Rather, my concern is with the aforementioned reading by Renear et al. It appears to me that, given any theory on text, one could simply take a position one step more radical and debate it, finding an example on the fringes of the definition. The paper explicitly sets out not to debate the OHCO theory on its merit as a framework for considering encoding issues, but to judge it as an all-encompassing theory. However, in considering the breadth and outliers in the world of text, I would say that the former is a consideration with much more value, while the latter is insignificant.

Google has just released software called Blog Converters, a set of python scripts with the purpose of converting your blog contents between blogging platforms. Currently, it supports Blogger, Moveable Type, WordPress and Livejournal. This comes just a month after they implemented Import/Export functionality into Blogger.

While it currently does not offer much value for less experienced users, this is a direction that I am thrilled to see Google pursuing. As we increasingly store our information online, it is somewhat off-putting that we are so limiting in our abilities totake it back.  For example, I have been using the online word processor Writely (now Google Docs) nearly exclusively for three years and, were it to disappear, so would 400 of my documents. This is what happened to users of AOL Hometown recently, which spurred Jason Scott to write a powerful call to arms recently. Some of the comments that Jason found, from the poor AOL users that missed the memo and have lost their data, are heartbreaking.

As a new school term starts and I find myself with three impending research proposals, I’m once again evaluating my priorities in Digital Humanities. What holes have we left in our digital development? This issue of data freedom over one’s own content is at the top of my list, and thus I applaud Google for their efforts. I can only hope that this philosophy moves into other areas of the company, which has left it’s own path of data destruction in the wake of recent service shutdowns.

Over the December break, a discussion broke out on Humanist on the nature of theory and whether it is something inherently textual. I found the shining moment to be when Stan Ruecker, responding to the wonderfully eloquent Martin Mueller, defends the concept of a prototype as a theory.

“I do agree with Martin that it isn’t necessarily a good idea to call all implicit purposes theories, which leads me to what I believe is the third advantage of saying “a prototype is a theory” — namely that it may help remind us that theorizing by prototyping is different from building production systems, however elegant they may be. There is always a temptation to forget that thinking by building, as Richard Cunningham reminds us, is one of the things we are about.”

This perfectly reflected my thoughts as I was reading through the discussion. A prototype is necessarily an embodiment of a theory for it to have any value. It is a statement of, “I believe this is how an problem can be solved, and this is a way that may properly realize that idea.” It can be argumentative or exploratory, but it should not be neither.

Yes, in practise this is perhaps not always the case, but as Stan explains, it should be. The semantic difference between the two is that a theory is, in essence, a hypothesis, which would technically make the prototype the test of that theory. However, the particular approach that is taken in realizing the test itself carries a collection of idealogical suggestions which bind the two together.

Note: To glance at the discussion yourself, start at “writing and pioneering” and read until the end of December and into the beginning of January.