Month: januar 2016

Librarians as data scientists. What should we be able to do?

Posted on by admin

Data is the next big thing. Big data is even bigger. And as always when something new happens, libraries jump on the bandwagon from the beginning.

We are coming to it at bit slow this time, at least in Denmark. We might have been intimidated by the Big in big data. But we’re getting there. And as always when we do something new, we have the problem of figuring out exactly what we should be able to do. Wich competencies should we have, what is the level of support that we should provide to our patrons?

I imagine that other places trying to get into data science, would begin by hiring a data scientist. Or at least send the most qualified personel on courses and training sessions. Not so in a library. We have all the books, we’ll just read them, and then we will know how to do it. It actually appeals to me as an engineer:

BOSS: We should do some data science
ME: OK, do we have anyone on staff that knows anything about that?
BOSS: No.
ME: Hmmm. Are we going to hire someone who knows anything about data science?
BOSS: No.
ME: Are we going to invest in training or courses to learn about it?
BOSS: No.
ME: OK, lets get started.

It gives us a chance to play around with exciting and difficult stuff, without being burdened with any actural knowledge about what we are doing. That is more or less how engineers define fun!

So. What should we be able to do?

  1. We are not going to be able to advise our patrons about what statistical test to use. There are simply to many. But we should be able to ask qualified questions: “Are you sure that that data follows a normal distribution?”
  2. We are not going to be able to advise our patrons about what data, and what correlations are interesting. We have no idea whether a correlation between a biomarker and a disease is relevant. But we should be able to recognise a correlation. Take a look at this page – its hilarious.
  3. We are not going to know all the intricacies of all the software we provide access to. Theres a reason we have 79 books in our catalogue about ArcGis. But we should be able to perform a simple data analysis in each of them.
  4. And of course – we are going to provide the world class level of customer service and assistance, that make libraries famous. Now we’re just going to assist with data science.

Thats it. How are we going to get there? I’ll get back to that later – now I have a meeting on LibQual.

Twitternetværk

Posted on by admin

Twitter er ikke specielt stort i Danmark. Men det er der dog. Det lader til primært at være brugt af politikere, der ønsker at kommunikere til journalister, journalister og andre kommmunikationsfolk der ønsker at kommunikere med andre journalister og kommunikationsfolk. Og bibliotekarer, der desperat forsøger at kommunikere med hvem som helst. Det er i høj grad ikke et folkeligt medie, men snarere det LinkedIn godt ville være.

Ønsker man en faglig selvpromovering kan det derfor, specielt når man er i biblioteksbranchen, være en rigtig god ide at være på Twitter. Så det er jeg. Det er sat i system. Jeg sætter tid af hver weekend til kvidren – de lagres i tweetdeck, og spredes ud over ugen, og hver mandag går jeg lige efter og sikrer mig at jeg har til resten af ugen. Dertil kommer en række løse tweets i løbet af ugen. Men der kvidres hver dag.

Jeg går også semiseriøst efter flere følgere. Der er optimeringspotentialer: Hvem fulgte jeg hvornår, og hvis de ikke har fulgt tilbage, var det så ikke på tide at affølge dem. Hvem har unfollowed mig i dag? Skal jeg blive ved at følge dem? Og så videre. Jeg trækker ved hjælp af et pythonscript på en Raspberry Pi oplysninger om hvor mange følgere jeg har en gang i timen, og trækker de samme oplysninger på et antal kolleger i branchen. Skal jeg udbygge det netværk til noget der kan bruges (og det kan det!) i mit arbejde, skal jeg have et synligt mål og kunne følge udviklingen. Jeg skal have flere følgere end Knut – ikke fordi jeg konkurrerer med ham, men fordi jeg skal have et mål, gerne et der bevæger sig lidt (men ikke for meget) , som jeg kan gå efter.

Så langt så godt, der har været andre indlæg der har omtalt det. De burde opdateres, for jeg har omsider fået adgang til Twitters API, og kan nu trække data langt hurtigere, elegantere og legalt, end jeg kunne før.

Men det virker, og selvom jeg skal have migreret et script til python3.4, er det ikke noget der haster.

Så ud over de mindre potentielle indsatsområder, så er der en anden ting der kunne være interessant. Også for andre end mig. Nemlig: Hvordan ser netværkene ud? Hvordan er de danske bibliotekarer forbundet på dette, i en dansk kontekst trods alt relativt begrænsede økosystem?

Der er nogle trin på vejen. Nogen af dem har jeg styr på.

Jeg skal bruge oplysninger om hvem der følger hvem. Lad os bare nøjes med Knut og mig. Hvem følger mig? Hvem følger Knut? Hvem følger vi hver især? Er der nogen vi begge følger? Hvor er de gensidige forbindelser?

Det er trivielt. Der er lidt udfordringer i at jeg ikke kan trække mere end 200 følgere ad gangen, og at jeg ikke kan gøre det mere end en gang i minuttet. Det er der veje uden om.

Hvad jeg har lidt flere problemer med, er at få styr på hvordan jeg vil visualisere det. Der er fine frameworks derude. Det ender nok med D3 til det her formål, den kan også lave fine animationer. Traditionelt gøres den slags med bobler, og det er vel oplagt at min bobbel i grafen har en størrelse der er proportional med det antal følgere jeg har. Derfor vil Knuts også være større.

Så har jeg nogen der følger mig, uden at jeg følger dem. Der skal være en linie af en eller anden art mellem deres bobbel, og min bobbel. Det betyder også at jeg skal have en ide om hvor stor deres bobbel er – jeg skal have trukket oplysninger om hvor mange følgere de har.

Så er der dem som jeg følger, og som også følger mig. der skal også være en linie af en art mellem os.

Endelig er der dem jeg følger, som ikke følger mig. Der skal ligeledes være en linie.

Boblerne er simple. Eller, det er de nok ikke, men det er ikke det jeg har svært ved at folde hjernen om. Det der udfordrer mig er linierne (eller kanterne) i netværket. Der er tre typer. Hvordan skelner jeg mellem dem?

Farver? Det ender det nok med.

Man kunne også overveje om det kunne gøres enklere. Der findes værktøjer derude til den slags. Twecoll for at være mere præcis.

Well. D3. Farver på de forskellige kanter. Så skal der trækkes data. I et eksempel jeg har fundet, tager D3 en JSON fil, med nodes og links. Disse nodes har en source og et target. Det giver god mening for alle andre end de links der er gensidige.

Jeg tager lige et kig på denne her: http://bl.ocks.org/mbostock/4062045

Det er en lidt kølig visualisering af hvilke karakterer der optræder sammen i Les Miserables. Selve koden tror jeg at jeg starter med at kopiere. Så skal jeg generere en JSON-fil. Den har en source et target og en value i link-delen. Hvad der forvirrer mig er, at dens nodes liste har navne og “gruppe”. Gruppe kan man lege med. Men der er ikke et ID der matcher source i links. Der lader det til at være således, at ID’erne matcher positionen i listen i nodes. Hm. Jeg ville klart foretrække at ID’et var et sted i Nodes. Det skal jeg nok tænke lidt mere over.

Rambling on. Vi gør det som D3 vil ha’ det. Så skal jeg bare have det genereret.

Jeg har en liste i json-formatet med de enkelte nodes. De har et navn. Og kan have andre atributter også. I det eksempel jeg tager udgangspunkt i, har de en gruppe. Og det er det. Jeg skal bruge deres index i en liste. Så det første jeg skal er at få genereret den. Jeg trækker alle som følger Knut. Og alle som følger mig. Det giver to lister med twitter-id. Dem gemmer vi i hver sin fil. Hvert eneste ID i den liste er karakteriseret af at de følger Knut eller mig.

Det ville altså være lettere hvis jeg kunne bruge twitter-ID direkte. Det sparer et opslag i node-listen hver gang.

Og det kan man: http://plnkr.co/edit/20t4F02vsM1U55ktCv66?p=preview

Også:

http://stackoverflow.com/questions/23986466/d3-force-layout-linking-nodes-by-name-instead-of-index

Godt. Så vender vi tilbage til at generere listen over edges… Helt så trivielt er det heller ikke.

The Mythical Man-Month

Posted on by admin

Note: I’ll be using the male pronoun. Not because there are only men in the world. But because I really like the association between Man-Month and Mothman. For a long time, Iunnamed thought that the title was inspired by the urban legend of the Mothman. It probably isn’t. I still like it.

In a previous post I discussed the Bermuda Triangle of Project Management. Or the Iron Triangle as it is properly known. I promised to return to the mythical man-month later. Lets do that.

The following thoughts are not my own. They come from a classic essay by Frederick Brooks, written in 1975. And it appears to have been completely forgotten. Well. Not forgotten, it is a classic. But apparently no-one has learned anything from it.

Think back to the ideal world of project management. In that world everyone knows, that if we cut ressources, the project will be delayed. It follows logically, that if the project gets delayed, we should assign more ressources to it. That might be a good idea. It might be a horrible idea. And in some situations, the thought of getting an extra man-month should fill the project manager with the same terror as the mothman did to the good citizens of Point Pleasant back in 1966.

The basic idea is, that if the project runs late, it should get more ressources, in order to finish on time. The observation is, that the added man-months will actually delay the project even more. Why would that happen?

First of all, in most projects, men and months are not interchangeable. We all know that some of our colleagues are more productive that others. Maybe they just have other qualifications. Just because you are a great database engineer, does not mean that you are qualified to make the userinterface. And the man-month your project is assigned does not know the project. Some of the members of the project team will have to spend time training the new guy. In a really bad scenario, Brooks describes a situation where one member of the team have to use a month to train three new team members. The project might have been assigned three man-months. But the first month uses four man-months on training. Placing a net drain of one man-month on the ressources available to the project, compared to the initial situation. After one month, the project is even more delayed. And the project manager now has to explain to his boss why. A difficult question to answer when you have just been assigned more ressources.

Secondly, the tasks performed in a project are not interchangeable. They are usually sequential in nature. First we have to do this, then we have to test it.

Project managers often refers to people who believes that if you assign nine women to the task of carrying a pregnancy to terms – you will become a father next month.

So – what to do? There is no simple answer. The task of management is to pressure the project manager to perform. As a project manager, it is easy to come to the conclusion that they dont understand anything, and that their demands are unreasonable. But maybe, just maybe, you actually could do better.

When you have done better, you are still left with the task of explaining to your boss, that he is not going to be a father next month, just because you get more womanpower. Good luck.