We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

TOOLS - Web editor for JSON/Bibframe data in libraries

00:00

Formal Metadata

Title
TOOLS - Web editor for JSON/Bibframe data in libraries
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
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
This presentation shows a cataloguing form created to edit data stored in a Bibframe/JSON format. It points out the specificities, obstacles, advantages and difficulties of this implementation in comparison to a raw MARC editor. On the one hand, the interface must be really user-friendly, as it is targeted at public, school and special libraries. On the other hand, it must enable to receive granular bibliographic records from MARC and to edit JSON data that is hierarchically structured and deeply nested, composed of a multitude of fields with different conditionalities and validation rules. The system does not enable to create directly RDF data but it represents, in the specific library context, a relevant step towards the edition of linked and interoperable data. The next step regarding semantic web is to define a transformation and context for exposing this data in JSON-LD. This happens within the transition of RERO+, a Swiss competence and service centre for libraries, to an open source and in house library system called RERO ILS. About 60 libraries in Switzerland are using it since July 2021. In this context, it was decided to abandon MARC21 in favour of JSON, using the Bibframe model as far as possible and maintaining an interoperability for data import/export. RERO ILS is based on the Invenio 3 framework proposed by CERN, which heavily relies on JSON and JSON schema for resource management. The editor is also implemented within SONAR, another RERO+ software made to manage institutional repositories.
Computer animation
Transcript: English(auto-generated)
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.
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.
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
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.
So it's a basic mark versus new comparison. We are the Rero Plus Foundation. Maybe you know the Rero library networks in Switzerland.
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.
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.
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.
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.
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.
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,
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.
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.
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,
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.
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.
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.
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.
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.
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
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.
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,
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
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
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,
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
are aligned. Point D, we use RDA labels and lists. So thanks to this, the editor can be
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
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,
here on an ISBN, and there on the right on a language list. Before, the user was always able to save the form,
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
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
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
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
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.
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.
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
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
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,
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
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.
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
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
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
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.
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
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
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
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.