USER INTERFACES - Capturing cataloger expectations in an RDF editor
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 16 | |
| Author | ||
| Contributors | ||
| License | CC Attribution - ShareAlike 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/60334 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Bonn, Germany |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
02:24
Computer animation
09:39
Computer animation
Transcript: English(auto-generated)
00:11
Yeah, you need to set down the coffee and come back in. All right, as people are coming in, I'm going to introduce the first block of speakers
00:23
we have this morning after our lovely keynote while we're waiting. All right, so the first block we have this morning is on user interfaces, and that's the series of talks we're going to be having,
00:41
or the topic for the series of talks this morning. The first talk we have is capturing cataloger expectations in an RDF editor, Shackle, Lookup, and Vitrolib. And this is a presentation coming from a number of colleagues at Cornell University. Stephen Folsom, Huda Khan, Lynette Rael, Jason Kovari,
01:01
Rebecca Younes, and Samir Warner are all listed as co-authors. I'm happy to introduce Stephen Folsom and Huda Khan to present this morning. OK, so I had a number of fears in giving this presentation. The first one was technical difficulties,
01:21
and we do have those. I'm going to be working from two machines so I can have my speaker notes. Another was going after Jim Hendler and not having a natural segue, but I'm encouraged in his slides around dive and that theme around interoperability and validation, and you'll hopefully see some of that here in our presentation today.
01:40
This presentation is a, it covers work that wrapped up in the summer of 2018 under the auspices of two Mellon funded grants, LD4L Labs and LD4P. That's the extent of which I'm going to talk about the grants. They're highly Google-able, and we have lots of links throughout the presentation if you want to dive deeper.
02:02
Another aspect worth mentioning is that this is a progression of some ideas that we presented at SWIB last year, so the ability to implement BIBFRAME and extend BIBFRAME, and namely through the context of an RDF editor, in our case, VITRO, a link data cataloging tool.
02:27
So the general problem or set of questions that we're trying to answer here are around, once we have a model, how do we meaningfully allow for applications that the catalogers can interact with
02:40
naturally and that meet their expectations? And by this, we're mostly considering form definitions and the implementation of those forms. Another central piece of our work is the use of, the development and use of data outside of the context of the editor, so creating lookup services
03:02
that let us link to external data. So what Jim was saying earlier about making meaningful connections between different data sets, we're largely in the business of trying to do that. And then using usability with catalogers to make sure that the right information in our environments is being displayed from those places,
03:22
or from those data sets. So our process generally starts with developing a model, then building a constraint language, followed by building an application that the catalogers can then use. I don't have time to go into all the modeling work
03:40
that we did during our grant, but here's an example of measurements where we worked with rare materials catalogers and our librarian catalogers to extend BIBFRAME with a measurements model that more clearly models and in a machine actionable way measurements. So we begin with a measurement group,
04:02
and that's really just a way to cluster related measurements. And you can qualify the measurements using DC term or the measurement group using DC terms. So you can say that the measurements were approximate, that the measurements include the object in a container, et cetera.
04:21
Let's see if this works. Yay, it worked. And on each measurement group, there's the ability to assert actual measurements and to say with certainty that they are measuring a particular dimension, that they are using a particular unit and the value of course.
04:45
So I'm gonna step back a quick second to talk about our decisions around what constraint language we used. A lot went into selecting a syntax for capturing this information. We settled on Shackle.
05:00
A number of reasons include we were non-committed, we lacked commitment on the editor we were going to use. So we wanted an editor agnostic syntax. So we did that, or use a 13th standard when there are 12.
05:21
We also wanted something that was standard space. And it turns out that this was actually a standard. We didn't develop one. The W3C recommendation went a long way for us. There are tools to create Shackles. So we began using TopBraid, the free version. To start, I have to admit, we quickly moved out
05:42
of TopBraid into just editing the RDF files directly just because we were working in such volume and it was a lot of clicking. And lastly, and most importantly, Shackle comes with both validation properties but also non-validating properties. And as we go into our examples,
06:00
you'll start to understand this a bit more and how they became useful for us in form definitions. So here we have a little snippet of the Shackle and in parallel some UI. Each property path, each section there, is anchored by an existing property
06:24
and they largely map to a field in the form. And so you see here that working with catalogers, once we had the model done, we had to figure out what order the fields were going to be in the application. Also, things around labels.
06:42
So we have SH order starting with zero to talk about the different properties or fields within the case of measurements. Another thing to point out here is the SH name allows you to override an existing property label
07:01
that you're using. So we are reusing RDF value for the value but we wanted to display in the app numeric value because we're talking about measurements and we wanted numeric values. So it's a way for us to override some of that display.
07:24
I was trying to figure out how not to come up behind Stephen like a stalker in a bad movie. So as Stephen just described, Shackle is the way that we were trying to define how the ontology should actually behave. So what should the properties be labeled in a particular form for a particular class?
07:42
What kind of grouping should we use and what kind of options for vocabulary should we integrate? So on the left, we have the information that we can capture in Shackle. And so as we saw before, we have the interface that we actually want to get to. So our challenge was to take that information and be able to represent that
08:01
in our cataloging prototype called VitroLib in a way that the application could present the interface we wanted to our users. Luckily for us, Vitro had, in addition to the ontology, had the ability to use application-specific configuration to determine how properties could be displayed
08:23
and edited within the interface. And VitroLib is the name for the cataloging prototype editor, which is based on Vitro. And I'm not gonna go into all of that, but this is sort of the important piece where we have Shackle and we wanna get an interface and we're using the application's own configuration
08:40
to do that. So our process was, we took the RDF that we had defined in Shackle, and since it was RDF, we could query it. And we queried it to generate the application-specific configuration we needed, which was also an RDF. So we went from one set of RDF to another set of RDF, which I'm sure you can all read on that wonderful slide.
09:00
I won't go into the details for this table here, but it should show you that the kind of concepts that we were looking at in Shackle, how they map to things within the Vitro configuration. So I want a property to be labeled a certain way on the form. I can then use that and map it over to the equivalent functionality within Vitro.
09:24
I want properties to be grouped a certain way. I can take that information and put that in the Vitro configuration. So this is an example of property groups, or I'm gonna go through one example to show you exactly what we're talking about. So we have specific groupings of properties
09:40
that are defined for what should show up on an instance form. And so let's say you have a property group called titles, which you want to show up first. Way down in the bottom, you have a property group called instance physical description, which is where you would want measurement properties to show up. And so we take the Shackle,
10:01
we do our little querying magic and translation magic, and when we generate the configuration for the application, the application says, oh, I know what you're talking about. You want these property groups with these labels in this particular order, and you want these particular properties in those groups. So each of the tabs is a property group. They're ordered the way that you see in Shackle.
10:20
If I click on instance physical description, I want to get this. I want to get the properties I've defined in that group. I kind of skip back and forth, but you can see here, these are snippets from the Shackle that show which property goes in which group. So in this case, the measurement property is going to go in the instance physical description, which is that blue box.
10:42
Don't ask me why I picked those colors. So that's what the interface you're seeing, the groupings and the properties themselves, and what they're called, all of that is being generated from the Shackle. And when it comes to the form, some of this is not automated, but we were able to use some of the information in the Shackle to generate the form itself. And Stephen will talk about that.
11:06
Okay, so one of the things that we'll keep harping on is how often we involve catalogers. And so here you see for the has unit and measures property groups that
11:21
we have an SHN pattern. And what that is is we worked with catalogers for units to select terms from the QUDT model so that we wouldn't have to recreate those terms. So we've selected four units using an existing measurement model
11:40
to have those as a controlled list. Similarly, we worked with the catalogers to identify dimensions, existing dimension values from AAT. And so as you can imagine, when you have a controlled list, one of the ideas or one of the options in UI is dropdown. So on the left you see the labels for the QUDT values
12:04
and on the right you see a dropdown with labels from the AAT terms. So one of the things that we explored was how do we provide direction in the Shackle to talk about or to
12:22
indicate to the application that we wanna use a particular lookup service. And we didn't get very far in terms of this work. Mainly we came up with a Shackle extension that said for this property shape, if you wanna use a lookup service,
12:42
do it this way. Whether or not this is the right way is a question to be answered. Another and also some of the more complicated use cases where we might have multiple lookups, we didn't really explore that either.
13:01
So yeah, so closing arguments or closing questions on Shackle, a lot of questions remain. When we first began this work, we were mostly considering a non-modular approach. So it was a single document with all the Shackle self-contained or encapsulating all of the semantics
13:21
for a given form. And this was really about readability. So we were, oh boy, we got five minutes. So it was about readability and trying to make sure that as we learned Shackle, we understood it more. Later we began to think about modularization.
13:40
So removing or separating the form semantics from the validation layer so that communities could agree on one layer without having to implement another. So we could agree on validation and use a different tool with different form specifications. And we have a link there about maintenance issues
14:01
and including that question. More generally, we have to have a more nuanced conversation around validation and what it means to validate. Are we talking about closed shapes versus open shapes? So does all of the data in our environment and that gets treated by our application require a shape definition in order to be used,
14:25
in order to be worked with in our environments is an important question. We ran into trouble with creating Shackle. The tools to do this, it's a pretty high barrier. So, and that goes for any profile editing.
14:44
So there's a barrier there. And then I mentioned that one of the reasons we use Shackle was for UI, built-in UI predicates. There's some distance from those predicates to all the ways that we would want to configure an application.
15:00
So you got to see a little bit of that with the lookup service extension to Shackle. So the community could come together to extend Shackle for useful configuration specs. Changing directions and focusing more on the lookup side of our work.
15:22
We spent a lot of time with catalogers identifying data sources that we wanted to be able to link to. And in doing so, we chose the lowest barrier technology spreadsheets so the catalogers could make these decisions directly. And what we're asking them to do is identify a data source,
15:41
the entities in that data source that we want to search for, what properties are useful for search, what properties are useful for display. Off the screen on the spreadsheet are comments about ranking, and we also have some YAML test format that we're asking them to do. So the idea here is for them to identify the data sources and how they would want to query it
16:01
and provide links to it. You know the thing where you have to present 20 slides in two minutes? This is that thing. So I'm not gonna go into all the details, obviously, but here are examples of lookups within the interface. So this shows a lookup of a person.
16:20
That's a simple auto-complete. You type it in, you get a label and URI back. Here's an example which we based on our feedback from the usability work that we did and our discussions with catalogers. The catalogers need some additional context to actually disambiguate between which particular person they need to link to and which particular genre form or subject area they want.
16:42
So this is an example of showing context coming back and with the search results themselves. How did we do this? We had a presentation last year where we talked about the infrastructure behind this. I'm not gonna talk about all that except for this part which is an excuse for me to use the names of my colleagues as acronyms.
17:03
We have the service that takes the data from the authorities and allows us to cache and index it. We have the RAIL service which is the questioning authority API that provides a standardized mechanism to get data from different authorities without us having to write a whole new module on the front end every time.
17:21
And this is the infrastructure we're using to get the information you're seeing in the lookups. These, the API for the, especially for RAIL which is for the link data questioning authority API is based on the use cases that we talked about very briefly here which is looking up information from an authority and also providing
17:43
or retrieving context for, for example genre form. So I type in soul music and I got not only or animation films, I get not just the URI and the label back from the service, I also get information like alternate labels and broader and narrower terms. All components of information identified
18:00
as important to catalogers. And in our work that we are doing now with Synopia which is what we're calling the version of the cataloging editor in our current grant, we're looking at using the same API to get information back for a single entity that can then be used to populate a form. And here's a screenshot of the API because I'm sure you can read that.
18:22
But all of the information and references are at the end of the slides and there's a very nice video that our colleagues set up. So future directions, all that was previous work. We have one minute and we'll try to talk about current work. So Synopia is an RDF editor based on the bib frame editor
18:41
that Stanford is the technical lead on. So it's sort of the central work in the next grant. And some of the same themes around lookups and profile development have sort of transitioned into that work. Of note is that we are not using Shackle.
19:01
This is largely a pragmatic decision. The bib frame editor isn't Shackle compliant. We don't have resources to refactor it to make it so. We don't have resources to convert Shackle to the bib frame profile. So we're all working creating JSON syntax bib frame profiles.
19:20
A version of the profile editor will be supported by Stanford. There are existing profiles that we can at least start with from the Library of Congress, bib frame pilot. And long term I think there's just a big messy discussion that we need to have about what format these configurations are gonna be in. There's Shex that we heard about yesterday.
19:40
There's JSON schema, et cetera, et cetera. But when we settle on how it is that we wanna have shareability of these profiles and what sort of tooling and library tools are available to support them, I think that the dust will settle and will become clear. It's me again.
20:01
So like I said, a big part of this was really talking to catalogers and understanding their needs and requirements. And that was demonstrated with some of what Stephen talked about, the spreadsheet and getting all the requirements from them. There's also work we've done in the grant that we are talking about as well as the current grant to actually do usability work around what the interface,
20:21
what information should the interface display to users, how should it display it, and what kind of design can help facilitate what catalogers are actually trying to do. We just finished with a usability session last week where Asher Desong from Stanford and I talked to six participants across different institutions in our cohort
20:40
using a prototype based on the BIBFRAME editor, but what we tinkered with to try to actually show the context and the information to the catalogers and also enable linking to VIAF, Wikidata, and ISNI where we could find that information. And then these are screens that just show you how we had the catalogers try to figure out
21:02
which Sam Taylor was the one that they actually wanted based on the information. And they could open up the authority file in the window, they could open up Wikidata. Similarly for genre forums, you have contextual information about broader and narrower terms, which is very important, and they can also look at the authority information. Astrid also set up a mock-up
21:20
that provides a little more involved interaction with the hierarchy itself for broader and narrower terms, and so something that allows people to see what the tree actually looks like because as one of the catalogers put to us, it's not simply an issue of finding the best option, it's finding the better option within a set of best options, which one really works.
21:41
So since I don't have a great ton of time to go through all this, I think the one good takeaway is context is useful, so we seem to be on the right track. And like I said about the hierarchical navigation, really being able to understand how to show that to users in a way that, to the catalogers in a way that really helps them, I think is going to be a very interesting question
22:02
which we'll pursue. And we got recommendations and suggestions for additional sources, so it turns out catalogers look at a lot of info to figure out exactly which person and which subject heading is useful. I was going to wax poetical here about how this is all about moving from abstractions to something people can actually use, and I guess I just did.
22:21
That's the extent of it. So in the spirit of concrete outcomes, I would like to say that there's a minimum viable product for the Synopia editor in April of next year, that's expected, which may integrate some of the work we've done and at some future version probably will. There's plenty of documentation about that. And in the spirit of engaging all the community
22:41
and asking all the really interesting questions, we would like to invite you to save the date for the 2019 LD4 conference in May in Boston. I apologize, I went through that very fast, but the slides are up there, so that's it.
23:06
Thank you very much for that. We do have time for a quick question or one question if someone would like to ask about the wide range of work at the Cornell University Libraries. Come on, there's not a shackle-shacks throwdown.
23:30
I have a question to Huda. And it's just a usability thing. I wonder when you open this selection list
23:41
for the, in the look up, no? That one, exactly, yeah. And you have decided to put, not to link to something, but to put it in an iframe or so. Was this based on usability feedback from your user group?
24:06
So this was a question we had which was, is this a better way of representing that information and allowing for all of the external information to be displayed in screen? And that was one of the questions we wanted to actually evaluate. Does this even make sense, this particular design?
24:21
Is it helping you? Or would you rather open it up in a new window? And we got kind of mixed feedback on that. Some people were like, no, I'd rather open it. The biggest set of feedback was, whatever we choose needs to be consistent across the interface. And it turned out with VIAF, we can't do cross-domain framing. The other sources allowed us, but with VIAF you had to open it up in a new window.
24:41
And the catalogers were like, why? Why is this over here and why is this over here? So I think there's more design work to be done, but that was one of the questions we wanted to evaluate. Thanks.