TOOLS - Web editor for JSON/Bibframe data in libraries
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 |
| |
| Title of Series | ||
| Number of Parts | 14 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Germany: 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. | |
| Identifiers | 10.5446/60268 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Computer animation
Transcript: English(auto-generated)
00:00
The next talk is about a web editor for JSON BIBFRAME data in libraries and that's a talk by Nicolas Ronguet who is an information specialist at Rero Plus, an IT and competence center for libraries in Switzerland.
00:21
He collaborates in the development of the library system Rero ILS, bringing functional specifications and a librarian point of view to the project. So the floor is yours. Thank you, Elvis, and welcome to this short talk about a web editor for JSON BIBFRAME data.
00:47
I will just start with a short context why we do this, then present the editor in a user point of view, especially usability aspects, and end with a small explanation of why is this
01:07
relevant for semantic conference. But let's start with a short before-after. So this was the situation six months before, and this is the situation now.
01:26
So it's a basic mark versus new comparison. We are the Rero Plus Foundation. Maybe you know the Rero library networks in Switzerland.
01:42
We became Rero Plus now. We are a non-for-profit foundation with open source philosophy and host and develop IT solutions in Switzerland, especially two of them, Sonar and Rero ILS. Both of them are using this web editor.
02:06
These solutions are based on Invenure 3, developed in Geneva by CERN, and we develop Rero ILS and this JSON editor in collaboration with University of Louvain in Belgium.
02:23
So about the usability, I will present a six point of six challenge actually that we had during the development, and we still have now.
02:40
First, the data structure and granularity. So you see this is one field in Rero ILS in the JSON structure, and you see it has a lot of staff field and a very big granularity that is offered by the JSON syntax.
03:01
So here I highlighted the various levels. If we count them, we have seven depth level, which is in comparison to Mark, much more complex to present in an editor.
03:23
So this is the equivalent of the same field in Mark, the famous provision activity field of BigFrame, and we see in Mark it is spread in at least four different Mark fields, so the data structure is different and more granular,
03:44
and this is a challenge for a web editor that has to be user-friendly. Concretely, JSON has a specific structure consisting of names and value.
04:01
Here you have a name and a simple value. You can also have sometimes a name and a repetitive value. This is the case of almost every field in Mark 21. They are almost all repetitive, which does not make it easier. We can also have a name with an array of objects.
04:28
For example, here identifiers can contain more than one identifier, and each identifier can contain a type, a value, a statute, a qualification. Some of the fields are required,
04:44
some of them are not, and we need all the interface patterns to enable to add, remove, and interact with the form in an easy way. So here is the identified by field.
05:05
And the last example, this is the most complex one that I will present. It's a name of a plus array of arrays of objects, and this object contains name and simple value. It seems complex, but it's only the field statement of responsibility.
05:24
You can have various statements. Here we have two statements, and each of them have transliterations, so first the Latin version and the Cyrillic version.
05:41
The editor had to cope with this. The second challenge was the compactness. If you look at the sensor on the right, you see that you cannot have an overview of all the fields in the same web page. This is why we had to add this jump to section.
06:07
This is a big difference in comparison to a mark editor where you type directly in the code. Actually you type the dollars and so on. Our users were used to have this overview.
06:24
To make it shorter, we had to hide some optional fields. Here you see for the title field, we decided to hide subfield other title information, and it could be added manually
06:41
as an option. And we also have fields that are displayed by default because they are important. The next challenge, the visual layout. We introduced a fake repetition of labels.
07:01
Here this is the normal editor, and this is the version if we had not these label repetitions. So you see for some NEST, we had to put an effective label so that the end user understands what he or she is going to duplicate or to delete. But in the data,
07:28
we have no fields called responsibility or values. We just have an array basically. Second and third things we did, lines and indentation for the end user to understand better
07:48
the data structure. All this trying to keep a clean design because it can become very difficult to see where is what if we add too much in the interface. And the fourth point
08:09
is responsiveness since we do a web editor. So here you see the same field in two different size screens. On the left, we have the mobile size, and on the right,
08:25
the bigger window size where we tried to align some input fields here because it makes it also easier for the end user to understand the data structure if things
08:42
are aligned. Point D, we use RDA labels and lists. So thanks to this, the editor can be
09:07
sometimes labels that are not that user-friendly in RDA, but at least we have no more mark codes. For example, in mark, we had to type the mark codes and to know it to be able to use the
09:25
editor. One big advantage of this editor is that it can give a direct validation and feedback to the user when the person is typing. Here are three basic validations, here on a date,
09:49
here on an ISBN, and there on the right on a language list. Before, the user was always able to save the form,
10:07
and we had to launch every week some verification script to identify the dates, errors, and ISBN errors, and it was quite painful. Now the user is not allowed to save the record if
10:23
there are some blocking errors. Another validation or interaction is the autocomplete to link a document to other resources. Here, with the very typical field
10:45
contribution, we have links to a corporate body. The last point is the textual help elements. We have on the one hand placeholders where we
11:07
decided to put example of data, as you have it here, or recommended RDA terms. We also have another option, the tooltips, where we put a definition of the fields and, if necessary, some
11:28
input rules. For example, use one or more RDA terms. We also put the mark correspondence because it still helps for some of our users.
11:44
So just those six points are very important for us because we develop and have this editor for public libraries, sometimes also very small school libraries, and it has to be easy to use.
12:03
What's behind the editor? We have a data model defined in JSON schema. It's a set of rules defining the validations and so on of the various fields. We have 54 first-level
12:20
bibliographic properties. What is great is that this editor is generic. It works for all kinds of JSON data. For example, in our library system, we also edit library patrons or acquisitions with the same editor. It's based on Angular 12 and you can see here you can reuse it
12:49
or test it. We have the links on GitHub. Concretely, here you see how the JSON schema looks like. It uses JSON syntax, the field names, the field keys,
13:09
uses the BIBFRAME structure. For example, here we have field credits. It comes directly from BIBFRAME ontology. Lastly, we use RDA labels to be displayed in the interface because we don't
13:24
want to disturb our user with where the BIBFRAME names or new credits has a title note on statement of responsibility. We also added some JSON schema custom fields to define form options.
13:47
This is where we place the placeholder and also some navigation rules, hiding rules, or the size of the field. I think as a librarian this is an advantage of
14:06
JSON schema to generate an editor because I can read it. It's human readable, not only machine readable. This is one of the positive points. The other is the
14:23
better ux in comparison to mark, at least for the learning curve. We had already positive feedback from our librarian that it was easier to introduce this editor to the new person arriving in the library. We have a better data quality because we have a direct validation
14:49
and again this editor is generic for all kinds of JSON data. The negative points are some ux disadvantage for our users or for users used to mark. It's a difficult change.
15:08
Our disadvantage pages are linked to the abandon of mark which is taken at difficulty because we have to keep import and export functionality and also because
15:29
BIBFRAME is a changing standard. I'm almost finished. Why is this important for semantic data? Firstly, because we can enter high structured bibliographic data which is not the
15:43
case with mark. We store values directly in linked data format so if you open the JSON data you can see some BIBFRAME and RDA values. We should still add the context but we are
16:02
just one step away from JSON-LD. This is a work to be done maybe next year and we have a dynamic integration of IDRF and GND data in the editor as you could see it in autocomplete functionalities. Thank you if you have any questions.
Recommendations
Series of 16 media
Series of 15 media
Series of 16 media
Series of 15 media
Series of 14 media
Series of 16 media