Tag: research

A few weeks back Ben and I met at Three Monkeys for a chat about work and life in general. Inevitably, our discussion turned to pervasive computing. Ben spoke about the idea of seamfulness as opposed to seamlessness, which I found interesting. He’s written a short blog entry about it. I think the quote in his blog entry is from Elizabeth Goodman’s blog. Here’s what she said:

Ubicomp-the-conference and ubicomp-the-field are frustrating because they promise the impossible. The promise of computing technology dissolving into behavior, invisibly permeating the natural world around us cannot be reached. Technology is, of course, that which by definition is separate from the natural; it is explicitly designed that way. Technology only becomes truly invisible when, like the myriad of pens sold in Japan’s department stores, it’s no longer seen as technology at all. Deliberately creating something ‘invisible’ is self-defeating. I can think of few recent technologies as visible to the public as RFID, no matter how physically ‘invisible’ it might be.

Yet again, confusion reigns supreme in the UbiComp debate. Much of this confusion stems from the notion of invisibility and the relative importance conferred to that concept. UbiComp doesn’t seek to make all technology invisible, no matter what it’s critics believe. What it does try to do is hide those aspects of technology that needn’t be visible to humans. Take the RFID example. For many applications, RFID is a better solution than older technologies like bar code scanners because it does away with user interaction in a situation where user interaction is not required. When Elizabeth Goodman talks of RFID being highly visible despite its small size, I can only assume she means it has gained wide exposure in the media and in research publications. But this is talking about a different kind of visibility! Any technology, when first deployed, is bound to attract attention. It’s what happens after the hype dies down and the novelty wears off that counts. The fact of the matter is that RFID is closer to being invisible than bar codes and the other technologies it will replace. That can hardly be argued with under the assumption that RFID works as it is supposed to (and given the uptake of the technology by logistics companies, e-ticketing systems and the like, it appears that it does work well for many applications). Furthermore, this talk of having computers blending with the natural environment is a complete red herring, designed to draw your attention away from one of the real goals of ubiquitous computing, which is simply to release users from explicit interaction with technology as far as it is possible and sensible to do within certain applications of technology. The extent to which this is possible and the degree to which it remains sensible is determined by the users themselves.

It strikes me that it is often those criticising UbiComp whom attribute the most marvellous traits to it. Of course the more outlandish the "promises" of UbiComp become, the easier it is for its critics to knock it down. Ubiquitous computing is just that: computing that has moved beyond the desktop and which becomes integrated with many aspects our everyday lives. The technologies that will enable this in a way that is satisfying to users are subject to ongoing research and debate within the UbiComp community.

Slowly but surely, some technologies are receding to the background. This will not happen for all computer technologies: users gain value from many technologies precisely because they are visible and their boundaries are well-defined. But by the same token, there is a large category of technologies which the user need not be conscious of. RFID is an example already given, but there’s also simple things like sensors that switch the airconditioner on when you arrive home from work, or the software that seamlessly re-routes a telephone call to an appropriate device nearby, doing away with the need for a human operator to redirect the call. These are all examples where their users do benefit from their invisibility and seamlessness. It will be users (the market) who decide the extent and rate at which technology recedes to the background and becomes part of our work, home, shopping and social environments, but it will certainly happen for some technologies.

For sure, seamfulness has its place too. Ben gave me this really cool example. There’s a game played with GPS- and Wi-Fi-enabled PDAs. There are two teams, and each team has a safe. The playing field is randomly seeded with virtual coins that are visible on the PDA screen. The object of the game is to move as many coins as possible from the playing field to the safe. You collect a coin by moving to its GPS coordinates. Coins can be stolen in transit (kind of like a mugging). But Wi-Fi suffers from gaps in coverage, especially when there are buildings and other objects around. The game works because players can take advantage of these black spots to sneak a coin back to the safe without getting mugged. Upon collecting a coin, a player can jump into a black spot and then emerge from it at a point closest to the safe. Thus the seams of the Wi-Fi technology can actually be of some value in certain applications. However nobody woud dispute that it is also highly useful to a much larger range of applications when it maintains invisibility and seamlessness, showing that there’s a place for seamlessness and seamfulness in the future of computing.

Today was the last day at the DSTC for one of its icons, Dr. Kerry Raymond (Distinguished Research Leader, Adjunct Prof., ITEE). All the best in the future Kerry!

I’ve just returned from Melbourne where I presented a paper at The 9^th International Conference on Knowledge-Based Intelligent Information & Engineering Systems (KES 2005) and visited some relatives. The trip served to reinforce how much I like Melbourne. The conference venue was quite spiffy (Hilton on the Park), though there was lots of audio interference between some of the rooms. Conference attendees who registered as students (like me) didn’t get a copy of the proceedings in hard or soft copy (although I’m glad I didn’t get the hard copy, which came in four LNCS volumes), nor did their fee provide entrance to the cocktail party of conference dinner. This turned out okay because I found the really nice little restaurant that Karen and I went to last time (corner of Little Collins St and Block Place). There was an awesome mariachi band playing. Those guys totally rocked. The food was great too.

I saw the part of the National Gallery of Victoria that Karen and I didn’t get to see last time. There was a temporary exhibition of about 100 pieces from the Rijksmuseum in Amsterdam, but I’d already seen them all with Karen when we visited Holland earlier in the year. There was also an exhibition of some of Albrecht Dürer’s sketches. I was impressed by some of the pieces the gallery has managed to procure for its permanent collection. There were several paintings by Rubens (though Rubens was so prolific that his pieces seem to be everywhere) and Rembrandt as well as a Monet.

All in all a good trip. I didn’t get to meet Rhys because he’s galavanting around South East Asia on business again.

My thesis has come back to the thesis office. Jaga tells me the review was good and that there are only minor corrections to make.

These days I am invariably at odds with Ben’s take on ubiquitous computing and related issues, and the trend seems likely to continue.

In On Context, Ben argues that we still don’t have a clear understanding of what context, among other terms, means. Come off it, really. We’ve known what context means for centuries, and what it means within computer science for decades (which, when one looks at it, is not substantially different from what it means in the ordinary world). John McCarthy, helped to formalize context over a decade ago – a remarkable feat, and one that would be all the more remarkable if the meaning of context was still unclear at that time. McCarthy has also looked at formalizing common sense, a term that I believe is much harder to define than context. The problem is no longer figuring out what context is or what it means, it is understanding how to monitor (sense) it, model it, derive it, and use it to do something sensible even in the face of imperfect information. These are hard problems, and it strikes me as a distinct possibility that people are still talking about what context is because they are avoiding the difficult problems involved with utilising it. Not only do we already know what context is, we know what it is useful for; all you have to do is observe the way in which a typical conversation proceeds between two people and see how they fill in the blanks in the absence of explicit information. Or, the next time you see a person standing in the middle of an intersection wearing a blue uniform and waving their hands about in various ways, observe the way in which you and other motorists respond. It is unlikely that any motorist would make a call to the nearest hospital for the mentally ill. But if you saw a similarly dressed person making those gestures in the middle of a football field, that phone call might be made. Why? Context is the element that allows us to differentiate between these two scenarios or situations. In the words of Dey:

Context is any information that can be used to characterize the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves.

So how does an application decide what is relevant, without being pre-configured with a static set of entities that the programmer/administrator/user has deemed to be relevant to the scenarios in which the application will be used? Now there’s a real research problem. I think this is the gist of what the IFTF article to which Ben refers was getting at – that context is mutable and hard to track, not that the term itself is hard to define.

The meaning of context, I think, is well understood, and the fact that there are many slightly different definitions of context floating around in computer science does not imply otherwise, just as there are many ways of describing the term "light-bulb". So I have no hesitation in adding another definition to the mix. This definition approaches context from a more functional point of view:

Context is the implicit environmental parameter that can be used to disambiguate a statement or an action.

That goes for statements made in natural languages and programming languages. For instance, in an application, we may wish to send a message to somebody. Perhaps the only formal parameter provided by the user is the contents of the message. It is then up to the application to figure out who the message is supposed to be sent to and how that message is supposed to be sent. As mentioned above, knowing what information is relevant to the decision making process, and then actually utilising this information is the tricky part.

Context has been defined to death, and just in case it wasn’t dead already, I made sure by throwing another definition at it. The last thing we need is more papers purporting to confer a better understanding of context unto the computer science community. What is needed are solutions to the problems of modelling, incomplete information, filtering, scaling and the derivation of context information from existing context information. Basically we need to figure out how to remove the current limiting factors so that it can be applied more generally and with predictable results that make sense to the user.

Today I modified my query testing application so that it doesn’t require access to the Internet and uploaded it onto my phone via a data cable. The demo is not very spectacular. It reads in a query in the form of an XML file and an advertisement in the form of another XML file, and sees how closely they match. It reports back the total number of components in the query, the total number of components in the advertisement, and the number of query components that match the advertisement. An exact match occurs if the number of matching components is equal to the number of components in the query. The query can have arbitrarily complex expressions, and the expression language has some built-in functions. Here’s an example:

 <?xml version="1.0" ?>
 <component name="printer">
   <component name="resolution">
     <component name="dpi">
       100     </component>   </component>
   <component name="location">
     <component name="latitude">
       <exp>
         <![CDATA[(that < 44.5) && (that > 31.1235) && (that != 33.3)]]>
       </exp>     </component>
     <component name="building">
       <exp>
         ![CDATA[that.startsWith("GP")]]>
       </exp>
       <component name="level" value="6">
         <component name="room">
           <exp>
             <![CDATA[that == 633]]>
           </exp>
         </component>
       </component>
     </component>
   </component>
 </component>

I hope that shows up as it is supposed to. By the way, this is a completely made up example. The component names and values aren’t actually supposed to mean anything. This example has three expression components if I can count properly. These are the CDATA things that are surrounded by an <exp> tag. The expression language is dynamically typed (i.e. it figures out whether it’s dealing with a string, integer, float or boolean as it goes), and the operators take on different meanings depending upon what the types of the operands are. For example "<&quot behaves differently depending upon whether the operands are strings or numbers. The keyword that stands for the value in the advertisement. Therefore the expression that == 633 is equivalent to using the value attribute. So in the example above we could have simply specified <component name="room" value="633"> instead of using an <exp> element. An application would either have some predefined queries or would build these queries from some simple user input. So don’t go thinking that the user has to type in all this gobbledygook.

The best news of all is that the example actually runs several seconds faster on my phone as compared to the emulator for the phone. Class loading is what takes the longest.

I also worked a bit on the journal paper today. I think it’s ready to be shown to Ted and Jaga.