Categories
Innovation

Citemine: a new way to do peer review and publishing

As you probably know, I’m a ubicomp researcher by day. However, on the side, NICTA‘s allowed me to allocate some of my time to develop a new way for researchers to review and publish papers. We’ve deployed a very early proof-of-concept of our idea called Citemine. We think Citemine has several nice properties, including a potentially more meaningful measure of research quality than existing indicators such as h index and raw citation counts. You can read all about the underlying mechanism in Citemine here. Until we deploy a feedback mechanism for papers, please leave your comments about Citemine at the official Citemine blog.

Note that we’re experiencing a few difficulties with our Citemine production server environment, which means slow page loads from time to time. And it’s clearly lacking polish, but hopefully it serves its purpose as a proof-of-concept so that you can get a feel for what it’s all about. But please do read the paper. I’ve been told it’s a fun read.

Categories
Innovation

Thanks for your help

To those who responded to my plea for help by leaving a comment or responding out-of-band, thank you very much. We’ve settled on a name for our application, purchased the corresponding domain names and filed a trade mark application.

Will keep you posted as things evolve further. But just to give you an idea, we’ve already iterated through several “alpha” versions and expect to have a public beta ready by the end of February. Stay tuned for an explanation of what the service actually does.

Categories
Innovation

I need your help

Valued readers, would you be so kind as to lend 15 seconds of your time completing the following task for me, your humble host. I ask that, from among the five names below (which, for various reasons, all begin with the word “cite”), you choose the one name that you believe sounds the best. The one that rolls off your tongue most easily. The one that you think is, well, coolest. Please do not bother yourself with trying to guess the meaning of the name, or the purpose of this exercise (though many of you will no doubt have a good idea). I am after your immediate gut feeling response. Please leave your response as a comment on this post.

  • Citemind
  • Citecloud
  • Citefish
  • Citecrowd
  • Citemarket

I would be more than grateful if you could point your friends and colleagues at this blog entry, particularly if they are involved in writing research manuscripts.

Thank you!

Categories
Innovation

Ben on ubicomp: spot on

True:

Often we seem to use the term Ubiquitous Computing to mean “computers everywhere” as if just having the hardware all over the place was a worthwhile end in itself.

But maybe a better meaning is “computing available when you want it in a way that makes sense for where you are and what you’re doing” which is much harder to do than “computers everywhere”.

Categories
Innovation

Augmented reality on your mobile: the next big thing?

It’s been a while in the making, but augmented reality on your mobile is just about here. And by that, I mean that these applications are available for your mobile phone, and it will only be a matter of time before they gain critical mass. So what am I talking about?

In the research space, among others I can refer you to iCam (2006) and MARA (2006) from researchers at Georgia Tech and Nokia respectively. iCam allows the placement of virtual sticky notes on objects in the physical world, through a mobile device. This is neat, since the sticky notes only appear to those whom you want to see them. A limitation of iCam is that, while placement of these sticky notes is very accurate, it only works indoors. MARA overlays information about the real world (and even the people in it if information about objects is being streamed from a central server) in real time.

The there’s this concept device from petitinvention, which takes the idea a few steps further. The user can see information about buildings and locations overlaid on the video stream from the mobile device’s camera. But the same tool can be used to select text from a piece of paper (like a newspaper). Essentially, it’s an augmented reality search tool.

In the commercial/start up realm, a couple of companies have been creating a bit of buzz. First there’s Enkin. Enkin has been developed for the Google Android mobile phone platform. It enables users to tag places and objects on Google Maps, and then to see these tags overlaid on the real world as you walk around with the phone. My favourite is Sekai Camera from Tonchidot. I’m not going to explain it. Just watch the video below. But note that even products on the shelves in shops are tagged in the virtual world and overlaid on the real world. And it’s a very social application.

There’s probably still all sorts of hurdles to overcome, but what a great presentation.

Categories
Random observations

I’m a Diigo convert

Today I discovered Diigo. Diigo is a bookmarking tool like del.icio.us, only, in my opinion it is vastly superior. Instead of just bookmarking, you can select a chunk of text in the page, and attach a sticky note to it. When you return to that page later on, there’s your sticky note waiting for you. Hugely useful for doing research. Yes they’re in direct competition with del.icio.us, but they’re also smart enough not to make you completely ditch del.icio.us: you can easily set up your Diigo account so that any bookmark you save to Diigo will be cross-posted to your del.icio.us account.

Check out my Diigo profile if you’re interested.

Oh, and this blog entry was written from within Diigo.

Categories
Innovation

Startup: an explanation

It’s probably time to come clean about my recent spate of posts on startups, Ruby, Python and so on. Well, there are a few things about peer review and publishing in the realm of academia that I think could be better, so I tried to figure out an alternative process that retains the benefits and overcomes some of the problems of the current system. We think we’ve done that, and it turns out that I wasn’t the only one who thought that things could be a lot better.

NICTA has provided pre-seed funding in the form of a couple of commercialisation grants to implement this new way of doing things. I’ve hired a top notch graduate software engineer (who’s been working with me as a student for the past year and a half on unrelated things) to help me deliver alpha and beta versions of this system over the next six months or so. For this project, we’ll be working in startup mode; I’ll be making every effort to provide a small company atmosphere for the engineer and others who join the project.

It turns out the solution to the problem can also be applied to (web) search, since it is essentially a nice way of ranking documents within communities. I can’t go into the details of the solution here, but I can list some of the things that I (and other researchers, as it happens) think could be better.

  • Traditional peer review requires that authors trust reviewers to act in good faith – reviewers are not required to “put their money where their mouth is”, so to speak;
  • Related to the above, traditional peer review gives no real incentive to support the good work of a group competing scientists;
  • Related to the above, traditional peer review provides no real incentive not to support the poor work of a colleague or friend;
  • Traditional peer review gives no tangible recognition to the many hours of reviewing that scientists do – reviewing is just something you’re expected to do for the good of the scientific community;
  • Traditional peer review gives no incentive to authors to self-review their work before submission, meaning reviewers get burdened with too many bad and mediocre papers;
  • Metrics such as H-index and G-index are somewhat arbitrary, do not give a direct indication of the esteem with which scientists are held by their peers, and are not indicative of the current capacity of a scientist to produce good work;
  • Citation collusion is too easy to accomplish, but difficult to filter out when calculating the above metrics;
  • Not enough cross-fertilisation between fields, largely because closed communities are too common; and
  • The publication process is too slow, often taking years for a journal paper and months for a conference paper.

These are some of the problems that researchers say they can see with the current way of doing things. We think we can claim that our idea solves many of these problems. For example, under our system, which we are calling PubRes for the moment, citation collusion is futile. Under PubRes, you’d also be silly to lend support to a paper that you know isn’t very good (even if it is written by a colleague), and you’d be silly not to lend support to a good paper (even if it is written by a competing group of scientists or your worst enemy). There are some things we haven’t solved, like honorary authorship and ghost authorship, but these are problems I’d like to investigate in the future. Although I can’t reveal the details here, I can say that the underlying mechanics of PubRes are no more complicated than traditional peer review procedures (and probably much less complicated), but it is a major departure from how things are done now. I can also say that the feedback we’ve got from people we’ve explained it to has been overwhelmingly positive, which is the main reason I’m still pursuing this.

NICTA are making sure we do this properly, so some of the grant money is being spent on figuring out the structure of the academic publishing market. We already know that the top three academic publishers had combined 2007 revenues in excess of $US3 billion, but that doesn’t say much. We’re currently doing some much deeper market research to get a better understanding of the domain.

It’s important to note that what we’re doing is completely different to all known attempts to bring science to the web. PubRes is not another CiteULike or Connotea. It’s not another arXiv.org. It’s not like PLoS One or PubMed Central. It’s different to ResearchGATE and Science Commons. While our implementation may contain elements of these existing tools, PubRes is a fundamentally new way of getting your research published, and it’s a new, much fairer (we think), more direct way of rating scientists and the papers that they write. One of our aims is also to make the whole reviewing, publishing and reading cycle a lot more fun.

With any luck, a public beta will be available early next year. Oh, we think we’ve settled on Ruby and Ruby on Rails for the web tier, and no doubt there’ll be some AJAX stuff in there to pull off a few nifty browser side features we have in mind. Stay tuned.

Categories
Random observations

Rediscovering closures and nested functions

When you’ve spent years coding pretty much everything in Java, it’s hard to break out of the Java way of doing things. It means that you tend to forget that other languages might have things called closures, for example. Here’s how a closure looks in Python:


lambda x:dosomethingto(x,anothervariable)

The neat thing is that this closure can be passed around like a first class object. Also, anothervariable, bound in the outer scope, is accessible to the lambda expression when it is invoked later. You can do stuff like:


if isinstance(somevalue, int) or isinstance(somevalue, float):
  isfunny=lambda x:log(x)>somevalue
else:
  isfunny=lambda x:isalpha(x) and islower(x)

funnyitems=[item for item in mylist if isfunny(item)]
seriousitems=[item for item in mylist if not isfunny(item)]

Sure there are other ways to do the same thing. But this is arguably more elegant.

There’s also nested functions, which are kind of like closures. Rather than contriving an example, I’ll give one from the book I’m reading, Programming Collective Intelligence. In chapter 8, a crossvalidation function is defined. Forgetting the specifics and purpose of this function, just know that the crossvalidate function returns low numbers for good solutions and high numbers for bad solutions. Earlier in the book, we’d already been introduced to optimisation problems and cost functions. The cost functions take a single argument, which is a potential solution to be costed. The crossvalidate function takes a bunch of parameters, so for this and other reasons it can’t be used directly. But you can do something like this:


def createcostfunction(algf, data):
  def costf(scale):
    sdata=rescale(data,scale)
    return crossvalidate(algf,sdata,trials=10)
  return costf

So now your costf function knows about algf and data, despite not having them as parameters. That is, the bound variables to algf and data are available to costf when it is called at some later time:


costf=createcostfunction(knearest,mydata)
annealingoptimise(wdomain,costf,step=2)

So when annealingoptimise eventually invokes costf, costf has access to knearest and data. That is the bindings of algf to knearest and data to mydata live on after the execution of createcostfunction completes. Cool.

Categories
Innovation

Another tangible user interface

The GroupLab at the University of Calgary has published a technical report describing Souvenirs, a tangible user interface for sharing digital photos in the home environment. It is very similar in spirit to Bowl, which I’ve previously blogged. Souvenirs will be formally published in the Proceedings of the 2008 ACM Conference on Designing Interactive Systems.

Souvenir - the tagged rock and the image it is associated with

Image credit: Nunes, M., Greenberg, S. & Neustaedter, C. (2007) Sharing Digital Photographs in the Home through Physical Mementos, Souvenirs, and Keepsakes. Research Report 2007-875-27, Dept Computer Science, University of Calgary, Calgary, Alberta, Canada T2N 1N4. July.

Categories
Innovation

Finding a human need

I’ve been reading over old ubicomp papers in preparation for a new project at NICTA. So it was that I found myself reading “Charting Past, Present, and Future Research in Ubiquitous Computing“, by Gregory Abowd and Elizabeth Mynatt (whom, incidentally, should surely be listed among those ubiquitous computing researchers who inspire me – particularly Abowd, whose work I’ve followed since my Honours year in 2000, and whose books were often referenced in the HCI course I took a couple of years before that). One of the most important passages in that paper, to my mind, was tucked away in section 6.1.1, Finding a Human Need (the emphasis is mine):

It is important in doing ubicomp research that a researcher build a compelling story, from the end-user’s perspective, on how any system or infrastructure to be built will be used. The technology must serve a real or perceived human need, because, as Weiser [1993] noted, the whole purpose of ubicomp is to provide applications that serve the humans. The purpose of the compelling story is not simply to provide a demonstration vehicle for research results. It is to provide the basis for evaluating the impact of a system on the everyday life of its intended population. The best situation is to build the compelling story around activities that you are exposed to on a continuous basis. In this way, you can create a living laboratory for your work that continually motivates you to “support the story” and provides constant feedback that leads to better understanding of the use.

Designers of a system are not perfect, and mistakes will be made. Since it is already a difficult challenge to build robust ubicomp systems, you should not pay the price of building a sophisticated infrastructure only to find that it falls far short of addressing the goals set forth in the compelling story. You must do some sort of feasibility study of cutting-edge applications before sinking substantial effort into engineering a robust system that can be scrutinized with deeper evaluation. However, these feasibility evaluations must still be driven from an informed, user-centric perspective—the goal is to determine how a system is being used, what kinds of activities users are engaging in with the system, and whether the overall reactions are positive or negative. Answers to these questions will both inform future design as well as future evaluation plans. It is important to understand how a new system is used by its intended population before performing more quantitative studies on its impact.

It strikes me that too few ubicomp research groups heed this, seemingly obvious, advice, including our own. Though we might occasionally attempt to build a story, it is not often compelling, and I’ve read far too many papers that suffer from the same problem (caveat: I specifically exclude Karen‘s work from this blunt introspective analysis because her work is typically very well motivated, and compelling; and she read the paper I’ve just quoted early on in her Ph.D. and took note of it). I don’t think it’s a coincidence that the most successful ubiquitous computing researchers have taken this advice to heart. I want to make sure that the new project at NICTA does do these things properly.