Will you be my bf: forever? Analysing Techniques for Conversion to BIBFRAME
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
Bigelow, Ian
Farnel, Sharon
The University of Alberta is actively trying to ramp up for Linked Data through local experimentation, research and partnerships with other institutions. Though BIBFRAME is still in development, several transformation tools have already been created, and with many libraries thinking about planning for moving to Linked Data it would seem timely to compare approaches to moving legacy MARC data to BIBFRAME. Setting aside the question of whether BIBFRAME should be the approach for libraries to move to Linked Data, this investigation aimed at comparing two tools for converting MARC to bf:2.0: A) LC MARC to BIBFRAME XSLT: An XSLT 1.0 application aimed at converting MARC to RDF/XML released in March 2017; and B) Casalini SHARE Virtual Discovery Environment: A project by Casalini Libri and @Cult to develop a Linked Data discovery environment, including a conversion tool for MARC to bf:2.0 RDF. Through the comparison and analysis of these transformation tools several topics will be explored: Comparison of underlying development models and performance of the tools; Comparison of data element conversion and impact for discovery; Impact of content standard on conversion efficacy (AACR vs. RDA); Implications for conversions for various formats (monographs, serials, et cetera); URI enrichment pre/post conversion; In house and vendor workflow implications.
 Thank you for having me. I'm Ian Bigelove, the cataloging coordinator for the University of Alberta Libraries, and I'm presenting here for myself, Sharon Farnell, our metadata coordinator, and Dhanush Devoudi, one of our metadata specialists in bibliographic services. So bib frame, bib frame, bib frame. Will you be my bib frame forever? The University of Alberta Libraries has been actively at least trying to ramp up for linked data for some time. And one of the aspects of that has been assessing bib frame with intent to implement something, sometime. So we've really been trying to ask a few really broad questions. How well does bib frame transition our data? Which flavor of bib frame will serve us best? How much should be invested in mark enrichment and development given this? How can we make bib frame data discoverable? And what could workflow look like for a bib frame pilot or implementation? So enter today's conversation, comparing the bib frame conversion to the Cassellini share VDE, virtual discovery environment program, and the bib frame Library of Congress converter. And while we don't want to make things too competitive, we do have a few horse races running with this comparison. One being the two conversion methods. Also in-house versus vendor supported processes. And also mark versus post mark to link data conversion, URI enrichment efficacy. So the bib frame 2.0 converter from the Library of Congress is an XSLT. It was originally released back in March 2017. It's available on GitHub for download. And so it's essentially a straightforward XSLT, at least the version that we used. This is it just as used in OxygenXML editor. So it really is take markXML, process it through the XSLT and bib frame 2.0. XML RDF is output. And we wanted to take that and do a little bit of further experimentation to see how we can automate that process, work with enrichment, post process and such. And so essentially we've been automating using the use of pie mark and open refine to convert and enrich our data. Really trying to transform and enrich at the collection level. And we've got a collection of about five and a half million titles, maybe seven and a half million volumes. So a lot of data to process through. And once in place, along with the Casselini data, we'll have two versions of our collection in bib frame 2.0. So lots of data to look at and play around with, lots of experimentation. More importantly though, we want to come up with a process where we can keep that data up to date. So for the in-house process, all names were extracted from bib frame files using the XSLT file. Named types were extracted to determine the proper search API for better results. Example.org. Your eyes from RDF about were extracted to be used as key when adjusting the rich name back into the bib frame file. Then the TSV files from the previous step were uploaded into open refine. And after some cleanup, generally speaking, reconciliation work was done against LC name authorities via an LCSH. We plan to look at some others at a future date, but this is what we started with. And this slide just represents some processing times. This is for a file set of 10,000 records, I believe, which not insignificant times, but manageable. It's worth noting that some of this does take some computation power or a little bit of time to work through. So when you're looking at large collections to work with, we've been making use of both our local systems, but also Compute Canada for cloud-based computing. And so as files were separated into segments, processes were done in parallel with the local machine doing, working on adjusting and rich DRIs into the bib frame. And the cloud instance would work on, say, enriching names and subjects with URIs at the same time. It's also worth noting that we're working on a script to automate this process because for a collection of our size, we don't want to have to do that 600 times. And we also want to be able to keep the data up to date once we go through the full set. So entity matching with the open or fine process, these are just some of the numbers we had from imprint files, sort of the general collection thus far. A few areas of caution worth noting, one, essentially due to some data errors within the mark data, we did have some files that were kicked back by the process, so we'll have to do some follow-up work with those. Also while we had a pretty good success rate with matching, I'm thinking about the number of entities that probably don't have authorities anyway, had a pretty good success rate, but we want to do a little bit more analysis to make sure we're not getting too many false hits, sort of, and we can adjust our thresholds accordingly. So changing gears and looking at the Castellini project. So it's at Colt and Castellini-Libri partnership. Originally, the Alliata project, co-financed by the European Union in 2013 to 2015, applied link data paradigm using FURBOR-OO based technologies, and essentially the share of EDE projects sort of picked up from that. It's a prototype virtual discovery environment with three-bit frame layer architecture, person work, instance and item, and conversion process, taking Mark 21 to RDF. So you can see the project participants there on the left, including the Library of Congress, and a range of very large research libraries within the United States and Canada, which combined to make for a very substantial data set that's being processed. With phase one of the projects, Mark IV, 1985 and 2015 in print, so anything published in those years, was returned with URIs enriched in Mark format. That data was also returned back in Bivframe 2.0. Through the processes, they worked on entity identification, reconciliation and data clustering. They released the share of virtual discovery environment tool with searchable imprint data and access to that data through Blazegraph. With phase two was the creation of a relationship database to support entity identification, improvements to the process in general. The base file of the participating libraries was returned or slotted to be returned, and this is still ongoing, in Bivframe 2.0. And the Mark data is also to be returned with enrichments and URIs added. And another further deliverable was web discoverability through application of other ontologies such as schema.org. So this is the general process for the share of the project, and it can be broken into two I guess main areas. The first one being the authified process. It's worth noting that they start with the Mark data for a lot of their work with clustering, entity detection and enrichment. And a tool called Relator Term Detection where they essentially use text mining to add related terms to a range of different pieces of data. That rich mark output is then taken through their lotify process where the Mark is converted into Bivframe 2.0. And this is just a sample of their share VDE platform, just showing a little bit of Shakespeare. And you'll see that there's a few differences to, you know, sort of the standard displays that you might note as the other forms along the right there. They've got links to Wikidata, LC, BNF and VF, some information from Wikipedia down below the screen which you can't see, the works will be broken out. And they've even managed to take it and link it directly into our blacklight discovery layer so you can go down to the, right down to the holding level. So there is a phase three to this project slotted and back in October there was a meeting at the Library of Congress to discuss and use cases for that. And while some of that's still being sort of worked out, in general the idea is to publish all the participants data into that share virtual discovery environment platform, incorporate the ability to batch update the record sets with library exports, to be able to have an enhanced data back to libraries in an automated way, the ability to edit the information in share VDE through cataloging tools, have different reports and develop original cataloging workflows. So the general timeline for this is three years which is very ambitious and in general it's looking much less like an exploratory project and really big frame implementation on large scale which is very interesting if it gets off the ground. And so with some of this in mind we really wanted to have a way to start analyzing some of this and sort of see how data transformed through these processes. Now I only have a little bit of time so we needed to try to focus on a few different examples to highlight some of the analysis that we've done and some of the differences between the two conversion tools. So one good example is looking at production, publication, distribution, manufacture, statements, the LCXSLT program, strips, brackets and other marks of punctuation for place, agent and date. This is, you can think of that as you will, it's perhaps more interesting for older data before RDA where those brackets meant a lot more. But in contrast the share VDE transformation still keeps that punctuation in the different brackets. So they meant URI structure to cluster the data together. Which what you see is becomes something of a common approach that they take with different things. Now similarly with preferred title whereas the LCXSLT makes use of the appropriate mark fields to generate preferred title for work information into BivFrame. The share VDE, again, they meant a URI structure for work titles and instance titles to cluster information related to each. For creators, contributors and relators, again, LCXSLT makes use of agents and roles. Share VDE, you see here they've got that Agent 78151, they've minted their own URI for that particular agent which then they point to the BivFrame agent and a range of other associated pieces of information. Another very interesting piece of point of comparison, the LCXSLT earlier records lacking relationship designators, so a lot of this stuff pre-RDA, they signed the contributor role to a lot of those just through the automated process of conversion. This is logical, I'm not complaining. But through share VDE, they have this related term detection where they use text analysis to sort of associate roles from other mark fields. And this is just an example below where from our data there was no relationship designator assigned but they've managed to pull that from the mark data and assign the creator term to it. Very interesting. So one of the other examinations was looking at URI enrichment both before and after. So we've recently had some very interesting guidance on the use of URI and mark data from the PCC task group on URI and mark. Back at the most recent MAC meeting at ALA annual, three new proposals were passed. One for the provision of the use of subfield zero and subfield one in mark data with subfield zero for URIs that identify a record or authority entity describing that thing. Subfield one for URIs that directly identify the thing itself, so real world objects. A separate proposal redefined subfield four, defining it to compass URIs for relationships in the mark data. And we've got a brand new 758 field in the mark data for identifier for resources relating to the resource described in the bibliographic records. So primary resource identifiers, think of OCLC works for instance. OCLC work identifiers, URIs. Just one example. So how did this data fare through the conversion processes? Well, from pre-enriched mark data that we worked with, you can see this is just an example. But id.loc.gov information seemed to be brought over through the conversion quite well. Same with ViF. Worked just fine. What we did find interesting is that, you know, using mark edit for instance to enrich the mark data beforehand, you can add a lot of the URI for different RDA vocabularies, but much of these from controlled vocabularies are brought over through conversion anyway, begging the question, you know, why do it? You want it in your mark data? Maybe? Also interesting that the LC conversion tool doesn't make use of the new subfield one or some 58EA, but I'm sure that'll come. From Vifreem to enriched post conversion, things seem to work quite well also. Again, just an example. Now both Cassilini has made a few good cases perhaps from getting context by looking at the mark data for further enrichment, by having the URIs sort of generated within the mark data. And there's perhaps a few other arguments there, but certainly there's a use case here that it works quite well doing it post conversion. Again, you may want to ask yourself about what you want to get out of putting URIs in mark if you want to do so. Mark from the Cassilini gets a little bit more speculative because, well, we haven't gotten their data back yet, but they have provided some examples and they've also been working very closely with the PCC task group on URI and mark. So there's just a few examples here. And for the deliverable to have our full collection returned in mark format with URIs added to it, they've currently, they're working through the modeling that they intend to provide those subfield ones, some 58EA and the other information from the new PCC proposals that just recently cleared, which is quite helpful. URI and the Cassilini, BIP Frame 2 data is rather interesting as well. Again, they're making use of these, they're augmented URIs to cluster information, but you'll also note here that they're sort of modeling other relationships within the data itself. You see the use of the ALSAM as to pull together some of the different identifiers. So all this makes us think about workflows a little bit more as well. So transitioning to linked data was never going to be easy. There's several reasons for this. Mark has been around for a very long time, we have lots of it. ALSAM discovery systems we use are built around mark. Staff have also been using mark for a very long time and essentially our entire workflows from resource description, LC, OCLC, other vendors and copying original cataloging depend on mark. It's been 15 years, I can't believe 2002 was 15 years ago. It's been 15 years since Roy Tenet wrote mark must die. But we now find ourselves in a position where non-marked data alternatives do exist. They're not mythical, they're out there. So let's assume that either approach with the Cassilini ShareVD project or in-house processes allows us to fully convert our data. We're pretty much there already. First updates, work through copy and original cataloging workflows, this is all coming. We now have a more general infrastructure challenge. University of Alberta libraries in particular have a lot invested in our current ALS support mechanisms. I think this is probably common. While we utilize blacklight, which we have control of as development, significant work is still being put into its development for current systems. A shift for development to work with mid-frame II data would be major. And our mark data does not represent our entire collection. These all need to be incorporated, of course. There's challenges with doing that with conventional systems. So the University of Alberta libraries and other libraries will need to develop clear strategic direction across units to tackle some of these issues. Even so, our experience from the Canadian link data initiative has highlighted that there are limited resources in any given institution for working towards implementation. And central planning for large scale projects across institutions is challenging. Getting sort of IT support for a group of large research libraries to sort of coordinate together can be a little tricky, a bit of a balancing act. So with this in mind, we do kind of really wonder if we could use an ally to bring about critical mass for change. Maybe something like LaCastelina ShareVD project. We're still analyzing it, but... And thinking further about possible workflows. In-house, we can continue refining the balance of mark versus mid-frame enrichment. Automator processes to finish our full collection. Establish a process for ongoing updates. Get our data into a triple store, and we're sort of experimenting with this already. Set up some kind of discovery on top, whether working with blacklight, Jupiter, another system that's local to us, maybe something else. With LaCastelina ShareVD at the same time, we could continue working with developing phase three use cases. Get our full collection set up with updates. Set up original cataloging workflows. Copy of cataloging workflows. Discovery is already in place, at least as a proof of concept. The production environment would seem like it would be the next logical step. So even if only for short or medium term use, this would give us a lot of breathing room for infrastructure change and learning through process improvement. Either way, we're going to need a lot more coffee. But it's going to be very exciting. And just like RDA, just like Mark, the frame will not be forever, at least no single instance of it. It will continue to develop and improve with time. And at some point, we need to dive in and start working with it. Many thanks. So thank you, Ian, for your talk. Do you have any questions from the audience or comments? Well, I have a question because it's this time of the year. It's almost too late, but you can still write to Santa Claus. So what would you wish from Santa Claus related to Big Frame? What would I wish for Santa Claus was related? Santa Claus, Castellini, I would really love it if they published their vocabulary URI, the URI vocabulary. The Castellini. Yes. Because it's so far the data we've gotten back for them is about 300 gigabytes worth. And reverse engineering that is hard on the eyes. So if they were to publish their vocabulary, which they haven't said they're not going to, but it would be great. Okay. Well, yeah, it's a few weeks before Christmas, so maybe we will get a present. Okay. Any other questions? Okay. Ian, so some of the evaluation that you've done, does that sit somewhere besides the slides? Yeah, the side-by-side comparison stuff, I think it's as more converters become available. I mean, one of the jokes is that if you haven't converted Mark to RDF, whatever, there's a joke there. So just knowing the strengths and weaknesses of each converter, as they stand and I realize it's a moving target, it would be really useful to see that. Yeah, we've got spreadsheets of comparisons. So there's that. We'd like to put some of our analysis into a paper, whether or not it could get published, but also, I mean, this isn't the end of our comparisons in any way, shape, or form, and we haven't even got all our data back. So one of the next logical steps that once we get, there's two versions of the data back from Casselini, one with their sort of native minted URI structure, one that is meant to be autonomous for the institutions using it, that have the URI broken out more definitively. So when we get that back, we want to get it into our triple store and do a little bit more comprehensive analysis of Sparkle as well, so whatever we do, we'll make it available in some way, shape, or form. Yeah. Okay. Anyone else? Okay. We're moving to the coffee break, but just remember to sign up for the lightning talks. So we have good talk. Thank you.
 Thank you for having me.  I'm Ian Bigelove, the cataloging coordinator for the University of Alberta Libraries, and  I'm presenting here for myself, Sharon Farnell, our metadata coordinator, and Dhanush Devoudi,  one of our metadata specialists in bibliographic services.  So bib frame, bib frame, bib frame.  Will you be my bib frame forever?  The University of Alberta Libraries has been actively at least trying to ramp up for linked  data for some time.  And one of the aspects of that has been assessing bib frame with intent to implement something,  sometime.  So we've really been trying to ask a few really broad questions.  How well does bib frame transition our data?  Which flavor of bib frame will serve us best?  How much should be invested in mark enrichment and development given this?  How can we make bib frame data discoverable?  And what could workflow look like for a bib frame pilot or implementation?  So enter today's conversation, comparing the bib frame conversion to the Cassellini  share VDE, virtual discovery environment program, and the bib frame Library of Congress converter.  And while we don't want to make things too competitive, we do have a few horse races  running with this comparison.  One being the two conversion methods.  Also in-house versus vendor supported processes.  And also mark versus post mark to link data conversion, URI enrichment efficacy.  So the bib frame 2.0 converter from the Library of Congress is an XSLT.  It was originally released back in March 2017.  It's available on GitHub for download.  And so it's essentially a straightforward XSLT, at least the version that we used.  This is it just as used in OxygenXML editor.  So it really is take markXML, process it through the XSLT and bib frame 2.0.  XML RDF is output.  And we wanted to take that and do a little bit of further experimentation to see how  we can automate that process, work with enrichment, post process and such.  And so essentially we've been automating using the use of pie mark and open refine to convert  and enrich our data.  Really trying to transform and enrich at the collection level.  And we've got a collection of about five and a half million titles, maybe seven and  a half million volumes.  So a lot of data to process through.  And once in place, along with the Casselini data, we'll have two versions of our collection  in bib frame 2.0.  So lots of data to look at and play around with, lots of experimentation.  More importantly though, we want to come up with a process where we can keep that data  up to date.  So for the in-house process, all names were extracted from bib frame files using the XSLT  file.  Named types were extracted to determine the proper search API for better results.  Example.org.  Your eyes from RDF about were extracted to be used as key when adjusting the rich name  back into the bib frame file.  Then the TSV files from the previous step were uploaded into open refine.  And after some cleanup, generally speaking, reconciliation work was done against LC name  authorities via an LCSH.  We plan to look at some others at a future date, but this is what we started with.  And this slide just represents some processing times.  This is for a file set of 10,000 records, I believe, which not insignificant times, but  manageable.  It's worth noting that some of this does take some computation power or a little bit of  time to work through.  So when you're looking at large collections to work with, we've been making use of both  our local systems, but also Compute Canada for cloud-based computing.  And so as files were separated into segments, processes were done in parallel with the local  machine doing, working on adjusting and rich DRIs into the bib frame.  And the cloud instance would work on, say, enriching names and subjects with URIs at  the same time.  It's also worth noting that we're working on a script to automate this process because  for a collection of our size, we don't want to have to do that 600 times.  And we also want to be able to keep the data up to date once we go through the full set.  So entity matching with the open or fine process, these are just some of the numbers we had  from imprint files, sort of the general collection thus far.  A few areas of caution worth noting, one, essentially due to some data errors within  the mark data, we did have some files that were kicked back by the process, so we'll  have to do some follow-up work with those.  Also while we had a pretty good success rate with matching, I'm thinking about the number  of entities that probably don't have authorities anyway, had a pretty good success rate, but  we want to do a little bit more analysis to make sure we're not getting too many false  hits, sort of, and we can adjust our thresholds accordingly.  So changing gears and looking at the Castellini project.  So it's at Colt and Castellini-Libri partnership.  Originally, the Alliata project, co-financed by the European Union in 2013 to 2015, applied  link data paradigm using FURBOR-OO based technologies, and essentially the share of  EDE projects sort of picked up from that.  It's a prototype virtual discovery environment with three-bit frame layer architecture, person  work, instance and item, and conversion process, taking Mark 21 to RDF.  So you can see the project participants there on the left, including the Library of Congress,  and a range of very large research libraries within the United States and Canada, which  combined to make for a very substantial data set that's being processed.  With phase one of the projects, Mark IV, 1985 and 2015 in print, so anything published  in those years, was returned with URIs enriched in Mark format.  That data was also returned back in Bivframe 2.0.  Through the processes, they worked on entity identification, reconciliation and data clustering.  They released the share of virtual discovery environment tool with searchable imprint data  and access to that data through Blazegraph.  With phase two was the creation of a relationship database to support entity identification, improvements  to the process in general.  The base file of the participating libraries was returned or slotted to be returned, and  this is still ongoing, in Bivframe 2.0.  And the Mark data is also to be returned with enrichments and URIs added.  And another further deliverable was web discoverability through application of other ontologies such  as schema.org.  So this is the general process for the share of the project, and it can be broken into two  I guess main areas.  The first one being the authified process.  It's worth noting that they start with the Mark data for a lot of their work with clustering,  entity detection and enrichment.  And a tool called Relator Term Detection where they essentially use text mining to add related  terms to a range of different pieces of data.  That rich mark output is then taken through their lotify process where the Mark is converted  into Bivframe 2.0.  And this is just a sample of their share VDE platform, just showing a little bit of Shakespeare.  And you'll see that there's a few differences to, you know, sort of the standard displays  that you might note as the other forms along the right there.  They've got links to Wikidata, LC, BNF and VF, some information from Wikipedia down below  the screen which you can't see, the works will be broken out.  And they've even managed to take it and link it directly into our blacklight discovery  layer so you can go down to the, right down to the holding level.  So there is a phase three to this project slotted and back in October there was a meeting  at the Library of Congress to discuss and use cases for that.  And while some of that's still being sort of worked out, in general the idea is to publish  all the participants data into that share virtual discovery environment platform, incorporate  the ability to batch update the record sets with library exports, to be able to have an  enhanced data back to libraries in an automated way, the ability to edit the information in  share VDE through cataloging tools, have different reports and develop original cataloging workflows.  So the general timeline for this is three years which is very ambitious and in general  it's looking much less like an exploratory project and really big frame implementation  on large scale which is very interesting if it gets off the ground.  And so with some of this in mind we really wanted to have a way to start analyzing some  of this and sort of see how data transformed through these processes.  Now I only have a little bit of time so we needed to try to focus on a few different  examples to highlight some of the analysis that we've done and some of the differences  between the two conversion tools.  So one good example is looking at production, publication, distribution, manufacture, statements,  the LCXSLT program, strips, brackets and other marks of punctuation for place, agent and  date.  This is, you can think of that as you will, it's perhaps more interesting for older data  before RDA where those brackets meant a lot more.  But in contrast the share VDE transformation still keeps that punctuation in the different  brackets.  So they meant URI structure to cluster the data together.  Which what you see is becomes something of a common approach that they take with different  things.  Now similarly with preferred title whereas the LCXSLT makes use of the appropriate mark  fields to generate preferred title for work information into BivFrame.  The share VDE, again, they meant a URI structure for work titles and instance titles to cluster  information related to each.  For creators, contributors and relators, again, LCXSLT makes use of agents and roles.  Share VDE, you see here they've got that Agent 78151, they've minted their own URI for that  particular agent which then they point to the BivFrame agent and a range of other associated  pieces of information.  Another very interesting piece of point of comparison, the LCXSLT earlier records lacking  relationship designators, so a lot of this stuff pre-RDA, they signed the contributor  role to a lot of those just through the automated process of conversion.  This is logical, I'm not complaining.  But through share VDE, they have this related term detection where they use text analysis  to sort of associate roles from other mark fields.  And this is just an example below where from our data there was no relationship designator  assigned but they've managed to pull that from the mark data and assign the creator  term to it.  Very interesting.  So one of the other examinations was looking at URI enrichment both before and after.  So we've recently had some very interesting guidance on the use of URI and mark data from  the PCC task group on URI and mark.  Back at the most recent MAC meeting at ALA annual, three new proposals were passed.  One for the provision of the use of subfield zero and subfield one in mark data with subfield  zero for URIs that identify a record or authority entity describing that thing.  Subfield one for URIs that directly identify the thing itself, so real world objects.  A separate proposal redefined subfield four, defining it to compass URIs for relationships  in the mark data.  And we've got a brand new 758 field in the mark data for identifier for resources relating  to the resource described in the bibliographic records.  So primary resource identifiers, think of OCLC works for instance.  OCLC work identifiers, URIs.  Just one example.  So how did this data fare through the conversion processes?  Well, from pre-enriched mark data that we worked with, you can see this is just an example.  But id.loc.gov information seemed to be brought over through the conversion quite well.  Same with ViF.  Worked just fine.  What we did find interesting is that, you know, using mark edit for instance to enrich  the mark data beforehand, you can add a lot of the URI for different RDA vocabularies,  but much of these from controlled vocabularies are brought over through conversion anyway,  begging the question, you know, why do it?  You want it in your mark data?  Maybe?  Also interesting that the LC conversion tool doesn't make use of the new subfield one or  some 58EA, but I'm sure that'll come.  From Vifreem to enriched post conversion, things seem to work quite well also.  Again, just an example.  Now both Cassilini has made a few good cases perhaps from getting context by looking at  the mark data for further enrichment, by having the URIs sort of generated within the mark  data.  And there's perhaps a few other arguments there, but certainly there's a use case here  that it works quite well doing it post conversion.  Again, you may want to ask yourself about what you want to get out of putting URIs in  mark if you want to do so.  Mark from the Cassilini gets a little bit more speculative because, well, we haven't  gotten their data back yet, but they have provided some examples and they've also been  working very closely with the PCC task group on URI and mark.  So there's just a few examples here.  And for the deliverable to have our full collection returned in mark format with URIs added to  it, they've currently, they're working through the modeling that they intend to provide those  subfield ones, some 58EA and the other information from the new PCC proposals that just recently  cleared, which is quite helpful.  URI and the Cassilini, BIP Frame 2 data is rather interesting as well.  Again, they're making use of these, they're augmented URIs to cluster information, but  you'll also note here that they're sort of modeling other relationships within the data  itself.  You see the use of the ALSAM as to pull together some of the different identifiers.  So all this makes us think about workflows a little bit more as well.  So transitioning to linked data was never going to be easy.  There's several reasons for this.  Mark has been around for a very long time, we have lots of it.  ALSAM discovery systems we use are built around mark.  Staff have also been using mark for a very long time and essentially our entire workflows  from resource description, LC, OCLC, other vendors and copying original cataloging depend  on mark.  It's been 15 years, I can't believe 2002 was 15 years ago.  It's been 15 years since Roy Tenet wrote mark must die.  But we now find ourselves in a position where non-marked data alternatives do exist.  They're not mythical, they're out there.  So let's assume that either approach with the Cassilini ShareVD project or in-house  processes allows us to fully convert our data.  We're pretty much there already.  First updates, work through copy and original cataloging workflows, this is all coming.  We now have a more general infrastructure challenge.  University of Alberta libraries in particular have a lot invested in our current ALS support  mechanisms.  I think this is probably common.  While we utilize blacklight, which we have control of as development, significant work  is still being put into its development for current systems.  A shift for development to work with mid-frame II data would be major.  And our mark data does not represent our entire collection.  These all need to be incorporated, of course.  There's challenges with doing that with conventional systems.  So the University of Alberta libraries and other libraries will need to develop clear  strategic direction across units to tackle some of these issues.  Even so, our experience from the Canadian link data initiative has highlighted that there  are limited resources in any given institution for working towards implementation.  And central planning for large scale projects across institutions is challenging.  Getting sort of IT support for a group of large research libraries to sort of coordinate  together can be a little tricky, a bit of a balancing act.  So with this in mind, we do kind of really wonder if we could use an ally to bring about  critical mass for change.  Maybe something like LaCastelina ShareVD project.  We're still analyzing it, but...  And thinking further about possible workflows.  In-house, we can continue refining the balance of mark versus mid-frame enrichment.  Automator processes to finish our full collection.  Establish a process for ongoing updates.  Get our data into a triple store, and we're sort of experimenting with this already.  Set up some kind of discovery on top, whether working with blacklight, Jupiter, another system  that's local to us, maybe something else.  With LaCastelina ShareVD at the same time, we could continue working with developing  phase three use cases.  Get our full collection set up with updates.  Set up original cataloging workflows.  Copy of cataloging workflows.  Discovery is already in place, at least as a proof of concept.  The production environment would seem like it would be the next logical step.  So even if only for short or medium term use, this would give us a lot of breathing room  for infrastructure change and learning through process improvement.  Either way, we're going to need a lot more coffee.  But it's going to be very exciting.  And just like RDA, just like Mark, the frame will not be forever, at least no single instance  of it.  It will continue to develop and improve with time.  And at some point, we need to dive in and start working with it.  Many thanks.  So thank you, Ian, for your talk.  Do you have any questions from the audience or comments?  Well, I have a question because it's this time of the year.  It's almost too late, but you can still write to Santa Claus.  So what would you wish from Santa Claus related to Big Frame?  What would I wish for Santa Claus was related?  Santa Claus, Castellini, I would really love it if they published their vocabulary URI,  the URI vocabulary.  The Castellini.  Yes.  Because it's so far the data we've gotten back for them is about 300 gigabytes worth.  And reverse engineering that is hard on the eyes.  So if they were to publish their vocabulary, which they haven't said they're not going  to, but it would be great.  Okay.  Well, yeah, it's a few weeks before Christmas, so maybe we will get a present.  Okay.  Any other questions?  Okay.  Ian, so some of the evaluation that you've done, does that sit somewhere besides the  slides?  Yeah, the side-by-side comparison stuff, I think it's as more converters become available.  I mean, one of the jokes is that if you haven't converted Mark to RDF, whatever, there's a  joke there.  So just knowing the strengths and weaknesses of each converter, as they stand and I realize  it's a moving target, it would be really useful to see that.  Yeah, we've got spreadsheets of comparisons.  So there's that.  We'd like to put some of our analysis into a paper, whether or not it could get published,  but also, I mean, this isn't the end of our comparisons in any way, shape, or form, and  we haven't even got all our data back.  So one of the next logical steps that once we get, there's two versions of the data  back from Casselini, one with their sort of native minted URI structure, one that is  meant to be autonomous for the institutions using it, that have the URI broken out more  definitively.  So when we get that back, we want to get it into our triple store and do a little bit  more comprehensive analysis of Sparkle as well, so whatever we do, we'll make it available  in some way, shape, or form.  Yeah.  Okay.  Anyone else?  Okay.  We're moving to the coffee break, but just remember to sign up for the lightning talks.  So we have good talk.  Thank you.
Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_0_683.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_684_1151.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_1152_1487.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_1488_2411.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_2412_2867.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_2868_6311.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_6312_8663.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_8664_11555.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_11556_13475.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_13476_15215.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_15216_24179.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_24180_25247.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_25248_27827.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_27828_29243.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_29244_30383.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_30384_30503.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_30504_30683.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_30684_30743.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_30744_31283.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_31284_31331.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_31332_32315.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_32316_32399.png Will_you_be_my_bf__forever__Analysing_Techniques_f_Fm4zFBIs16Q_32400_34568.png