Corey Harper [twitter:chrpr] starts a session by giving a terrific presentation of the problem: Linked data discussions and apps have focused too much on resources instead of on topics, narratives, etc. — what users are using resources to explore. We are not extracting all the value from librarians’ controlled vocabulary.

Some notes from the open discussion. Very sketchy, much choppier than in life, and highly incomplete.

Why not use Solr, i.e., an indexer of SQL databases? In part because Solr doesn’t know enough about the context, so a search for “silver” comes back with all sorts of hits without recognizing that some refer to the mineral, some to geo places with “silver” in the name, etc. E.g., if you say “john constable artist birthdate,” linked data can get you the answer. [I typed that into Google. It came back with the answer in big letters.]

Linked data can do the sort of thing that reference librarians do: Here’s what you’re looking for, but have you also seen this and this and that?

How do we evaluate the user interfaces we come up with? How do we know if it’s helped someone find something, put something into context, tell a story…?

We have two weird paradigms in the library community: Lucene-based indexes of metadata (e.g., Blacklight) vs. exhibit makers (e.g., Omeka). How to bring those together so exhibits are made through an index, and the flow through them is itself indexed and made findable and re-usable. (And then there’s the walking through a room and discovering relationships among things.)

How do we preserve the value of the subject classifications? [Here’s one idea: Stacklife :) ]

It’s important to keep one of the core functions of catalog: to identify and create identities for resources. A lot of our examples are facts, but in the Humanities what’s our role in maintaining identities around which we can hang relationships and maintain the disagreements among people. How do you help people navigate that problem space?

The Web’s taught us that the only way to find things is through search, but let’s remember the “link” in “linked data”: the ability to find the relationship between things you’ve found. E.g., the Google Knowledge Graph and Google fact panel are doing this to some degree. We’ve lost that, thanks to computers.

People want to have debates and find conflicting information. It’s hard how to bring this into a search interface.

The Digital Mellini project digitized a specialized manuscript and opened up. Once something is digitized, there are pieces you cannot see with the human eye — e.g., marginal notes.

Other examples of the sort of thing that Corey is talking about:

• Linking Lives. EACCPF (corporations persons and families).

• SNACs [??] (“Facebook for dead people”) mines finding aids to find social relationships.

• LinkSailor (RIP) traversed a many OWL sameAs relationships.

• CultureSampo (Finnish)

• Tim Sherratt‘s group has something coming out soon

People think that museum web sites are boring. At LODLAM we’re a bunch of data geeks and are the wrong people to be talking about user interfaces. Response: We should take the Apple route and give people what they don’t know they want. We should also be testing our models against how people think about the world.

“I have a lot of data. It’s very sparse and sometimes very concentrated. It’s hard to know what users want from it. I don’t know what’s going to be important to you. So we generate video games, using geodata to create the playing field.” That’s not a retrieval engine, but it’s a way to make use of the factoids.

Read “The Lean Startup.” The Minimum Viable Product is an important idea. Don’t underrate the role of the product owner in shaping a great project. (Me:) Having strong, usable, graphs that take advantage of what libraries know would be helpful.

Who are our clients? Users? Scholars? Developers? A: All of them. Response: Then we’ll fail. Response: Catalogs were designed to manage collections, not for the general public. People have been forced to learn how to use them; you have to understand the collection’s abstraction. And that’s not sustainable.

Our library wants to build the graph. We build simple interfaces to demonstrate the power, but our value is in building the graph.

We don’t want to deliver linked data to users. We want to build the layer between the linked data and the apps. If we do it well, users won’t know or care that there’s linked data underneath it.

We tend to focus on what we think our users should want. It’s an “eat your broccoli” approach to search. E.g., users want social networks, but many scholars resist it because it seems too non-rigorous.

Categories: libraries, liveblog dw