De l'Une à l'Autre: Towards Linked Data in Special Collections Cataloging
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial 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
Heberlein, Regine
Bell, Joyce
Santarelli, Lidia
Baxmeyer, Jennifer
Green, Peter
A member of the Mellon-funded Linked Data for Production (LD4P) initiative, LD4P at Princeton is participating in defining linked data ontologies specifically for the description of special collections materials. It uses a hand-selected set of 525 items from the Library of Jacques Derrida – all of which bear inscriptions by persons who gifted the books to Derrida or his household – to investigate tools, workflows, and data models that will make the creation of linked descriptive data for annotated material viable in a production environment. To this end, LD4P at Princeton is exploring modeling these inscriptions on an adaptation of the (W3C Web Annotation Data Model) and linking them to bibliographic data converted to (BIBFRAME 2.0) or related models. Since the VitroLib ontology editor, which was developed at Cornell University as part of the LD4L-Labs initiative, is designed to use (bibliotek-o; a supplement to BIBFRAME developed by LD4L Labs and the LD4P Ontology Group), LD4P at Princeton anticipates using bibliotek-o at least part of the time. The presentation will give an overview of the workflows and tools the group has developed, demonstrate the current data model, and discuss our current thinking on implementation issues such as front- and back-end interfaces, API's and the curation of external data sources, and lessons learned along the way.
 Good morning. My name is Regina Heberlein. I'm a metadata specialist in the Department of Special Collections at Princeton University. And it is my great pleasure to talk to you today about a project we're involved in, in that we are a participant in the linked data for production initiative. Our group consists of five people. Joyce Bell, who is our project lead, Jennifer Bax, Maya Peter Green, Lydia Santorelli, and myself. And also until March of this year, when he defected to Yale. Tim Thompson was also a member of our group. Many of you will know this. Our group is part of the Melon-funded linked data for production project, which actually includes six research libraries. So Columbia Cornell-Harvard Library of Congress, Stanford, and Princeton. And the purpose of the grant is to explore ways to move from mark-based production workflows to production workflows based on linked open data. Each partner library in the grant works independently on a local use case, and that includes the data modeling and as the case may be, the domain-specific ontology development. LD4P is also part of the larger LD4 family, which includes the Melon-funded linked data for libraries, LD4L, which concluded in 2016. And LD4L Labs, which runs 2016 to 2018 and is focused on tool production. LD4P is a two-year grant that started in April 2016. So we're fast approaching the finish line. So Princeton is using a selection from the library of Jacques Derrida as its project test case. This is an author library of about 19,000 items that was acquired by Princeton University in 2014. Jacques Derrida, of course, was a French philosopher. He's one of the major figures associated with post-structuralism and post-modern philosophy. And the collection has met with correspondingly high interest from researchers. The collection includes Derrida's working library, which is one of the things that makes it so interesting, as well as books belonging either jointly or separately to Jacques and his wife, Marguerite. And in a handful of cases also to their two sons. It includes a variety of formats, monograph volumes, certainly serial issues, off-prints, clippings, typescripts, etc. That were largely accumulated in the course of Jacques and Marguerite's professional activities, but there is also a set that represents the family's leisure reading. So, this is another view of the library. What makes this collection so interesting from a linked data perspective is that it embodies many and different types of relationships that aren't easy to either expose or let alone make functional in a library environment with our current descriptive tools. I'm going to give you three examples, the last of which is our use case. So, for example, Derrida extensively annotated his books. So, there's a lot of marginalia and also a lot of insertions. And for those interested in studying Derrida's reading habits or intellectual formation, for example, those represent a record of a dialogue between Derrida and the text. There is currently another project exploring this at Princeton University. It's called Derrida's Margins, and I believe they're not using a linked data approach, even though I think it lends itself to one. Another really interesting type of relationship in this collection is the shelving order, meaning the precise location of the books, because it is meaningful in that where a book was kept, so for example, in the studio or somewhere else in the house, and who its neighbors were, contains information about how it was used by Derrida. I'm an archivist by training, and archivists call this kind of meaningful background context. This is the kind of context that allows you to know what you're looking at, but it is not contained in the resource itself. And so we tried to address the presence of substantial contextual information in this collection by treating it as an archival collection. So it is described in a finding aid rather than in individual mark records, and that allowed us to display the original shelf order and to allow users to sort by it, among other data points. Of course, what that gives you is still basically a browse list, so the functionality is very limited. Last, not least, to get to our LD4P use case. Excuse me. The collection contains a large run of over 6,000 items of books that were gifted, and in many cases inscribed to Derrida, and also members of his household. Derrida famously never threw away a book, including those he never opened. There are some shrink-wrapped ones that we got as part of the collection, and obviously never read. And there has been active scholarly interest in these dedications, because they represent a physical manifestation of Derrida's reader network and intellectual influence. Currently, this sort of information is buried in a note in the record. I'll show you that in just a bit, and we really have no mechanisms to include it in our discovery functionality. Here you see some examples. For our project, we selected about 500 of these dedications, pretty randomly, even though we did try to filter out living gifters to be sensitive to privacy concerns. And so the goal of our project is to explore and develop a production-oriented workflow that allows us to capture and make discoverable the relationships embedded in the dedications. And to that end, we have been working at creating a dataset that combines in-linked open data format, the bibliographic item data, and when I say bibliographic item, I really mean the bit frame item, and antified dedication data. This one is an amusing example, also an interesting example. It's amusing because Derrida has annotated a dedication, and the dedication is pretty warm and cordial, you know, to the effect of ingratitude for your friendship, and with my strong and faithful and great admiration, yada, yada, yada, and his response is hypocrite, exclamation point. So this is actually also a very interesting case of a meta annotation, excuse me, annotation, and I'll use this example for a while to demonstrate what we can and cannot do with it in this project. So as mentioned before, we currently describe this collection in a finding aid, not in a mark record. This is a snippet of the XML. It's an encoded archival description, which is an XML schema for archival data. You notice the big blob in the center there. It's just a string of text. This, by the way, would be a very similarly sad situation in a mark record, where this would also be in a note field. The data is completely unstructured, and the entities are just embedded in a string. And I've circled sort of the low hanging fruit here, even though you could go further. So we developed a data model to structure this data, which is based on the W3C web annotations model that's currently in recommendation status at W3C. And by the way, those of you who attended the IIIF workshop yesterday have gotten a much fuller and better overview of this model. I'll just give a brief summary of what we're doing with it. So the web annotations model models relationships between information objects. And it was designed to model born digital annotations that reference web based targets, as opposed to physical data carriers. But it actually generalizes well to a library environment where a catalog reference, a catalog record references information, which could be on the physical data carrier or on a digital surrogate. The spec says, I quote, an annotation is considered to be a set of connected resources, typically including a body and a target, which you see here, and conveys that the body is related to the target. The exact nature of this relationship changes according to the intention of the annotation. But the body is most frequently somehow about the target, end quote. And so this, of course, is equally true for our stringy dedications in the books from Deridas Library, where the annotation, that is to say, the metadata package provided by the cataloger, references a body, the content of the dedication, on a target, the data carrier or digital surrogate. And then as you can see on the right here, conceptually the target hooks nicely into the existing bit frame structure. I should say that the idea for using web annotations came out of conversations between members of my group and Tim Cole and some others, and was then developed and published in the Journal of Library Metadata by my colleagues and former colleague, Tim Thompson, Jennifer Baxmeyer, Joyce Bell, and Peter Green. Applying this model to the hypocrite dedication and meta annotation. We see here the ANO1 or annotation 1, the information package regarding the dedication itself. Then there's an ANO2, that's the package regarding the comment on the dedication. And then we have an ANO3 that describes our, meaning the cataloging staff's, identification activities. If I start plugging in some data, this is what it would look like. I don't know that you can really read this, but I'll walk you through. So this is ANO1. ANO1 has a body called body1, which is the text of the dedication, and it has a target page x, and that's because I neglected to look up the actual page number. Page x has as its scope item 1, which in turn is our bit frame item. The purpose of body1 in ANO1 is dedicating. ANO2 in turn would have as its body a body2, and then point to body1. And it would look like this. So body2, the text of hypocrite, has the purpose of commenting on the target body1, the text of the dedication. This is a very, very simplified view. It's like irresponsibly simplified of how we created and consolidated the bibliographic and annotation data into a linked data record. And we're still in the process of doing that. So in very simple terms, we started with two data sources. That's a gross lie, but conceptually, there were two data sources. The data for the bibliographic item and the data for the dedication. We modeled one on bit frame and the other in web annotations, put both through their respective sausage makers, and voila. At the end, we got linked data out of it. This is the non-romanticized version in Peter Green's retrospective workflow analysis of all the steps that we actually had to take. And the details of this aren't really as important as just showing you the fact of the multiple contortions that we had to twist ourselves and our data into on the path to a consolidated record. I will mention two things, though, that were annoyances or major complications. One is that we had to go through mark to get to bit frame, because right now we can't produce bit frame natively. And so that, of course, is kind of a roadblock. We also ended up having to make our own editor to create the records for the annotations, and I'll talk a little more about that later. This is that editor. It is a tool that Peter Green built for us, so we could move forward because our timeline didn't sync up with the development of the editing tools that are being developed by LD4L. And we just needed something to move on. So there are a lot of disclaimers associated with this tool. It is not meant as a community tool. It's a one-off for our internal use. It doesn't quite do all that we want it to do. For example, it cannot yet accommodate the meta annotation, the hypocrite bit, unless we put it in the code manually. And that is why Peter calls it MacGyverware. This is the landing page. You can expand a whole suite of background documents here, including step-by-step instructions, and that is because the editor assumes as its users our regular cataloging staff who are not necessarily familiar with linked data. So here, if they want to, they have all the background materials. You can retrieve records by ID. We're starting from a prepared set of 489. And I've randomly selected record 450 here for no good reason at all. What you get is an image of the dedication that you can open up to double-check it against the transcription. A text box with the transcription. An entification box, which we'll use in a moment. That's the green box here. And the code template below. The buttons in the center there both are buttons to move to the next step and also show you what you still have to do, the steps in the process. Here, you can expand the view of the incoming metadata. So there's a link to the finding aid record, the OCLC record, the WorldCAD work record, among other things. And then this is the view of the actual dedication for double-checking purposes. And assuming that is okay, we can start antifying. And that is done by highlighting the entity. In this case, that's a person. So I click person in my radio button there. What that does is populate the identification field with 12 characters to the left and to the right. And then it appends the code you see below to the template. The next step is to manually edit the template. The dedicated is presumed to be the first to be sent to the template. And then the author of the dedication is the translator Marie Claire Pasquiet, which we know from the EAD record. So I've given her a via URL here, too. And then the tool allows you to edit the template. And then the second step is to add the error sign. And the second step is you have to do two types of Cameron transactions to try to show you what the dedicates. I suppose this is an e-mail where you see what the attractor is. If you're using free but arrive rate line services and DAT support he ersoup here, lots of other things. of URL here too. And then the tool allows you to view this graph, which you probably can't read, but that's okay. The blue bubbles are the bit frame entities. The red bubble is the OCLC work record. And the yellow bubbles here are what I just did. So there is one annotation motivated by describing, the body of which has the purpose of inscribing, and the other two where I tagged the names are motivated by identifying, and the body in those cases has the purpose of tagging. And I'll just quickly walk you through this. We are not sending the files to a triple store yet. It all lives on the file system. The tool outputs the turtle file, an SVG file, and an HTML file. It's a basex application. This is the file structure. There are two main files, the form itself, and an xQuery module. We will make that tool available at some point in the future. Just not yet. It actually keeps changing on a daily basis. And finally, just a note on our lessons learned and challenges. This is our original grant timeline with our goals. And when we first started the project, we quite underestimated how long the data modeling in particular would take. And we didn't quite count on having to make our own editor because at the time we were still thinking that, well, something is going to come out of LD4L, and we're going to use that. But the timelines just didn't converge that way. So we spent time building this editor. What that meant for us was that we had to give up on some of our goals, like working on the cataloger's workbench editor, or involvement in a rare mat or other community ontology development efforts, and also our anticipated use of RetroLib and Biblioteco. Our next steps are now to refine our tool and the production workflow, make our test data set available, and then hopefully start building some queries on it. And I'll be happy to answer any questions to the best of my ability. But please feel free to reach out to any of these good people who will probably be able to answer them more competently. Thank you. Thanks a lot, Regine. Are there any questions on this project? Yeah. Thank you again. This was quite inspiring, but if I was a philosopher, I would be quite skeptical now. Because according to Derrida, I think two people using this tool would use this tool in very different ways. And I think the annotations they produce would be quite different. So for a philosopher, what is the outcome of this? I'm going to take the pedestrian approach to this question and say a few of our catalogers, our philosophers, or would take the philosophical approach to this. If you remember, we have a step-by-step instruction manual here, the first bullet point, the how-to. It really tells you what you need to do, step-by-step, with very, I think, well, I might be wrong. But I think it leaves very little room for doubt. So it's just a matter of doing the work, of tagging the name. Is it a person or is it a place? Is this person also the dedicator or is it not? And the tool does the rest. So I'm actually a little more optimistic. Now, we've just started producing records this way, so it might very well turn out that you are right, and we have to go back and be more restrictive about what we do. But for the moment, it seems very streamlined, and I'm a little more optimistic, I think, that we'll get uniform output. There was another question. Could you explain a little bit the outcome? What could we expect if you finished the project? I didn't really understand the use case. I'm sorry, but will there be a portal for researchers or will this be part of your catalog? So the use case is that in the end, you want to be able to query this data, right? And you're right, I apologize. I didn't really give examples of that. But you could then do something, if we link it to external data sources, that of course is something that we haven't even begun to do. But let's assume we get to that step. We publish our data set. It is, in fact, pulling in data from, say, Wikipedia, DBpedia from a variety of sources. You could then begin to answer questions like, say, how many people, publishing in French, are alive in a certain time frame, and members of a particular school of thought gave books to Derrida. And then researchers can draw inferences about in which circles Derrida was active, how he was read, who he interacted with, and that sort of thing. Do you have your answer? Yeah, another question. Yeah, I thought it was very interesting what you showed. And I was wondering on the conceptual model, because now we have a lot of data hidden in note fields and annotations. And I think the assumption still is that you have a work that's the printed book, and then you have notes. Did you consider the idea that you actually have three works, the text, the text of the dedication, and the work of Derrida, and then connect it as a complex work? I was kind of worried that would come up. We haven't, we haven't. It's not like that thought hasn't occurred to us. But it's a little overkill, maybe, for what we're trying to do, because really all we're trying to do is make entities available for discovery in these annotations. And for that, it seems like the annotation, the web annotation model, does the trick, and it's a lightweight, fairly easily implementable solution to what we're trying to do. That said, we keep saying to ourselves that we really need to tweak the model, and we really need to rethink this and rethink that. So this is not written in stone. But I don't think that at this point in the project, we'll go back to that level of conceptual rethinking. We'll just, I think, stick with this lightweight solution and tweak it a little bit. Any question? But I just have one regarding the big diagram with your, the whole workflow. And I was just wondering the decision to have all these separate tools. Was it only guided by the fact that you were expecting something from this other LD4 project? Or is it also because you had other requirements, such as having only open source tool? I'm just wondering in the world of tools, whether you looked at everything and nothing was suitable. Just what was the thought process to go for a workflow that is so fragmented in a way? It is. Partly it has to do with dependencies that didn't work out the way we thought they would. Partly it has to do with the fragmented nature of our incoming data, because it really was an Excel spreadsheet there, a Word document that we had to scrape there. We all consolidated it in the database. It went to, you know. And part of it, which is a challenge that I actually had in my notes and then kind of glossed over because I thought, well, everybody has that challenge, is that we didn't really plan our project. So this is a project management issue. We didn't really plan it very stringently from the first moment. We couldn't have, because we didn't quite know yet what we were dealing with. But if we had been in a position to do that, that would have been, it would have made everything so much easier. So that's part of the answer. The other answer is that it's really, you know, we are a group of five people. Each of us brings certain skills, basically a certain toolbox to this project, and we use the tools that we find in our toolbox. So if we know how to get it from Excel to this other thing, that's what we're going to do because it does the job. And so, yes, there are a couple of eddies in here. It's a little tortuous, but it got us to where we needed to be. Had we known better what we were dealing with from the first moment, we would have planned it much differently. Okay. Thank you. I think it's quite a good, maybe a good point for people that want to start such an effort on their own as well. Okay. Well, thank you very much for your presentation. Thank you. Go ahead.
 Good morning. My name is Regina Heberlein. I'm a metadata specialist in the Department  of Special Collections at Princeton University. And it is my great pleasure to talk to you  today about a project we're involved in, in that we are a participant in the linked data  for production initiative. Our group consists of five people. Joyce Bell, who is our project  lead, Jennifer Bax, Maya Peter Green, Lydia Santorelli, and myself. And also until March  of this year, when he defected to Yale. Tim Thompson was also a member of our group. Many  of you will know this. Our group is part of the Melon-funded linked data for production  project, which actually includes six research libraries. So Columbia Cornell-Harvard Library  of Congress, Stanford, and Princeton. And the purpose of the grant is to explore ways to  move from mark-based production workflows to production workflows based on linked open  data. Each partner library in the grant works independently on a local use case, and that  includes the data modeling and as the case may be, the domain-specific ontology development.  LD4P is also part of the larger LD4 family, which includes the Melon-funded linked data  for libraries, LD4L, which concluded in 2016. And LD4L Labs, which runs 2016 to 2018 and  is focused on tool production. LD4P is a two-year grant that started in April 2016. So we're  fast approaching the finish line. So Princeton is using a selection from the library of Jacques  Derrida as its project test case. This is an author library of about 19,000 items that was  acquired by Princeton University in 2014. Jacques Derrida, of course, was a French philosopher.  He's one of the major figures associated with post-structuralism and post-modern philosophy.  And the collection has met with correspondingly high interest from researchers.  The collection includes Derrida's working library, which is one of the things that makes it so  interesting, as well as books belonging either jointly or separately to Jacques and his wife,  Marguerite. And in a handful of cases also to their two sons. It includes a variety of formats,  monograph volumes, certainly serial issues, off-prints, clippings, typescripts, etc.  That were largely accumulated in the course of Jacques and Marguerite's professional activities,  but there is also a set that represents the family's leisure reading.  So, this is another view of the library. What makes this collection so interesting from a linked data  perspective is that it embodies many and different types of relationships that aren't easy to either  expose or let alone make functional in a library environment with our current descriptive tools.  I'm going to give you three examples, the last of which is our use case. So, for example, Derrida  extensively annotated his books. So, there's a lot of marginalia and also a lot of insertions.  And for those interested in studying Derrida's reading habits or intellectual formation,  for example, those represent a record of a dialogue between Derrida and the text.  There is currently another project exploring this at Princeton University. It's called Derrida's  Margins, and I believe they're not using a linked data approach, even though I think it lends itself  to one. Another really interesting type of relationship in this collection is the shelving  order, meaning the precise location of the books, because it is meaningful in that where a book  was kept, so for example, in the studio or somewhere else in the house, and who its neighbors were,  contains information about how it was used by Derrida. I'm an archivist by training, and archivists  call this kind of meaningful background context. This is the kind of context that allows you to  know what you're looking at, but it is not contained in the resource itself.  And so we tried to address the presence of substantial contextual information in this collection  by treating it as an archival collection. So it is described in a finding aid rather than in individual  mark records, and that allowed us to display the original shelf order and to allow users to sort by  it, among other data points. Of course, what that gives you is still basically a  browse list, so the functionality is very limited. Last, not least, to get to our LD4P use case.  Excuse me. The collection contains a large run of over 6,000 items of books that were gifted,  and in many cases inscribed to Derrida, and also members of his household. Derrida famously never  threw away a book, including those he never opened. There are some shrink-wrapped ones that we got as  part of the collection, and obviously never read. And there has been active scholarly interest in  these dedications, because they represent a physical manifestation of Derrida's reader network  and intellectual influence. Currently, this sort of information is buried in a note in the record.  I'll show you that in just a bit, and we really have no mechanisms to include it in our discovery  functionality. Here you see some examples. For our project, we selected about 500 of these  dedications, pretty randomly, even though we did try to filter out living gifters to be sensitive  to privacy concerns. And so the goal of our project is to explore and develop a production-oriented  workflow that allows us to capture and make discoverable the relationships embedded in the  dedications. And to that end, we have been working at creating a dataset that combines in-linked  open data format, the bibliographic item data, and when I say bibliographic item, I really mean  the bit frame item, and antified dedication data. This one is an amusing example, also an interesting  example. It's amusing because Derrida has annotated a dedication, and the dedication is pretty warm  and cordial, you know, to the effect of ingratitude for your friendship, and with my strong and faithful  and great admiration, yada, yada, yada, and his response is hypocrite, exclamation point.  So this is actually also a very interesting case of a meta annotation, excuse me, annotation,  and I'll use this example for a while to demonstrate what we can and cannot do with it in this project.  So as mentioned before, we currently describe this collection in a finding aid, not in a  mark record. This is a snippet of the XML. It's an encoded archival description, which is an XML  schema for archival data. You notice the big blob in the center there. It's just a string of text.  This, by the way, would be a very similarly sad situation in a mark record, where this would  also be in a note field. The data is completely unstructured, and the entities are just embedded  in a string. And I've circled sort of the low hanging fruit here, even though you could go further.  So we developed a data model to structure this data, which is based on the W3C web annotations  model that's currently in recommendation status at W3C. And by the way, those of you who attended  the IIIF workshop yesterday have gotten a much fuller and better overview of this model. I'll  just give a brief summary of what we're doing with it. So the web annotations model models  relationships between information objects. And it was designed to model born digital annotations  that reference web based targets, as opposed to physical data carriers. But it actually  generalizes well to a library environment where a catalog reference, a catalog record references  information, which could be on the physical data carrier or on a digital surrogate.  The spec says, I quote, an annotation is considered to be a set of connected resources,  typically including a body and a target, which you see here, and conveys that the body is related  to the target. The exact nature of this relationship changes according to the intention  of the annotation. But the body is most frequently somehow about the target, end quote. And so this,  of course, is equally true for our stringy dedications in the books from Deridas Library,  where the annotation, that is to say, the metadata package provided by the cataloger,  references a body, the content of the dedication, on a target, the data carrier or digital surrogate.  And then as you can see on the right here, conceptually the target hooks nicely into the  existing bit frame structure. I should say that the idea for using web annotations came out of  conversations between members of my group and Tim Cole and some others, and was then developed  and published in the Journal of Library Metadata by my colleagues and former colleague, Tim Thompson,  Jennifer Baxmeyer, Joyce Bell, and Peter Green. Applying this model to the hypocrite dedication  and meta annotation. We see here the ANO1 or annotation 1, the information package regarding  the dedication itself. Then there's an ANO2, that's the package regarding the comment on  the dedication. And then we have an ANO3 that describes our, meaning the cataloging staff's,  identification activities. If I start plugging in some data, this is what it would look like.  I don't know that you can really read this, but I'll walk you through. So this is ANO1.  ANO1 has a body called body1, which is the text of the dedication, and it has a target page x,  and that's because I neglected to look up the actual page number. Page x has as its scope item 1,  which in turn is our bit frame item. The purpose of body1 in ANO1 is dedicating. ANO2 in turn would  have as its body a body2, and then point to body1. And it would look like this. So body2, the text of  hypocrite, has the purpose of commenting on the target body1, the text of the dedication.  This is a very, very simplified view. It's like irresponsibly simplified of how we created and  consolidated the bibliographic and annotation data into a linked data record. And we're still in the  process of doing that. So in very simple terms, we started with two data sources. That's a gross  lie, but conceptually, there were two data sources. The data for the bibliographic item and the data  for the dedication. We modeled one on bit frame and the other in web annotations, put both through  their respective sausage makers, and voila. At the end, we got linked data out of it.  This is the non-romanticized version in Peter Green's retrospective workflow analysis  of all the steps that we actually had to take. And the details of this aren't really as important  as just showing you the fact of the multiple contortions that we had to twist ourselves and  our data into on the path to a consolidated record. I will mention two things, though, that were  annoyances or major complications. One is that we had to go through mark to get to bit frame,  because right now we can't produce bit frame natively. And so that, of course, is kind of a  roadblock. We also ended up having to make our own editor to create the records for the annotations,  and I'll talk a little more about that later. This is that editor. It is a tool that Peter Green  built for us, so we could move forward because our timeline didn't sync up with the development of  the editing tools that are being developed by LD4L. And we just needed something to move on. So  there are a lot of disclaimers associated with this tool. It is not meant as a community tool.  It's a one-off for our internal use. It doesn't quite do all that we want it to do. For example,  it cannot yet accommodate the meta annotation, the hypocrite bit, unless we put it in the code  manually. And that is why Peter calls it MacGyverware. This is the landing page. You can expand a whole  suite of background documents here, including step-by-step instructions, and that is because  the editor assumes as its users our regular cataloging staff who are not necessarily familiar  with linked data. So here, if they want to, they have all the background materials.  You can retrieve records by ID. We're starting from a prepared set of 489.  And I've randomly selected record 450 here for no good reason at all.  What you get is an image of the dedication that you can open up to double-check it against the  transcription. A text box with the transcription. An entification box, which we'll use in a moment.  That's the green box here. And the code template below. The buttons in the center there both  are buttons to move to the next step and also show you what you still have to do, the steps in the  process. Here, you can expand the view of the incoming metadata. So there's a link to the  finding aid record, the OCLC record, the WorldCAD work record, among other things.  And then this is the view of the actual dedication for double-checking purposes.  And assuming that is okay, we can start antifying. And that is done by highlighting the entity.  In this case, that's a person. So I click person in my radio button there.  What that does is populate the identification field with 12 characters to the left and to the right.  And then it appends the code you see below to the template. The next step is to manually edit the  template. The dedicated is presumed to be the first to be sent to the template.  And then the author of the dedication is the translator Marie Claire Pasquiet, which we know  from the EAD record. So I've given her a via URL here, too. And then the tool allows you to  edit the template. And then the second step is to add the  error sign. And the second step is you have to do two types of  Cameron transactions to try to show you what the dedicates.  I suppose this is an e-mail where you see what the  attractor is. If you're using free but arrive rate line services and  DAT support he ersoup here, lots of other things.  of URL here too.  And then the tool allows you to view this graph, which you probably can't read, but  that's okay.  The blue bubbles are the bit frame entities.  The red bubble is the OCLC work record.  And the yellow bubbles here are what I just did.  So there is one annotation motivated by describing, the body of which has the purpose of inscribing,  and the other two where I tagged the names are motivated by identifying, and the body  in those cases has the purpose of tagging.  And I'll just quickly walk you through this.  We are not sending the files to a triple store yet.  It all lives on the file system.  The tool outputs the turtle file, an SVG file, and an HTML file.  It's a basex application.  This is the file structure.  There are two main files, the form itself, and an xQuery module.  We will make that tool available at some point in the future.  Just not yet.  It actually keeps changing on a daily basis.  And finally, just a note on our lessons learned and challenges.  This is our original grant timeline with our goals.  And when we first started the project, we quite underestimated how long the data modeling  in particular would take.  And we didn't quite count on having to make our own editor because at the time we were  still thinking that, well, something is going to come out of LD4L, and we're going to use  that.  But the timelines just didn't converge that way.  So we spent time building this editor.  What that meant for us was that we had to give up on some of our goals, like working  on the cataloger's workbench editor, or involvement in a rare mat or other community ontology  development efforts, and also our anticipated use of RetroLib and Biblioteco.  Our next steps are now to refine our tool and the production workflow, make our test  data set available, and then hopefully start building some queries on it.  And I'll be happy to answer any questions to the best of my ability.  But please feel free to reach out to any of these good people who will probably be able  to answer them more competently.  Thank you.  Thanks a lot, Regine.  Are there any questions on this project?  Yeah.  Thank you again.  This was quite inspiring, but if I was a philosopher, I would be quite skeptical now.  Because according to Derrida, I think two people using this tool would use this tool  in very different ways.  And I think the annotations they produce would be quite different.  So for a philosopher, what is the outcome of this?  I'm going to take the pedestrian approach to this question and say a few of our catalogers,  our philosophers, or would take the philosophical approach to this.  If you remember, we have a step-by-step instruction manual here, the first bullet point, the how-to.  It really tells you what you need to do, step-by-step, with very, I think, well, I might be wrong.  But I think it leaves very little room for doubt.  So it's just a matter of doing the work, of tagging the name.  Is it a person or is it a place?  Is this person also the dedicator or is it not?  And the tool does the rest.  So I'm actually a little more optimistic.  Now, we've just started producing records this way, so it might very well turn out that  you are right, and we have to go back and be more restrictive about what we do.  But for the moment, it seems very streamlined, and I'm a little more optimistic, I think,  that we'll get uniform output.  There was another question.  Could you explain a little bit the outcome?  What could we expect if you finished the project?  I didn't really understand the use case.  I'm sorry, but will there be a portal for researchers or will this be part of your catalog?  So the use case is that in the end, you want to be able to query this data, right?  And you're right, I apologize.  I didn't really give examples of that.  But you could then do something, if we link it to external data sources, that of course  is something that we haven't even begun to do.  But let's assume we get to that step.  We publish our data set.  It is, in fact, pulling in data from, say, Wikipedia, DBpedia from a variety of sources.  You could then begin to answer questions like, say, how many people, publishing in French,  are alive in a certain time frame, and members of a particular school of thought gave books  to Derrida.  And then researchers can draw inferences about in which circles Derrida was active, how he  was read, who he interacted with, and that sort of thing.  Do you have your answer?  Yeah, another question.  Yeah, I thought it was very interesting what you showed.  And I was wondering on the conceptual model, because now we have a lot of data hidden in  note fields and annotations.  And I think the assumption still is that you have a work that's the printed book, and then  you have notes.  Did you consider the idea that you actually have three works, the text, the text of the  dedication, and the work of Derrida, and then connect it as a complex work?  I was kind of worried that would come up.  We haven't, we haven't.  It's not like that thought hasn't occurred to us.  But it's a little overkill, maybe, for what we're trying to do, because really all we're  trying to do is make entities available for discovery in these annotations.  And for that, it seems like the annotation, the web annotation model, does the trick,  and it's a lightweight, fairly easily implementable solution to what we're trying to do.  That said, we keep saying to ourselves that we really need to tweak the model, and we  really need to rethink this and rethink that.  So this is not written in stone.  But I don't think that at this point in the project, we'll go back to that level of conceptual  rethinking.  We'll just, I think, stick with this lightweight solution and tweak it a little bit.  Any question?  But I just have one regarding the big diagram with your, the whole workflow.  And I was just wondering the decision to have all these separate tools.  Was it only guided by the fact that you were expecting something from this other LD4 project?  Or is it also because you had other requirements, such as having only open source tool?  I'm just wondering in the world of tools, whether you looked at everything and nothing  was suitable.  Just what was the thought process to go for a workflow that is so fragmented in a way?  It is.  Partly it has to do with dependencies that didn't work out the way we thought they would.  Partly it has to do with the fragmented nature of our incoming data, because it really was  an Excel spreadsheet there, a Word document that we had to scrape there.  We all consolidated it in the database.  It went to, you know.  And part of it, which is a challenge that I actually had in my notes and then kind of  glossed over because I thought, well, everybody has that challenge, is that we didn't really  plan our project.  So this is a project management issue.  We didn't really plan it very stringently from the first moment.  We couldn't have, because we didn't quite know yet what we were dealing with.  But if we had been in a position to do that, that would have been, it would have made everything  so much easier.  So that's part of the answer.  The other answer is that it's really, you know, we are a group of five people.  Each of us brings certain skills, basically a certain toolbox to this project, and we  use the tools that we find in our toolbox.  So if we know how to get it from Excel to this other thing, that's what we're going  to do because it does the job.  And so, yes, there are a couple of eddies in here.  It's a little tortuous, but it got us to where we needed to be.  Had we known better what we were dealing with from the first moment, we would have planned  it much differently.  Okay.  Thank you.  I think it's quite a good, maybe a good point for people that want to start such an effort  on their own as well.  Okay.  Well, thank you very much for your presentation.  Thank you.  Go ahead.
De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_0_287.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_288_347.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_348_683.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_684_9083.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_9084_9371.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_9372_18239.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_18240_20867.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_20868_20939.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_20940_21347.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_21348_21443.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_21444_22691.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_22692_27395.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_27396_30455.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_30456_30599.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_30600_30671.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_30672_31163.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_31164_31223.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_31224_31307.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_31308_34547.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_34548_35207.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_35208_35699.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_35700_35759.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_35760_36011.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_36012_36059.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_36060_37067.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_37068_37175.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_37176_38147.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_38148_39095.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_39096_39347.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_39348_39695.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_39696_39911.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_39912_40463.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_40464_40511.png De_l_Une_a_l_Autre__Towards_Linked_Data_in_Special_izrmju4kHBo_40512_41476.png