Artificial Intelligence as defined by Nick Carr

Nick Carr has a short post here marking the occasion of Facebook's one billionth member.  He goes on to talk a bit about some work at Google on neural nets, but then includes this gem on artificial intelligence:

Forget the Turing Test. We’ll know that computers are really smart when computers start getting bored. If you assign a computer a profoundly tedious task like spotting potential house numbers in video images, and then you come back a couple of hours later and find that the computer is checking its Facebook feed or surfing porn, then you’ll know that artificial intelligence has truly arrived.

It's a short post and a good read.

FLAME, no, not that one

Asmat Noori, who leads the IT Operations team at ICPSR, pointed me to this the other day:

http://www.msnbc.msn.com/id/47590214/ns/technology_and_science-security/#.T8Tg67_wPx5

Unlike our FLAME, which we hope will be a benevolent collection of built and borrowed systems, this:

Flame appears poised to go down in history as the third major cyber weapon uncovered after Stuxnet and its data-stealing cousin Duqu, named after the Star Wars villain.

So I think it wins the award for the Dangerous-but-kind-of-cool Flame.

Zombies as a pedagogical tool

This is what we should be doing with the OLC:



Analyze this dataset to find out who is the most likely to contract the virus.

Use GIS to plot a path to safety, bypassing the areas most likely to be zombiefied.

And maybe some funding via Kickstarter too boot?

How to read thousands of floppies

This is pretty cool.

Dead On Annihilator Superhammer

I can see all sorts of good uses for this.  Everyone machine room should include one.

In addition to helping with routine maintenance, I think this would also be perfect for any future Zombie Apocalypse.

UnDead On Annihilator Superhammer?

Thanks to Cory and the gang at Boing Boing for pointing this out.

This is the sort of thing that we should be giving away at conferences with a nice ICPSR logo on it.

Stop using Word!

I felt a rant come over me this week....


Hey, you!  Yes, you!  You know I'm talking to you.


I tried to look at that meeting agenda you sent me.  You know, the one that you sent as an email attachment, and where the attachment is a Word document. But because I was using a web browser to access my Exchange email account, the browser won't show me the attachment unless I was to right-click on it and save it first.


And I was reading this on an iPad!  Sheesh.


So, you know, that meant that I didn't look at the agenda until this morning when I got back into the office.  Oh sure I could have made the time to boot up a Windows machine to try to get to web mail that way, but really.


So when I did open this thing, I found this agenda:

1. Introductions
2. Problem statement
3. Brainstorm solutions

And this couldn't just go into the message as text?

Oh, wait, here comes another one.....

You over there!  Yes, you, the guilty-looking one.


I was looking for the policy on Widget Transformations yesterday on our CMS.  I knew we had a policy because you made me go to all of those policy meetings.  (I wasn't sure at the time that we even needed such a policy, but there you go.)


So I was searching and browsing and clicking and scrolling.  And searching.  And searching.  No luck.


So I finally got so frustrated I asked Fred if he knew where it was.  He found it right away.  (He had it bookmarked.  Good ol' Fred.)


It was a Word document.


Don't you know that our CMS is really lame and it doesn't search these things?


But the worst part is when I opened the policy document.  I figured that it must have been done in Word since it had a lot of extra fancy content.  But here's what I found:

Widget Transformation Policy

It it the policy of ICPSR that no widgets should ever be transformed.

And that was it.


This couldn't just go into the CMS as text?

Whew.  Feeling much better now.

But I wish I had a nickel for every time I couldn't find something or read something because it was in Word, and where it was something very plain and very simple.

Customer service, Zingerman's style

Our parent organization, the University of Michigan's Institute for Social Research (ISR), is working with the training component of the Zingerman's family of companies - ZingTrain - to build a customized training module for use at the ISR.  The focus is, of course, on delivering excellent customer service, and I had the opportunity to attend a session led by two ZingTrain consultants.

I don't want to give away too much of their "secret sauce" but I found their interaction with the group engaging and informative.  I almost used the word "presentation" but that feels wrong; it really isn't a monologue whatsoever.  And there are no Powerpoint slides in sight.  As you might expect the ZingTrain folks shared some tips and techniques about how they build the right culture and right processes.  And they brought goodies from the Bakehouse!

I started to think about some of the tips and techniques I've learned to use in the technology business over the years.  In this realm an awful lot of the interaction with others takes place electronically, and so one doesn't have all of the visual cues and tonal cues one normally can use in conversation.  For example, how do you let someone know that if the solution you have offered does not work, you want and expect the person to let you know so that you can keep trying to solve the problem?  How do you let them know that you will own the problem until it is solved?

One easy way, of course, is to be explicit.

If that doesn't do the trick, please let me know.  I have a few other ideas we can try.

By asking the person to return and letting them know that "we" can try some other things, it shows that one is engaged.  It lets them know that this is the start of a conversation, not the end of one.

On the other hand, I will often see people write this instead:

Hope this helps.

I know people often write this with the best of intentions, but consider how people may read it.  It sounds like the conversation is over.  "Here, try this.  I hope it works.  But if it doesn't, it's your problem, not mine." There's no invitation to come back for more advice, more assistance, more analysis if the issue hasn't been resolved.

And that's my customer service tip for the month.

Hope it helps. :-)

Tech@ICPSR takes another holiday

Dear Loyal Readers:

We return to our normal antics later this week.

Signed,

Tech@ICPSR

Tech@ICPSR takes a holiday

As far as the University of Michigan is concerned, today is Christmas Day.  (I know this.  It says so on my timesheet.)  Tech@ICPSR had too much egg nog and is taking the day off.

Google Music keeps the tunes playing

I started using the new Google Music production service.  I hadn't explored Google's previous offering, the Music Beta, all that much, but decided the time was right to dip a toe into the water.

The service has a lot of similarities to iTunes, of course, except one's library is in the cloud rather than on a PC (assuming one isn't using Apple's iCloud).  Google gives one free space to store 20k songs.  I'm using about 1% of that quota so far.

I like the idea of having a copy of our music in the cloud as an additional backup (or preservation copy), and it is also nice being able to use a standard browser window to manage and play the music.  One complaint I have about iTunes is that because it is conventional desktop software, one has to update it from time to time.  And this is somewhat more burdensome if one has to switch from a "standard" type of login on Windows to one with administrative rights, and then switch back again.

Google provides a tool which will copy music from one's existing storehouse (mine was an iTunes library).  The tool worked well for this purpose, and it did NOT require any administrative rights on my home WinXP (I know, I know) to download, install, and execute.  I started the copy one evening, and some 400 songs had been copied into Google Music by the morning.  One feature request:  It would be fabulous if the Music Manager tool would pull songs directly from a CD.

On the back-end I wonder if Google is using some form of de-duplication to minimize the amount of storage it needs to provision for this service?  It must be the case that there would be great overlap between music collections, particularly with the most popular songs, artists, albums, etc.  Google does such a good job of squeezing storage efficiency out of GMail; would expect them to do the same for their music service.

InfoWorld Geek IQ Test - 2011

I took the 2011 InfoWorld geek IQ test.  I knew the answers to some of the more techie questions, especially when they were related to networking (CIDR, DNS), but didn't do so well on the pop culture items.  Got a 65 which places me between Geek dilettante and Marketing Executive.

I haven't decided yet whether I'm happy or ashamed.

A dangerous combination

Do you like irony?

It turns out that the University of Michigan, like many other organizations, has decided to use the cloud for keeping track of its "Travel and Expense" software and reporting, and has therefore adopted Concur.

I think that the University has made a good decision to put this in the cloud, and to look to use a hosted solution (Software as a Service (SaaS)).  Using an existing service makes much more sense than building our own software.  How could the U-M build a better application than a company that makes its living doing exactly this sort of thing?

Now, this isn't to say that I am a huge fan of Concur (or at least how it has been implemented at U-M).  I don't find the workflow or interface to be all that intuitive, and there are a couple of things that really trip me up all the time.  For example, when entering the name of someone, sometimes I am supposed to enter their LAST name and sometimes I am supposed to enter their FIRST name, and I can never remember which to enter.  (Cue sad music.)

But the really challenging part about using this cloud service is when I use it to pay for cloud services.  (Cue ironic music.)

Each month I get a bill from Amazon.  And DuraCloud.  And another one from DuraCloud (because we use more space than our membership allows.)  And another one from Amazon.  (Two different projects with different credit cards and different pools of machines.)  And Salesforce.  And....

So each month I print the invoice to PDF.  And I fetch the receipt from my university credit card, and PDF that too.  And then I bundle them together in an expense report in Concur.  And that's when the trouble starts:  How do I classify the expense?

This is almost certainly not the fault of the Concur software, of course.  The problem is in the controlled vocabulary of "expense types" that the U-M has plugged into the system.  Not one is a good fit for paying cloud providers.  And so I pick one from the choices I do have.

Computer maintenance?

Computer rental?

Memberships (especially for the DuraSpace one, which is indeed a membership)?

Other?

My expense report is reviewed by at least four different people (two within ICPSR, at least one within our parent organization, the Institute for Social Research, at at least one at the U-M central Business and Finance unit).  If any one of them believes that I have selected the wrong expense type, the report returns to me, and I then must resubmit it.  The good news is that I don't have to reload the invoice or receipt, and so the process is relatively simple.

But for those of you about to implement Concur or another expense and travel reporting system, please add a new expense category for your IT managers:  Cloud computing services.

Top Ten: No more rubbish meetings!

Several years ago, Deb Mitchell, the Director of the Australian Social Science Data Archive, visited ICPSR during one of our Council sessions.  A bunch of us were bemoaning the number of meetings we attended, and how so many of them were so ill-focused.  We felt that many of the meetings lacked a clear purpose or goal, had no agenda, and often included too many people (but often lacked the actual key stakeholders!).  At the end of the conversation, Deb exclaimed:

No more rubbish meetings!

And that was our mantra for the rest of the month.

And so with that same spirit in mind, I present my top ten list of how to avoid the dreaded "rubbish meeting."

1. The meeting must have a goal.  Example meeting goals are: we share information, we make a decision, or we discuss an issue that requires some conversation.  Each goal has a different output, of course.
2. The meeting should end when the goal is reached.
3. The stakeholders MUST be at the meeting; the meeting cannot be productive without them.
4. Send the goal (or the agenda - which is a roadmap of how to reach the goal) far enough in advance of the meeting so that any necessary research can be completed.
5. If meeting participants will need to review documents in order to achieve the meeting goal, the documents must be sent well ahead of the meeting.
6. Come to the meeting prepared.
7. Summarize the decisions reached (if decision-making was the goal) at the end of the meeting.  This sometimes takes the form of listing the action items.  ("We decided that X will do Y...")
8. Size the meeting appropriately.  If the goal is to brainstorm the requirements of a highly complex system with many moving parts, don't try to fit it into a single 30-minute meeting.  Break it into smaller chunks, or schedule more time, like a day-long retreat (if it is important).
9. Do not rely on the "Subject" line of a meeting invite or email to convey the goal; be explicit in the body of the invite or the email.
10. Despite the best of preparations and intention, a meeting will sometimes head off into the weeds and cease to be useful.  Never be afraid to pull the plug, and live to meet another day.

I'll post notes about the Designing Storage Architectures for Digital Preservation event - definitely not a rubbish meeting! - later this week.

Photo credit:  http://vitaminsea.typepad.com/.a/6a00d83451d84969e2010535dbc2a6970c-320wi

ICPSR is a .........

I read an interesting article last week about Zynga, the company that makes many of the most popular games available at Facebook.  (The article is behind the WSJ paywall, but here is a link that subscribers can use.) 

The essence of the article is that Zynga has discovered a way to generate real revenues from virtual products, and that their extensive use of data and analytics have enabled this capability.  This short paragraph caught my eye:

"We're an analytics company masquerading as a games company," said Ken Rudin, a Zynga vice president in charge of its data-analysis team, in one of a series of interviews with Zynga executives prior to the company's July filing for an initial public offering.

We often say the same sort of thing about ICPSR, particularly within the technology team. 

This happens most often when we've just inked a new grant or contract with an organization.  On the surface the agreement is all about science and investigation, promoting research, and enabling good data management.  But just underneath there is a different story, one that often shows up in the budget.  The project is, in fact, all about building technology, and will support a large team of web designers, software developers, business analysts, and project managers to define the scope of the deliverable, and then to build it.  And this leads to:

We're a web development company masquerading as a data archive.

or something similar echoing in the halls outside the IT bay.  Of course, it isn't true, but that doesn't stop us from saying it anyway.  And, of course, one could reverse the roles:

We're a data archive masquerading as a web development company.

 to get a different twist.

Do you ever describe your own organization in this way?

Another (32-bit) one bites the dust

In 2002 ICPSR had three main servers. All ran Solaris 8; one was a SunFire 280R used for testing out new web server software, and the other two were our production systems: a dedicated web server and a systems which did double-duty as an Oracle database server and a shared staff login machine. Both were bigger E9000 systems.  All of the machines were pretty new at that time.

When the machines were tired and ready to be upgraded in 2005 or 2006 we made the move to Red Hat Linux and inexpensive, 32-bit Intel machines (mostly from Dell).  Most of these initial machines have been retired over the past year or so, and only a handful remain.  And, of course, they are the machines that deliver the most mission-critical services and so are the most difficult to upgrade.

By my count we now have over a dozen 64-bit Intel machines running RH and a only two 32-bit machines remaining (the web servers for our staging content and our production content).  We retired the 32-bit machine that served as the primary data processing platform last week; it had been replaced by a 64-bit machine that runs inside our Secure Data Environment a few months ago.

Vaults of Heaven: Visions of Byzantium

Vaults of Heaven: Visions of Byzantium

We made a family trip to one of the University of Michigan's smaller museums, a little gem called the Kelsey Museum of Archaeology.  Even though they added a large new wing for exhibition space, the entire museum is still quite small, and is perfect for smaller children (but who are still old enough to be interested in going to a museum).

We wanted to be sure to check out a special exhibit that ended on May 27, 2001 called Vaults of Heaven:  Visions of Byzantium.  While the museum's permanent collection contains artifacts from the ancient world (Egypt, Greece, Rome), this exhibit featured relatively recent items from between the sixth and fifteenth centuries.  There's an image from the the exhibit on their web site, and I've created a link to it to the left.

One thing that struck me about the items in the exhibit were the similarities -- and the differences! -- between how a museum like the Kelsey preserves objects and makes them available for access, and how a place like ICPSR does it.  Another reminder about how the digital world and the physical world are very, very different.

For example, one item available to view at the Kelsey was a small piece of pottery with an image of a person on it.  No doubt it is very fragile, and it probably needs to be kept in a very safe, climate-controlled location when it isn't on exhibit.  There was a card next to the object that contained some (all?) of the information the museum had collected about it:  When it was likely made, what it was used for, and the identity of the person in the image.  (St Simeon the Stylite.)  This information also needs to be preserved and made accessible, but it would not need to be kept in the same type of storage as the object.  In fact, it may well be the case that the metadata in this case is kept in digital format, and only printed out on a card for access purposes.  And so one of the key preservation tasks would seem to be maintaining a reliable, bi-directional, long-lived link between the metadata and the object.  If the link breaks, then the task of finding the object (or re-discovering what it is) becomes very, very difficult.

In the digital world of ICPSR, we face some of the same issues (climate controlled storage for objects, purchasing and managing storage space, linking metadata to objects), but my sense is that we have a much easier time of it when it comes to linking metadata to objects. 

For one thing, both our objects and our metadata are built from the same stuff - bits - and so keeping them in the same type of storage is easy and makes sense.  (And it sure is much easier to make copies of bits that centuries old pieces of pottery.)

Also, because our stuff resides in the digital world and tends to be kept in a file, there's the filename that one can use to help identify the object, even in the absence of metadata.  And so if I have a digital object without metadata, I still have the filename (and the content, of course) to help me identify it.

And, for some type of files, like PDF, one can bundle a great deal of the metadata inside the file itself.  This creates a very close coupling between the object and its description.  This type of close coupling is also available via some of the stat packages, but becomes less useful if the file may only be read successfully with proprietary software.

Just for fun: Conan O'Brien premiere cold open

I came across a link to this today in Kara Swisher's BoomTown blog.  It has such a nice connection to The Godfather, I can't help but share the video too.