Pre-existing Bias

The most popular post on this site is “Emergent Biases” where I talk about Tay, Microsoft’s AI which went quite sour as she learned neo-Nazism and misogyny from Twitter users. 

Due to the post’s popularity, I will be doing a brief series on biases in computer systems, based on Batya Friedman and Hellen Nissenbaum’s “Bias in Computer Systems.”  They define three types of biases – pre-existing biases, technical biases, and emergent biases.  This post details one of these biases.

Pre-existing biases always seem the most nefarious to me.  As though some software developer somewhere sat in their basement, chuckling maniacally as they put societal prejudices into code.  Obviously, that’s rarely ever the scenario.  Many of us just can’t think out of the societal box.

Friedman and Nissenbaum define pre-existing bias as stemming from “social institutions, practices, and attitudes.”  These biases “exist independently [of], and usually prior to the creation of the system” (333).  Unlike emergent biases, these are inherent.  And unlike technical biases, these have nothing to do with the limits of technology.  No, these come from how specific groups of humans view the world.

My best examples of pre-existing biases appear in dating apps and websites.  One of the first things a user does is pick their gender.  Unfortunately, there are usually one of two options: “Man” and “Woman.”  For those of us who strongly identify as one or the other, this isn’t a problem.  But only having these two options ignores individuals who don’t identify as either.  And then there are those of us who stress about what the system means by “Man” or “Woman.”  Do they mean male anatomy and female anatomy? Or purely gender performance? Or both?  And if it’s gender performance, that means a lot of things to a lot of different people.  The developers creating only two options for gender creates a pre-existing bias in the online dating systems against non-binary individuals.

There is also another example of pre-existing bias in online dating apps.  Tinder is one of the most used dating apps.  (I think we all know someone who met their partner on Tinder.)  Tinder requires users to have a Facebook account and links the Tinder to the Facebook account.  I’m sure this requirement is to ensure that Tinder users are verified and “real.”  But it also makes the assumption that everyone has a Facebook account.  Thus it’s a pre-existing bias against people without Facebooks.  Obviously, not a matter for legal recourse but an interesting example.


Technical Bias

The most popular post on this site is “Emergent Biases” where I talk about Tay, Microsoft’s AI which went quite sour as she learned neo-Nazism and misogyny from Twitter users. 

Due to the post’s popularity, I will be doing a brief series on biases in computer systems, based on Batya Friedman and Hellen Nissenbaum’s “Bias in Computer Systems.”  They define three types of biases – pre-existing biases, technical biases, and emergent biases.  This post details one of these biases.

I find all biases in computer systems interesting.  Friedman and Nissenbaum only posit three…so it’s hard to choose which one I find most interesting.  But for today, let’s say it’s technical biases.  Technical biases are difficult for me to wrap my head around: it’s difficult for me to think of solutions to these biases.  This is not because it should be difficult but that I have lived so long with certain technologies just being “that way” that it’s hard to imagine a radically different technology doing the same thing.

index typewriter
Index Typewriter. From

(Think of it like this.  I’m so used to keyboards for typing.  But typing didn’t have to include keyboards.  Typewriters didn’t start off with the QWERTY or AZER keyboard being standard.  In fact, there are these things called indexing typewriters that use a plate and needle to type.  So, if someone asked me to develop a typing technology for Klingon, I would immediately think of a keyboard…but that might not actually be the best technology.)

Friedman and Nissenbaum define technical biases as resulting from “issues in the technical design…including limitations of computer tools such as hardware, software, and peripherals” (335).

In their article, Friedman and Nissenbaum note that screen sizes limit how much information can be displayed.  So, software developers had to think of a way to offer possible information but in a readable way, with the limitation of screen size.  They developed pages.

Think of your Google results.  You don’t see all 3,908,393 results on your screen.  First, you scroll down to see more results and, eventually, you have to click to see the next page of results.

The pages themselves aren’t biased; they’re really just more a reality.  What is a technical bias is the Google algorithm (which is a black box that we don’t know what is in).  It ranks results and then displays them.  We can see some biases immediately – that advertisements filter to the top two slots of the results.  And then there are the non-ads that are ordered in some unknown manner.  So few of us even scroll down to the end of the first page, let alone go onto the next page of the results.  So those first few results are crucial – because that’s the information most people will access.  And we know Google’s system is deciding what this information is.  So, we know it’s biased but we don’t know how.

This is a technical bias, which arose from a limitation in typical hardware…and from the code.

Emergent Biases, Part 2

The most popular post on this site is “Emergent Biases” where I talk about Tay, Microsoft’s AI which went quite sour as she learned neo-Nazism and misogyny from Twitter users. 

Due to the post’s popularity, I will be doing a brief series on biases in computer systems, based on Batya Friedman and Hellen Nissenbaum’s “Bias in Computer Systems.”  They define three types of biases – pre-existing biases, technical biases, and emergent biases.  This post details one of these biases.

My 2016 post on Emergent Biases happens to be my most popular post.  Who knew?  Because of its popularity, I am starting this mini-series with emergent biases.

Friedman and Nissenbaum define emergent bias as arising “in a context of use” (336).  When they were writing in 1996, they noticed that these biases emerged after the completion of a system and after the users changed in some significant ways.

If we are looking at the very original definition that Friedman and Nissenbaum studied, we can find some examples of emergent biases.  One very obvious one isn’t even related to a computer system.  The Americans with Disabilities Act (ADA) passed in 1990 and provided specifications for accessible buildings.  Part of building accessibility included ramps for those individuals who could not use stairs easily.  In 1990, though, wheelchairs were much smaller than today (2017).  So, if builders are using the specifications recommended by the ADA – and not going larger – many wheelchair users will be unable to use the ramps.  This is an example of a system whose user population changed (they’re using larger chairs), thus creating a bias in the system.

In 2017 (as I’m writing this post), emergent biases can also appear when people use the system in certain ways.  I wrote about Tay in my previous emergent biases post.  But there are so many other instances of emergent bias.  (She just happened to be quite an interesting one.)  I used to play video games (a lot more than I do now that I have a full-time job).  The internet at home was too slow to enjoy online gaming, so I never did that.  But I hear it would have been an “interesting” experience.

Let’s look at Twitter.  I, personally, love using Twitter.  You may have even discovered this blog via my Twitter account.  So, I think it’s interesting to study how a system I personally like and use is biased.

Twitter in and of itself is just a platform where people can post little snippets of whatever is on their mind.  Seems pretty benign.  But people can use the software to inflict plenty of damage.  For example, many people of color and women receive offensive, upsetting, or threatening tweets – sometimes en masse.  Think of Leslie Jones’s departure from Twitter after users sent her pornography, hateful memes, and racist remarks.  Twitter the system isn’t inherently hostile to people of color or women (or women of color, like Leslie Jones’s) but its users can make the system incredibly hostile to them.

That’s why policies and terms of use – and strong enforcement of them – are incredibly important with Web 2.0 systems (like Twitter).  Users can transform a system that is not inherently biased against a certain group…into an incredibly hostile system and environment for that group.  That’s an emergent bias.

What students should know about ethical scholarship

My institution has weekly “lunch-and-learn” type gatherings for the faculty.  Recently, I attended one of these that was on the topic of ethical scholarship.  Much of the preliminary lecture had to do with what sorts of ethical dilemmas faculty have when conducting research.  The second portion of the lunch-and-learn was a discussion.  One of the questions posed was: what should students know about ethical scholarship?

My colleagues had all sorts of interesting responses.  Students should take responsibility for completing the assignments (this implies they aren’t completing the assignments in a satisfactory manner).  Students should discuss and understand the institution’s IRB policies and procedures.  Et cetera.  All these responses were valid and interesting.

But I was starting to form an idea about how this related to what I have seen in the library.  I couldn’t quite articulate it at the lunch-and-learn, but I want to attempt to articulate it here.

In talking to faculty as well as teaching courses on source evaluation, I have begun to notice that students have a hard time articulating why they choose a specific source.  Many just want to fulfill the professor’s expectations; they don’t care why they chose something so long as the professor approves.  Others will cite the title: “the title suggests it’s about the topic I’m researching.”  If my instruction session is going well, they’ll often start talking about the press or journal that put out the resource they found.  This is okay for a 50-minute instruction session; it’s hard to get everything in during that time.  But I started to connect dots.

I have already realized that my trusted sources are not trusted sources in the grander scheme of things: just because I believe the anthropologists, sociologists, and psychologists who argue in peer reviewed texts that gender is a spectrum and a construct (not a biological attribute), does not mean that anyone else buys it when I use those texts as evidence.  I realized that people who aren’t in academia don’t necessarily buy that scholarly peer-reviewed articles are reputable or authoritative.  Though I think there are many, many, many factors at play, I think one significant reason for this disregard for academic sources is because people do not know how they are created.  People outside academia don’t realize how a scholar spends 6+ years in graduate school studying what they’re writing about.  Then, once they’re out of grad school, they keep studying it; they focus their writing and teaching on it.  And then they write an article, which gets reviewed by other people who have spent the majority of their lives studying and understanding the topic.  Only when the reviewers okay the article does it get published.  These scholarly articles take a whole lot of work and expertise to craft!

And people just don’t know it.

So, I think many of these undergraduates don’t know why they have to use specific types of sources.  Or why these scholarly publications are better than a blog post or a Wikipedia article.

Students knowing and understanding the scholarly communications process might help them understand why their professors want them to use scholarly publications.  If students understood that scholarly communications often requires expertise…and not of just one person.  Scholarly communications has an ethical component: that the articles are backed by expertise and research.

Understanding the scholarly communications process is similar to understanding how an IRB works.  Students can start fitting their research into the ethical frameworks upheld by the institution (e.g. IRB) and the scholarly community at large (e.g. scholarly communication).


So, I’m not sure if I really articulated that well.  But it’s a bit farther along.  Writing helps to test out (essay) thoughts and clarify them.  That’s in part what this blog is for.

Things I Didn’t Go to School For, Part II

A few weeks ago, I wrote a post about all the things that people expect me to do that I didn’t go to library school for.  Basically, that post was about things people expect librarians to know about – even when it’s not really all that relevant to library science.  (Like why would a librarian be an expert on copyright law?)  This post is still about the stuff I didn’t learn in grad school.  This time, though, I want to talk about the stuff I really ought to have learned.  I just didn’t, for whatever reason.

So, here comes another list of things I did not go to library school for.

  • Project Management.
    • In all my pre-professional positions, I was doing tasks.  I was inventorying graphic novels, lending DVDs, mending books, making posters (for outreach), cleaning out the defunct card catalog, shelving, running pick lists.  Little did I know that these pre-professional and para-professional tasks aren’t librarianship.
    • In library school, I learned about reference, pedagogy, metadata, digital preservation, architecture, preservation, and advertising.
    • Little did I know, when I started my professional job, that I would be leading projects of every size.  I’m fortunate I’m naturally a planner and am comfortable delegating tasks…because I sure didn’t go to library school for that.  (But I really should have.)
  • Meetings, meetings, meetings.
    • Again, nothing in my pre-professional or library school life quite prepared me for library administration.  Our library staff is so small that all of the faculty librarians are large power players in the administration and decision-making in the library.  And administration requires a ton of meetings.
    • There was a library administration course at grad school…that I didn’t take.  I really wonder if it would have given me some insight into how many meetings and decisions I would have to make.
  • Managing People.
    • Same points as above.
  • Managing Power.
    • Same points as above.
  • Linux, HTML, CSS, PHP, Javascript, Java.
    • If I had gone into grad school knowing I would be a systems librarian, maybe I would have found my way into a few more courses with more web development and more server maintenance.  I didn’t think I would be a systems librarian, however, so I didn’t go to library school for enough of this.
    • Also, though, I doubt that my grad school offered much in the way of Linux system administration, or working with Java or PHP.  (We did have stuff with HTML and CSS as well as Python, instead of Java.  Again, I should have taken those courses…perhaps a bit more seriously.)
  • Cataloging.
    • Thank goodness I took a metadata course because that has helped tremendously.  And thank goodness that I weaseled an hour of training on copy cataloging.
    • Still, I didn’t take the actual cataloging class, focused on MaRC.  I was discouraged from taking it by mentors and by the way the cataloging course was offered.
    • Now that I am always working with knowledgeable and experienced catalogers on all sorts of projects, I wish I had spent more time in grad school learning more about cataloging (and the structure of MaRC records).  I wouldn’t have nearly as steep a learning curve.
  • Original Research-ing.
    • My library school had opportunities for research, but it didn’t make it easily accessible to all students.  And mentorship opportunities for research were few and far between.
    • Now, I am in a faculty position which pushes for me to produce “original research,” I’m finding that’s easier said than done.  My writing (not learned at grad school either) is fine…but finding something no one else has done, all the while doing 40 hours per week of library work, is quite a challenge.  I wish I had gone to library school to help me think up and execute original research.

A Day in the Life of a Systems Librarian

In the words of the Beatles’ song “A Day in the Life,” I “Woke up/fell out of bed/dragged a comb across my head…”

Back in 2015, I told you about A Day in the Life of an Acquisitions Graduate Assistant.  If you have been following this blog, you know that I am no longer an acquisitions graduate assistant.  I graduated from library school and started my first professional job as a systems librarian in July of 2016.  Well, now that I’ve been in my current position more than a year, I thought it was time for a description of what a day in the life of a systems librarian looks like.

server room
Server room at Royal Institute of Technology Parallel Computer Center. John Frederiksson, CC By-SA 3.0. Wikimedia Commons.

So, after waking up, falling out of bed, and brushing my hair, I either walk or drive to work.  And then it’s checking emails from the coworkers who get to work earlier than I do.  On Fridays, I run server updates first thing – before any library instruction sessions start.  That includes snapshotting them, running the updates, and then rebooting them.

After that, I have at least one meeting with one of my direct reports.  I have plenty of days where I am inundated with meetings.  Today, though, I was able to focus most of my morning on crafting an information literacy session on robotics.  Sometimes developing lesson plans are quick; other times they are slow.  The robotics one ended up going slowly because I found myself fascinated by the literature surrounding robots, androids, and cyborgs.

Then, I go to lunch with other faculty – a program designed by our dean of faculty to help build community and cooperation.  I like the free food and hanging with my colleagues outside of the library.

After lunch, I have another meeting with another direct report.  And then an hour to do data cleanup.  At 3, there’s a meeting with the library director.  By 4, I’m slowing down with scholarly publication, scholarly reading, more data cleanup, or finishing up various communications to my coworkers.

At 5, I try to “skip town” (leave work) and go take care of my horse and home.

Things I Didn’t Go to School For

As I librarian, I start to wonder what the rest of the world thinks I do.

Yes, there are the people who say, “Ah, you must like books a lot!”  To whom I say, with a dead look in my eye, “I don’t work with books.  I don’t even touch books.”  There are others who marvel that I need a Masters degree to “help people find books.”  Others swear I must really like the quiet, and that I will like to shush people.

Those comments come from only understanding media-presented stereotypes about librarians.  We’re just (matronly) ladies (because men aren’t librarians) that sit around with books.  At most, many people only sometimes go through the public library and see someone sitting at a desk.  (At the public library I worked, it wasn’t even librarians at those desks but clerks.)  The “book-loving” and “shushing” stereotype comes from people with perhaps the shallowest knowledge of libraries.

And then there are people who I swear should know a bit more about libraries.  Namely, academic faculty, staff, and students.  These constituents are around the libraries all the time (particularly the faculty) and yet I have many a time marveled at their requests for the libraries.  Many times, I sit with the question (most often in email format) and wonder what my colleagues think I went to grad school for.

So, what are things I didn’t go to school for?

  • Extensive and authoritative knowledge of citation style and format.
    • First, I come from a generation who simply uses citation generators to create my citations, rather than knowing how to do it.
    • And where in “library and information science” does it suggest that we study APA, MLA, Chicago/Turabian, AMA, ASA, etc. citation styles?  These are scholarly publication/communication schematics.  So…maybe ask someone who works for those style guide creators.
    • Does anyone else in academia spend their time memorizing style guides?  Why would your colleagues in another department do it?
  • Knowledge of citation management software.  (I think this is somewhat related to the above.)
    • I know that oftentimes libraries will subscribe to citation management software.  Probably because everyone expects us to.  And we are one of the few departments actually considering how difficult it is to create and manage all these resources.
    • But librarians have integrated library systems (ILS) and a variety of other databases to organize information.  We don’t have any real desire to organize one individual’s collection of resources that they found pertinent.  (Unless we’re in an archive, but that still would have nothing to do with citation management software.)
    • I definitely did not go to school to learn how to “demonstrate” Mendeley, Refworks, Zotero, etc.  I did not go to school to even know how the things work.  So, when I am asked to give an instruction session on it, I don’t really know if I am all that knowledgeable about the topic.
  • Copyright law.
    • Librarians have to deal with copyright law all the time – from buying or licensing resources to digitizing for preservation or accessibility to circulating materials.  So, our work is very much influenced by the law.
    • No matter that our work is influenced by copyright law, we are not copyright lawyers.  And yet librarians get asked all the time to clarify what violates copyright, etc.  I oftentimes want to say, “Ask a JD.”
  • Teaching databases.
    • This is probably the closest one on the list to something I ought to have learned at library school.  Some library school classes go over database construction and whatnot.  And many of us would prefer less dreadful course topics.  But I have some training in databases.
    • Still, teaching databases is not something I went to school for.  I learned about acquiring databases and managing electronic resources in school.  And I took a pedagogy course, with a focus on information literacy standards (like the ACRL Framework).  But never did the pedagogy and databases meet.  So, asking me to teach databases is a little odd.  I didn’t go to school for that.

The Trouble with Tech Services, Part III

Every once in awhile I end up realizing how hard it is to talk about library technical services.  You can read about a few of those times here and here.  Well, today it happened again.

As the systems librarian, I handle – wait for it – the library’s systems.  And these systems all interface with each other in some capacity.  But of course, never quite seamlessly or fully.  And I have a rather decent grasp of how they all work together.  Maybe not every single piece of code, but I know how and what each system shares with the other systems.

book sorter
Book sorter, Ames Public Library, Rebecca Ciota, 2016.

However, all these systems and the myriad of ways they talk (or don’t) to each other proves confusing to most people.  Hell, it was confusing to me at the first get-go – and I came in with at least some knowledge of the monster I was dealing with.  People without a library or technical background (or both) find themselves mystified about our systems, what they do, how they work, how they function alongside our other systems, how they might work for constituents outside the library, etc.  And when faced with a room of library technical staff who all use differing jargon (but somehow we all understand each other), a lot of people get at best a little unsure – at worst, frustrated that we keep jabbering and they plain don’t get it and our jabbering doesn’t seem to help.

I understand completely and anticipate the variety of negative reactions people have to technical services chatter.  It’s why when most people try to get me to talk about work, I try to be as vague and nondescript as possible.  Launching into a tirade about discovery layers, Solr indexes, batch uploads, and a litany of other things…just doesn’t make good conversation.  (Ah, yes, the trouble with technical services.)

However – even though I try to avoid talking about the stuff to spare other people the pain of trying to decipher what I’m saying – I love talking about technical services.

Recently, one of my colleagues in the Art department asked me to explain all the moving parts of our systems to her.  I cannot describe how thrilled I was.  I drew charts on the board, explaining what each piece did and how it interacted with the others.  And I really hope I made sense.  I loved describing my systems to a lay person.  I got to challenge my own understanding of my systems when I talk about them to a lay person who wants to understand and therefore asks questions.

So, if you want to know about library technical services, set aside a good few hours and let we tech services librarians (try to) demystify parts of our job.

So, again, the trouble with technical services is that it’s hard to communicate about tech services.  But I like to try.

Link: “Fear of the End of Reference”

Normally, I prefer to write my own content for my site.  But I came across John Hubbard’s blog post “Fear of the End of Reference” and knew I had to share it.

In Hubbard’s piece, he discusses how librarians (and patrons and faculty and a slew of other stakeholders) cling firmly to outdated information-seeking practices.  Like the professor who requires (physical) print sources when more and more and more information is electronic.  Or a patron who refuses to learn the new discovery interface.  Or the slew of librarians who would prefer to search in individual databases, rather than the more comprehensive vendor-provided search tool – which all the students use.

I loved reading this piece, so my advice is go and read it here.