Thank you.
So I believe my talk today will be first of all shorter than potentially what you're used to.
I think I will finish earlier than most of you.
And secondly, I think it might be a little bit different because I'm coming from digital humanities.
Is there anybody here who also comes from?
Okay, all right. Okay, that's great.
And I think as a continuation of what Olivia was saying, it's going to be very much about how an interdisciplinary work.
It's very sometimes difficult and complex for people coming from different fields to understand each other.
So in order to start that, I'm going to first say who I am or where I come from and where I work very quick.
I'm Lucina Sadi. I did a Bachelor's in Computer Engineering at the University of Tehran.
Then I did a Masters in Digital Humanities at the University of Bolonia.
And now I'm doing a PhD at the University of Antwerp, also in Digital Humanities.
And I'm working at the faculty of literature with people who work with digital scholarly editions.
Now, the problems I face because a lot of you already come from Digital Humanities, I believe a lot of you also face.
Me, as I said, I'm like Olivia, I do not have 30 years of self-engineering experience.
I only have a Bachelor's degree.
So sometimes I feel like I'm Superman and this scene.
They think my humanities colleagues think that I've got them, but nobody knows who's got me.
So yeah, in Digital Humanities a lot of us are, let's say, amateurs.
So yeah, sometimes getting expert advice can be a little bit difficult.
And well, right now, in specifically computational literary studies, two prototypes, which are what I work on,
are not the best thing to present, because right now the buzzword is not that.
The buzzword right now is generative AI and what you can do with that.
And the H, as you all know, is still quite young.
And it lags a little bit behind the cutting edge of science, even though it is very buzzwordy.
So yeah, because of that, it happens quite often that the people in places of power in the H communities prefer to work with
what has been working so far and are a little reluctant to keep working to improve upon things.
And yeah, again, as the previous speaker mentioned, team structures and digital humanities have not exactly matured yet,
having that common ground is difficult.
Now what do we do in my research group, which will lead me to my, let's say, two prototypes here,
we make digital scholarly additions of manuscripts.
In my faculty, in my research group, we work with a different variety of manuscripts,
medieval, middle-dutch manuscripts, from, for example, the Hernah monastery,
but we also use modernist manuscripts.
We have a lot of Joyce and Beckett.
And we also have colleagues who work on born digital manuscripts.
The manuscripts that have actually been written on a computer and the process of making them has been recorded by an input logger.
And to analyze a lot of these manuscripts, we use hundreds in text recognition to facilitate the transcription of these documents,
because one of my colleagues, for example, has thousands upon thousands of pages of police reports from early 1900s in Antwerp,
and she uses hundreds in text recognition to facilitate the transcription of these documents,
and then, of course, as everywhere in academia, we would like to publish our results somewhere.
Now, you all are probably familiar with this, but just as a basic starter, the process of hundreds in text recognition,
looks something like this.
You first have your manuscript, you scan it, then you put it through a hundreds in text recognition platform,
from which you end up getting computer readable text, then you correct the mistakes you find in there,
and that would be the result of this hundreds in text recognition process.
And what is used very often in the humanities faculties are these two programs, transcripts and escriptorium.
Transcribers is the more popular one, but it's proprietary to use to work on a freemium model, then it became subscription based,
and it has a centralized server, and they clearly say that they will be using all of your data,
so whatever you send over there, they will use and then they make a model and then sell it to you.
It is a very, very good app, but well, it's not free in open source.
Escriptorium is an up-and-coming alternative to transcribers. It is free in open source.
It does not have a centralized server, which is very good in a sense, but it also makes it less popular because of that,
because people who work in the humanities usually are not very technically, like, capable of setting up their own institutional server,
and sometimes they would need super computers if they have a lot of complex data.
So that's another issue that exists with Escriptorium, but on the other hand, everything could be shared.
Now, these two are really, really good.
Transcribers actually has a tagline on lock the past, and it's amazing.
You get to train models and, yeah, on lock your past and get a lot of transcripts.
But then, the output of these two programs ends up either just being downloaded as plain text and puts in an archive, never to be seen again,
or used for distant reading, for some kind of computational literary analysis, like counting how many times so and so work was used.
But specifically, in my research group, what we do digital scholarly editions, we are really care about that inherent connection between the text and the actual manuscripts, in this case, TypeScript.
This is, for example, the BDMP, the Beckett Digital Management Project.
And as you can see, like, this was done completely manually.
This was before Transcribers, et cetera, was a thing.
And the people who made it, it was actually done in our faculty, really cared that the person can see exactly what line and how it was written.
It was not just the text that was important, but the connection between the context, the content of the text and the form of it was actually an important part of this, yep, like, process.
So now the options to, like, publish whatever it is you have with the text, the image with the text are either to make bespoke digital editions from scratch, which requires lots of money, lots of time, lots of effort.
Use Transcribers sites, which starts at over 47 euros a month, if you have more than 1,000 pages.
It is, again, not for your open source. It is not for the user to be scriptorium.
Or to use TI publisher, which is for your open source, but it loses the text to image connection.
You can use your image and your text, but the text does not have any inherent connection to the image that you have.
And it is dependent on the existDB ecosystem, which, again, creates a steep learning curve for anybody in the humanities who wants to make it.
Now, this is where I come to my proposed solution that is for now locally, and, like, also, one other, like, faculty is using it.
Which is a viewer I call, Nick Durus. I call it Nick Durus, because the editor I previously made and presented on this year is called Axelotl. And Nick Durus is another kind of that species. I don't remember what they are called even.
So, it is a lightweight and modularized TI viewer and publisher. It is a React component. And process data from transcribers or escriptorium, or even not necessarily from the output of a hundreds of text recognition platform.
Can be directly exported to and rendered in it. And the interlink to zones, which is inherently valuable for digital scholarly editions, will still be present to aid the user.
This is pretty much the setup of the architecture that we have designed. And these are the features. They are not going to sound out of this world, because this is a room full of software developers.
I have pagination, so it is not just one page, you can have as many pages as you want. I have collection support, so you can have multiple books. You have the raw XML view, so you can see it as rendered, beautiful HTML, whatever, but you can also see the underlying TI XML underneath it.
The page layout is flexible. You can replace the manuscript section and the text section, different places. You have a collection search. You have authentication. The architecture is API driven, so it is like database, agnostic, let's say. And of course, as opposed to most of the options that exist, it is free and open source.
This is a sample of what it looks like. It is very very bare bones. I am leaving the extra CSS to the people who are using it. This is a sample of those herna manuscripts I mentioned.
As you can see, you have the connection between the text and the lines and the image.
And one issue with this was that it was difficult for humanity scholars to set up, because again, this is like you would need a server, a database, and just setting up a web application.
Again, humanity scholars could find this difficult. So what I did was I made a GitHub pages template for a static version of the app that has a lot of those previously mentioned features, not all of them.
And the only required skill to get it up and working is minimal familiarity with Git, so you just have to know what's like pull and push are pretty much.
And it works very well for smaller projects and for bigger projects that can act as a first step because a number of the archives we've talked to have said, okay, this looks interesting, but is there a way we can put up some of our data on this so that we can see if we like it.
And this can act as a first step for that. And this one, this is a digital scholarly edition of the last notebooks of Virginia Wool, is done with that early template with that does not have all of the features.
As you can see, it looks very much the same, has 270 pages over 45 documents and it works pretty well and the person who made it is not familiar with programming at all, but he made it completely on his own just using that GitHub template.
Yep, I just wanted to share this like let's say at talk solution that I came up with and how I continued to use it and how other people are using it, this person for example who's using it is at Oxford and is doing something that's completely not related to me.
But he was looking for something like this and he just couldn't find anything that would work with his level of digital literacy, let's say.
And that's it for my talk. Thank you all so much.
And we have some questions in the room.
Thanks for the report, it was a very interesting tool to provide.
I was wondering because I have been facing a report for this in the last years.
And then I chose to go with just T.I. to display T.I. to enhance it with graphic information.
Yes.
That's actually a very interesting question and we've had a lot of talks about this at our research group.
The thing is that people who work with digital scholarly editions specifically wants to use T.I.
Because T.I. has some specific tags that's the people who work for example with genetic editing really need, for example, to set up their apparatus, the genetic apparatus of how a manuscript was edited.
And also is focused on where in the page everything is, which makes a lot of sense.
What you get out of transcript was any scripturium is actually also either alto or page XML.
I end up transforming this that is why I developed that editor I previously mentioned.
There I transform them to T.I. because the people who make these digital scholarly editions still very much only want to use T.I.
That best the reason.
Yep.
Thank you.
Thank you a lot of questions.
And let's speak again.
Thank you.