Restarting the machine at this point would not get it far enough to gain me SSH access. A manual fsck from single-user mode was required.

In practice, I found it takes about two hours on the phone to instruct a non-technical (but very helpful!) user to hook up an otherwise headless server up to a keyboard and monitor, restart the machine, enter the root password, type “fsck /dev/VolGroup00/LogVol00″, press enter a couple of times, and restart the machine again, all while communicating verbally the contents of the screen. (Coincidentally, I think this is a really good exercise for understanding the amount of effort required by blind people to surf the web using a screen reader.)

I wish SSH access to keyboard and CGA display was a basic, low-level BIOS feature. Until then, there are remote KVM devices like this one, but they are very pricey. And you’d still need a remote power switch to allow remote hard reset.

[1] With all graphical fluff turned back to “Windows Classic” mode, of course.

[2] Originally one running Fedora (the free version of what used to be called Red Hat), then after a year I upgraded all the hardware and installed 64-bit CentOS (the free and independently maintained version of what is now sold as Red Hat Enterprise Linux). They are very similar, though I suspect Fedora package repositories might be more up-to-date and reliable (not sure; for all I know they might be equivalent).

Recently, a new trend in online advertising is appearing.  As many social sites incorporate ‘like’ features or other approval mechanisms, some have started adding this feature to advertisements.  Hulu.com, which streams network-approved videos of television shows and movies, has this feature for their advertisements; another example is popular social networking site Facebook.com.

I can’t purport to speak on the actual financial models behind these actions, but I’m assuming that your thumbs-up on an ad is something that can be monetized as well.  From the user’s perspective , it’s a conflicted action.  Do we like being advertised to?  Are we approving this particular ad?  Are we asking to see more of the same?  Does a click of approval mean we’re interested in this product or service?

The ‘like’ feature is a nebulous thing on its own.  If my friend posts that her car has gotten towed and I ‘like’ that post, does that mean I don’t condone her actions and am satisfied that her car was towed, or is it a symbol of support for her?  However, the real-world analogue of this action comes much more naturally in communication, both verbal and non-verbal.  The confusion here arises when we’ve made this feedback discrete and countable, as opposed to  appropriately complex, complicated, and communcative actions in the non-digital world.

In an upcoming series of blog postings I’d like to illustrate how Exhibit and SMW can benefit from each other. Besides, I show which fundamental problems can be solved by just uniting the power of both tools.

This first entry deals with the usage of Exhibit as a result printer within Semantic MediaWiki. As one of its main advantages SMW offers the possibility to query the data it contains. By just adding simple query strings to a wiki page information scattered across a bunch of articles can be gathered on this single page. SMW relies on semantic annotations which are evaluated while the query is processed.

For instance, the following query string triggers the selection of all pages about cities which are located in the United States. Moreover, the values of the properties population and state are extracted from the selected wiki pages.

{{#ask: [[located in::USA]] | ?population | ?state}}

By default the data is displayed in an ordinary table format what tends to be kind of boring. This is where Exhibit hits the mark. With the help of Exhibit we can get a fancy, well-arranged  and even more meaningful visualization of the data. That’s why SMW is enabled to use Exhibits for printing query results now. All the different views Exhibit has to offer (e.g. maps, timelines, tables) are supported. Faceted browsing is possible as well.

In order to keep the query string as short and simple as possible information SMWs already contain is leveraged. For example, a specification of a property which holds a geographic coordinate is not mandatory, since SMW stores information about value types. The same is true for date values.

Thus, the following query yields the visualization on the screenshot:

{{#ask: [[located in::USA]] | ?population | format=exhibit | view=tiles,tabular,timeline,map | facets=state}}

Query results with Exhibit as result printer

As you can see the Exhibit seamlessly fits the wiki user interface. No additional scrolling is required and the Exhibit doesn’t look squeezed.

All these features work fine and will be part of the next Semantic Result Formats (SRF) release. SRF is a collection of sophisticated result printers which is realized as an extension to SMW.

This first approach of bringing SMW and Exhibit closer together magically opens doors to further applications I’ll refer to in my next blog entries.

The major challenge, she predicted, towards making our digital tools work better for people was the simple fact that people are all different: people have differing needs and different levels of expertise. She backed her view with several studies showing that tools suited for a person’s particular needs and/or levels of expertise generally improves his or her experience with the tool, increasing chances of actually completing task, faster completion times, and less frustration.

Of course, people differ in far more ways than merely needs and levels of expertise. They live in different countries, speak different languages, have different friends, assume different jobs, preferences, strengths, weaknesses, beliefs and values structures and so on. And worse, people are dynamic systems that change from moment to the next.

How can application designers possibly address such complexity when building tools not just for people, but for individuals? Unless one day we have software teams that constantly follow each each person around, study them one by one, and build what is “best” for them, will we never achieve tools that work efficiently for everyone?

A practical solution: Personalize it yourself (PIY?)

One simple approach is to have people personalize their tools themselves. This seems reasonable since individuals are an excellent source of information about themselves.

The problem, of course is that personalizing a tool is yet another thing to do, requires time and effort, and is overally tangential to the original task. For tasks a person performs seldomly, we might expect people to realistically not worry about personalizing a tool. But what about tasks that people perform very often? For example, what about managing e-mail?

The “personality” of e-mail management

E-mail remains huge. Despite the number of tools people have to communicate today, e-mail still remains the dominant overall form of on-line communication. The amount of time and effort that a person spends communicating using e-mail are significant and tangible — a recent study revealed that people spend on average of 7 hours a week writing (composing/reading/organizing) their e-mail. [2]

Given the time and effort spent using e-mail, we would expect to see some degree of personalisation, particularly among advanced computer users. Even as early as 1981, E. Rich specifically cites e-mail as an example where users could benefit from self-personalization strategies:

Consider, for example, a computer program that enables system users to communicate with each other by sending mail messages back-and-forth. The program stores the messages in a set of files and provides functions by which users can read messages, answer them, and so forth. Such systems often allow users to set system parameters to determine such things as which message fields will be displayed when a message is printed. A much greater degree of personalization is provided by systems such as most implementations of the programming language LISP that allow users to specify an arbitrarily complex program that will automatically be executed whenever the user enters the system. With this facility, a user can create his own procedures, alter system variables, or define his own symbols.

– Elaine Rich, Users are Individuals

With advancement comes … uniformity?

When I was an undergraduate in the late 1990s at MIT, I remember that writing scripts (short programs) to automatically handle e-mails was quite a common practice among my friends. Most of these scripts used a tool such as procmail, to match patterns in message headers against a set of predefined rules — which took various actions when particular messages were received. These actions ranged from simple filtering, deletion, foldering, to more sophisticated actions: automatically responding to the sender, forwarding messages to a pager, or sounding audible (and visible) alarms to get the user’s attention. One particularly memorable script written by some electronics hobbyist friends matched the contents of incoming e-mails arriving from reuse@mit.edu, a popular mailing list for announcing laboratory equipment being discarded, against a “want list” of equipment that they needed to complete their projects. A positive match triggered an audible “foghorn” alarm on his hall and caused an LED signboard to scroll the details of the message in the hall’s lounge – including where and when the prize was located – to dispatch as many people as quickly as possible to obtain the desired piece of equipment.

Today, things seem very different. Most undergraduates at MIT either graphical desktop mail clients such as Thunderbird, Outlook and Apple Mail or, increasingly, purely web-based e-mail such as Gmail. Despite the fact that the Athena environment itself has not changed, the most common customizations, if any, rely on standard rule-based foldering features of these popular e-mail clients.

But why? – I could see at least three possible explanations for this trend. It’s possible that people (or specifically their needs) have changed, somehow mitigating or changing their needs with respect to e-mail handling (h0). Another possibility is that tools themselves have changed. Perhaps general-purpose e-mail clients have improved sufficiently to encompass the needs previously addressed by individuals’ personal hacks (h1). Or, perhaps these tools have become more complicated, making them somehow less easily customized, leaving people to resort to various coping strategies (h2). These are three very different possible reasons, and I wanted to find out more.

Do today’s hackers personalize their email handling?

To find out what some of today’s power users did to manage their e-mails, I polled members of MIT CSAIL, who were mostly graduate students, staff, research scientists and professors. Given that these were members of a computer science laboratory, nearly all individuals within the building are expert computer users. I asked these labmates whether any of them actively used any e-mail handling “hacks” beyond what was built-in to their e-mail clients of choice, and for what purposes these hacks were created to serve. I describe the results below.

Twenty two (22) individuals responded to an informal poll I sent via e-mail to members of CSAIL. These responses as well as the original e-mail I sent out can be viewed here.

Respondents who did not use any custom processing: 8 (out of 22) respondent indicated that they did not (or no longer) used any automatic filing features beyond what was available to them in their mail clients. Note that 8/22 (36%) seems a large number of responses by non-customizing respondents considering that the poll explicitly asked for those who actively customized their e-mail handling. This, plus the fact that over 1000 users are subscribed to the particular mailing list, indicates that even among experienced computer programmers/engineers/researchers, relatively few people customize their e-mail handling.

Reasons for not having custom handling solutions:

1. The most commonly cited reason (when given) for not performing custom handling hacks was (6) that the person regularly used multiple email clients on multiple platforms (Windows, Mac, Linux) and mobile devices. In such situations, implementing client-side processing hacks becomes difficult becuase of the need to implement such hacks across all clients is either impossible (with impoverished clients) or deemed too much effort.
2. The second most cited reason (5) was that users have largely switched to webmail due to universal availability (4), and user interface affordances (1) of modern web mail systems.
3. The third most cited reason was that modern mail clients were not as flexible/open to custom processing solutions as old clients.
4. Another reason cited included migration effort, specifically that the effort required to migrate/port hacks to new e-mail systems required more effort than they saved.
5. Two participants mentioned that their previous hacks primarily surrounded spam management and were basically rendered obsolete by standard spam-management systems built into most clients today (SpamAssassin, etc). Interestingly, several other participants still felt that such standard spam management software was inadequate and cited that they still used custom rules to further reduce and manage spam.

Reasons for custom e-mail hacks – Respondants gave a large number of reasons for writing custom e-mail processing hacks. These include:

• Automatic foldering – 5 explictly mentioned the use of rules to automatically folder emails and reduce the number of messages that end up in their main inboxes. Several mentioned the use of websieve to do this foldering at the mail server, so that such foldering would affect all clients they used.
• Multiple account management – 3 mentioned the use of scripts to help with the management of multiple-email accounts; 2 explicitly mentioned the use of scripts to simplify handling of corporate versus personal e-mail.
• Forwarding to mobile/notifications – 3 mentioned the use of selective forwarding to mobile phones, while 2 explicitly mentioned the use of scripts to enable notification when certain important messages arrived.
• “Reflecting” e-mail to others – 2 mentioned the use of scripts that automatically copied others, acting as “client-side” mailing list.
• “Procrastinating” e-mail – 2 mentioned the use of mechanisms for having e-mails re-sent to the user (to remind him or her) at a specific later date. One respondent called this the “procrastinate” function, which he tied to a single keystroke for his mail client, nmh. Another wrote a webmail extension to provide the same functionality, supporting procrastination until arbitrary later points in time.
• Spam reduction – 2 mentioned the use of custom rules/techniques reduce spam (beyond a standard spam filtering techniques), such as challenge-response filtering.
• Archiving, Backup and Archive management – 2 mentioned the use of scripts for archiving email, backing up email inboxes to disk, and searching email archives.
• Other uses – Other participants mentioned using custom scripts for providing vacation auto-responding, off-line email access, mass-mailing (e.g., like client-side mailing lists) and attachment managements.

Respondent #17 expressed his dissatisfaction with standard e-mail filtering schemes:

i have hundreds of filters set up in tbird to auto- file my email into folders. it was a big pain, because tbird filters don’t have enough expressiveness. for example i have to say “From X” or “To or Cc X” (two predicates) to catch everything to or from X.

there’s also no easy way to express priority, for example that an individual message from a student should go to a different place than a group message. and there’s no way to capture the manual filing i do, i.e., watch me file, infer a rule based on the headers and the filing action, and put that rule in place.

all of these would be nice to have in a better suite of email management tools.

Conclusions

Revisiting our hypotheses from before, based on our responses we can see that in fact, all three hypotheses were somewhat true. With respect to (h0), it seems that users needs have indeed changed: for example, many users now need to access e-mail from multiple accounts, on multiple devices (running different operating systems and clients). These needs made customization (h2) more difficult, because clients are not all capable of the same customizations. Furthermore, modern graphical clients, while better for novice users, are less flexible, change rapidly and thus are not as conducive to customization as older command-line and terminal-based mail clients (h2). But they do some things better (h1), including spam filtering, and offer simple customizations such as keyboard macros and rule-based foldering.

Overall, these uses of personal e-mail handling indicate the presence of unmet needs in current e-mail processing tools among expert users. The question becomes whether the next generation of e-mail tools should seek to support al of these functions, or to return to a state where they can support greater personalization — letting users better fit their client to their exact needs.

References

1. Elaine Rich: Users are Individuals: Individualizing User Models. International Journal of Man-Machine Studies 18(3): 199-214 (1983)
2. http://news.digitaltrends.com/news-article/14823/survey-looks-at-hours-spent-managing-email
3. CSAIL survey results: http://people.csail.mit.edu/emax/blog/email-study.html

At runtime, firebug and Javascript Debugger will catch Javascript errors you need to worry about. But what it you’ve made a syntax error, and that Firebug completely ignores your js file… If you want to avoid hitting Ctrl-z until you find where you made the mistake, or worse, re-read line-by-line your 2000-lines-of-code script, here’s the solution: http://jslint.com

In addition to errors, it will indicate implied globals (just to make sure you didn’t forget that “var i = 0;”, and that your variable i keeps changing values event inside a loop iteration because it calls another function that has also declared i as a global…

Last but not least, if you’re working on copyrighted code and you don’t feel safe about sending it to a remote server: As of today (Nov 11th 2008) all the processing is done in your browser (you can check with firebug: no network traffic after the page has loaded).

Wouldn’t it be a cool feature if firebug and other debuggers would just incorporate the JSlint code, in order to signal those kind of static errors.

Suppose that you’re about to carry out an web-based experiment (called tutor, for instance), and that you don’t want to setup a whole new machine for that, because you already have a machine with apache mysql etc… installed (ex: sacha1.csail.mit.edu)

On the other hand, it would be nice to tell your users to visit a webpage that has a name relevant to your experiment (say tutor.csail.mit.edu, instead of http://sacha1.csail.mit.edu/experiments/tutor for instance !!!).

With webdns, nothing’s easier: just visit https://webdns.csail.mit.edu:1443/cgi-bin/webdns.cgi, choose a to add new hostname (i.e: tutor.csail.mit.edu) and give it the same IP address as the one of your existing server. Et Voila: Less than an hour later, you have the tutor.csail.mit.edu hostname pointing to your machine !

The story goes even further: You can Tell apache (ot twisted etc…) to display a different site depending on which url was used to reach your computer…

After your experiment is over, you can use webdns again to get rid of the DNS record you used, so that this way the csail.mit.edu domain name doesn’t get polluted with useless stuff.

http://www.google.com/views?q=olympics+view%3Amap&esrch=RefinementBarTopViewTabs. They have used a  graphical framework that reminds me of exhibit. Interesting that they haven’t explored faceted browsing (for now, still a single search box). On the other hand, within a view you can adjust the lens (i.e: show only dates). Would that be a cool feature to add to exhibit ?

I’ll cover three things in this posts: labels, classes, properties. This post assumes the following three namespaces:

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>
@prefix xsd: <http://www.w3.org/2001/XMLSchema#>

@prefix ex: <http://www.example.org/lightweight_classes#>

And it uses the Turtle syntax.

Labels

In the last post I said an important rdf property was rdf:type, which says that the <subject> is an item of type <object>. Another important property is rdfs:label (note that it is in the RDFS namespace, not RDF). rdfs:label is RDF’s equivalent of Java’s toString() method. If you want to give some resource a human-readable name, you should set this by saying

<some object> rdfs:label "The Human Readable Name"^^xsd:string .

It is customary among people who hand-write Turtle files to put the label definition as the last property on an object. That way if an object definition is more than one screenful tall, the person knows they can look at either the top line of the definition (the resource) or the bottom line of the definition (the label) to remind them what they’re looking at.

Classes

You can declare a class like this:

ex:MotorVehicle   rdf:type   rdfs:Class ;
                 rdfs:label  "Motor Vehicle"^^xsd:string .

Classes are usually given a capital letter in their local name. (The local name is the portion of the URI that comes after the namespace. So URI ::= Namespace + LocalName).

You can write a subclass like this:

ex:Van     rdf:type         rdfs:Class ;
          rdfs:subClassOf     ex:MotorVehicle ;
          rdfs:label        "Van"^^xsd:string .

And, as in the previous post, you can say that an object is a type of class by saying:

ex:aCar     rdf:type         ex:Van ;

Notice how the same property defines a class and also declares class membership. Also know that you can make as many class assignments as you want — multiple inheiretance is fine in RDF.

Properties

The Basics

You can declare a property like this

ex:topSpeed          rdf:type   rdf:Property ;
                    rdfs:label  "Top Speed" .

It is customary to start of the local names of properties with a lower-case letter.

Subclassing Properties

Just like you can make subclasses, you can subclass properties like this:

ex:driver          rdf:type             rdf:Property .

ex:primaryDriver   rdf:type             rdf:Property .
ex:primaryDriver   rdfs:subPropertyOf   ex:driver .

Domains and Ranges

You can also specify the domains and ranges of properties:

ex:age   rdfs:domain   ex:MotorVehicle .
ex:age   rdfs:range    xsd:integer .

but this is dangerous terrirory with RDFS, and IMHO it sort of breaks the nice notion of edges of the graph being able to connect any node to any other (but of course, now we’re in object modeling territory instead of graph land).

The reason that RDFS domains and ranges are dangerous is that if a property P has a domain of C, where |C|>1, and a tuple states <X P something>, then every class c in C must apply to X. The same goes for ranges (with appropriate modifications to the previous sentence).

Here is an example of why you have to be careful. It is perfectly reasonable for both a person and a car to have an age, but if you say:

ex:age   rdfs:domain   ex:MotorVehicle .
ex:age   rdfs:domain   ex:Person .

And then you say

ex:mycar   ex:age   "15"^^xsd:integer .

Then you have just stated that your car is both a MotorVehicle and a Person! Probably not what you wanted to say. Of course, you will only feel the ill effects of this when you turn on an RDFS reasoner, but that is a pretty common thing to do because it is lightweight and gets you the goodness of class and property inheritance.

—————————-

That’s about it. Much of the example RDF on this post was borroed from the Turtle version of the W3’s RDF Primer, so if you want more information you can look there.