The bibliotek-o Framework: Principles, Patterns, and a Process for Community Engagement
Folsom, Steven
Kovari, Jason
Younes, Rebecca
This presentation provides a detailed description of ontology development efforts undertaken by Linked Data for Libraries Labs and Linked Data for Production partners to extend BIBFRAME 2.0 and enhance with alternative models, which have yielded the bibliotek-o framework (available: bibliotek-o GitHub Repository and bibliotek-o website). The framework includes the bibliotek-o ontology alongside well-established ontologies, building off BIBFRAME as its core. We are not creating a competitor to BIBFRAME; instead, our intention is to demonstrate select alternative models for consideration by the community and BIBFRAME architects as development continues in future versions of BIBFRAME. We will discuss motivations and focus on bibliotek-o modeling patterns, notably areas of deviation from BIBFRAME; in doing so, we will demonstrate how we believe that these models provide queryable patterns and align with ontology principles and best practices. Further, we will discuss efforts around development of an application profile and MARC-to-bibliotek-o mapping for use in aligned, in-development tooling for metadata production and conversion of legacy data. Our goal is to promote open development of bibliotek-o, including community engagement, feedback, collaboration, testing and adoption. To encourage engagement with the SWIB community, we will provide pointers to the various types of bibliotek-o documentation that are available and outline our strategy to engage with the community. With greater participation from the community we can hopefully begin to converge around a shared set of practices with a clear process for iterative improvements.
 Okay, so my name is Jason Kovari and today Stephen Folsom and I will be talking about Biblioteco, which is in many ways an implementation of BibFrame. So I'm really glad that we went following Nate and Ray. The work today is part of the link data for libraries, labs, and link data for production, and to WMLN Foundation funded projects, which you had an introduction to this morning by Regine, so thank you for saving us that effort. But that really is, but more specifically, this is an effort of the joint ontology group within those two projects. So that is really to say that this work is the effort of significantly more people than Stephen and myself and our co-presenter Rebecca, or co-author Rebecca. And way too many people to name individually, but they represent six institutions, Columbia, Cornell, Harvard, Princeton, Stanford, universities, as well as the Library of Congress. We're going to keep it fairly superficial because we are limited on time, so with that I will move forward. So what is Biblioteco? Biblioteco is a very simple model for representing the bibliographic domain. The core concepts and models are based on BibFrame. Work instance item, you can see in the diagram there. And building upon BibFrame is the Biblioteco ontology itself, which in many ways supplements BibFrame with an extension, as well as in places, replaces patterns in BibFrame in our attempt to demonstrate alternative modeling, which we'll talk about in a moment. On top of that are additional ontologies such as schema, DC terms, fof, et cetera. All of these are available at the Biblioteco.org site. All of these links are in the slides later and you can find them through there. If you want to know exactly which terms we're using from which ontologies. Alongside of the ontologies are Shackle application profiles, which are in development currently, although there are some that are available in GitHub already, that define implementation of the use cases that we are trying to describe or to create data around within the projects, as well as mappings are also available within the GitHub repo, specifically currently the BibCo mark Bibliographic standard record mapping to Biblioteco. So what is the purpose of this? Why did we bother creating yet another core model? This really began as an attempt for the ontology group to engage in assessment of BibFrame 2.0. Conveniently, these two projects began the same month as BibFrame 2.0 came out. When we said, okay, we're going to use BibFrame in these projects, we started by saying we don't actually know what's in BibFrame because we knew BibFrame 1.0 pretty well and now BibFrame 2.0 and we have no idea what they changed and we have to assess. In doing so, that assessment sort of took on a life of its own. It was evaluation and engagement because we believe that as people who are going to use these models, we need to deeply engage with them. And it was also an attempt to look towards extension of BibFrame itself. We went further to deviate from BibFrame and demonstrate these alternative patterns with the goal of trying to identify whether or not there are other ways to go about creating our data that could be more queryable, could be more useful for us. The verdict is out on some of those because we haven't tested yet. But the idea here is that we are not in any way creating a competitor to BibFrame. We are simply demonstrating these alternative patterns so that they can be assessed by the community such as yourselves and also by Library of Congress who are the, obviously, the BibFrame developers to be determined whether or not some of them could be folded into future iterations of BibFrame, future versions of BibFrame. And all of this alongside trying to assess whether or not we can accept our legacy data and bring it into a real-world orientation alongside creating new data. Now future plans for Biblioteco are actually frozen. We are not continuing development of this model and in fact not even all of the six institutions who have created this model are using the model. The goal here, again, really is assessment and evaluation to demonstrate alternatives. We defined rather robust change management process available in the GitHub repo and have a ton of work that we identified but never completed because of time constraints. But we believe that we did succeed in our goal of assessment so we are very proud of that. And we also really want to engage with the community around this. We want issues on GitHub. We want people to say this is great or terrible. Why did you do this? We really like the latter particularly. So there's plenty of places to get documentation, perhaps a few too many, but there are many. There's a wiki for this as well as a GitHub repo. We try to cross-link as much as possible. But between these spaces there is actually plenty of rich documentation so that the community who wishes to either implement or analyze has the tools to do so. There are OWL files, shackle application profiles, mapping spreadsheets, narrative pattern descriptions and diagrams and speaking of pattern descriptions, these are in a way rather at times very lengthy analysis of what exactly is within the pattern itself. These merge modeling and implementation to demonstrate diagrams of how we believe the pattern should be profiled, what exactly should be, what kinds of data should be produced through this. And the patterns that were created where the bib frame patterns are either supplemented or replaced follow a few principles. And in discussing three of these patterns in a minute we'll outline which principles sort of align with which. Those in general being reused and aligned with existing vocabularies and ontologies. And also inversely for anything that we do mentor ourselves doing so broadly enough that we encourage reuse by others. Trying to use OWL axioms in moderation so that we do not over constrain the ontology itself. Preferring object properties and structured data over unstructured literals and not being mired in our legacy data in hopes that one day we will have more future data created natively in these models. And so we're going to focus on three patterns. I'll take the first and then kick it over to Steven. The first being activities. The principles that this aligns with are preferring the simplest and most general model, capable of faithfully representing the data. And the second being using OWL constructs in moderation. So for a just very two second primer within the bib frame model activities in a way are divided between provisions and contributions with provisions being only on the instance level and contributions I thought were only on the work level but apparently they're now work instance or item used with or it says it in the, it says it last time I checked at least. And we feel that this is unnecessary complication in that the two profile the same, the two have the same kind of concept. We saw the semantics as being at least having a super class there that would allow for it. And also on the other hand, bib frame also uses BF role to define the agents interaction with the resource. In Biblioteco there is a single pattern for representing activities whether they be in the bib frame mode provisions or contributions. And that activity uses subclassing as the inherent way of identifying how the agent is related to that activity or that resource. The significant features that we feel that this model changes or at least aligns with are that it's a consistent model across the board for activities on a resource. There is a super class and a shared super class and a shared property for all types of activities. And there aren't any formal constraints about which type of BF core class that something aligns with. So the Bibliographic resource is not specified as being this activity is only related to BF instance for instance. And I think that's all I'm going to say about activities. And with that I'll pass it over to Stephen. Okay. So jumping into the next pattern. Bib frame uses two distinct patterns for capturing content carrier and media type. So if you're familiar at all with RDA these concepts are sort of an embodiment of an implementation of RDA. And so what you see here is you see two types of Rx. You see RDF type and you also see content carrier and media. And so really what you see is surfaces, multiple query paths that you then have to take into account in your applications. And so there's the subclassing of works instance items and then linking also to content carrier and media resources that essentially captures the same if not similar if not the same ideas. So at least in the lifetime of this grant we're proposing that we commit to subclasses. And so this is sort of like what Valentin was saying with their schema.org extensions. So schema has creative work and then the types of resources can be extended through subclassing. And so RDF type everybody knows is a pretty ubiquitous property. Systems know how to use it. It's a fairly safe way to implement and extend in Bib frame. And the other thing to point out here, a couple of things to point out here. An alternative model would be to not ignore these content carrier and media vocabularies that are often SCOS vocabularies. But even with that we don't necessarily need a different property per resource. So CDOC CRM has P2 where you can classify resources and use a single property to say this entity has this type but we're not actually linking to a class. We're linking to a SCOS concept that gets around that sort of punning question. The other thing to point out here is that we haven't extended media type and we're trying to push the boundaries here on instances so that we say we define instances and we extend instances in such a way that in their definition is this idea of what it takes to playback. So the Bib online resource here is a subclass of electronic and electronic in its definition says requires a computer for playback. So having another pattern that says here's a media property and computer off from the resource, we're really striving for some simplicity there. So moving on maybe a harder pattern to describe is the relations document. I'm only going to touch on this in surface. There's a, as Jason said, a document that goes in much more detail. But in this case we decided that, so for some of the properties that Ray was talking about with expression of and related to in the sub properties, they reach a limit. They've held themselves to being a framework and ask that you extend. And so this is sort of an approach to extending sort of the core relationships between principal or primary entities in Bib frames. So an example of this would be the derivative work. So there's a pretty deep hierarchy of derivative works in RDAU and we're suggesting to use that and I'll acknowledge Osmo here and say yes, the opaque URIs are a pain, but we'd rather not mint them ourselves. Some other motivations behind this or another motivation behind this was that we felt that we wouldn't have to train catalogers necessarily. I mean, they're getting a lot of RDA training so hopefully they'll recognize some of these terms and the other is the RDAU properties if you don't know. RDA unconstrained has open domains and ranges. So RDA wants to use the FURBER stack and work expression manifestation and item and this lets us get around that in the way that Bib frame strives to do. So some of our more recent work is trying to understand with the definitions that we or the properties that we've chosen to use, how do we use those in the sort of Bib leotecho environment. So we've identified properties like DC terms description and the domain is open and we want to build these applications that use the properties that we've identified in deliberate ways and the ontologies themselves don't, aren't enough to build an application. We have to specify how are you going to use each of these properties and Huda Khan in the audience has great presentations about ontology to app and I recommend going out and looking at those. And so with Shackle, the shapes constraint recommendation out of W3C, there's lots of ways that it can be used. A lot of people are considering a validation language. We were happy to find axioms in the model that allow for form building. So and really as the Princeton folks pointed out, we got really far behind and bogged down in modeling so we got behind in building an application that would let catalogers catalog and so this is our way to a standard way to define what the cataloging tools would use. Examples of this you can find in the repository, the most mature being the hip hop repository and really this is coming from a very content specific set of decisions. So for audio works, what properties and classes do we want in that form so that you don't have all of the big frame and you don't have all of the other extensions in a big heavy weight editor so really trying to tune it for a content type and moving images coming along and one of our goals is to have it for any project that wants to use Vitrolib which is the editor that we're building to define some shackles so that we can transform the shackle into what the editor needs. And so I'm going to leave this out. I'll just use this slide as a plug for a breakout session because we don't have necessarily the time to go into it but I'm really interested in the semantics of form building and what shackle can do versus what it isn't able to do and but we know that there are certain semantics in form building that we have in JSON configuration files and elsewhere so there's a lot of experience in the room around building forms so I would love to have a conversation about a standard space way of doing that and given the shackles RDF-based we can have URIs and share shapes and share some of these definitions so that across applications we don't have to recreate some form building. So leaving question for, or leaving time for questions, really we do hope that people will engage with our work and either here at the conference or online. As Jason said there's lots of opportunities. Please comment publicly. It's sure we'll have a side conversation but the more that this stuff can be out in the open I think the more useful it is. And if you have your own assessments I know we're not the only groups looking at BIP frame and trying to make these sort of evaluations. We'd love to hear from you. And lastly though BIP.ly.lo.techo isn't going to progress as something that we maintain into the future we're really interested both with our engagement with BIP frame and other ontologies. Your experience about building community-based open process for communicating and maintaining ontologies. So thank you. So thank you. Thank you for your presentation. Do we have any questions or comments from the audience? We have time. Come on. Okay there's one. Hi my name is Kristina. I'm from the Danish Library Center. I was just wondering actually what your motivation behind this was was it like you saw some data that wasn't really well represented in BIP frame or was it you mentioned something in the beginning about making it more searchable or was it what was your motivation for this? Was it presenting it in a user interface then this doesn't make sense in BIP frame? What were your thoughts about this? I think it would depend on the pattern itself or the fragment that we were concerned with. I can't offhand think of an individual instance where it was like this was about querying and this was about display or something like that. But overall it was a sense that as we were going because our assessment was going class by class property by property through it's easy to especially when you have 20 people in the room sort of suddenly say oh we really wish it was doing this instead of that and we really wanted it to be simpler in this one area or more complex in this other or whatever the case might be. And it took a life of its own prior to us really having a mode of operation in that way. We weren't necessarily, we wasn't thought of as being a massive undertaking a whole framework before when we began the project. It was really just let's document some questions that we have and some issues we have. Okay, thank you once more.
 Okay, so my name is Jason Kovari and today Stephen Folsom and I will be talking about  Biblioteco, which is in many ways an implementation of BibFrame.  So I'm really glad that we went following Nate and Ray.  The work today is part of the link data for libraries, labs, and link data for production,  and to WMLN Foundation funded projects, which you had an introduction to this morning by  Regine, so thank you for saving us that effort.  But that really is, but more specifically, this is an effort of the joint ontology group  within those two projects.  So that is really to say that this work is the effort of significantly more people than  Stephen and myself and our co-presenter Rebecca, or co-author Rebecca.  And way too many people to name individually, but they represent six institutions, Columbia,  Cornell, Harvard, Princeton, Stanford, universities, as well as the Library of Congress.  We're going to keep it fairly superficial because we are limited on time, so with that  I will move forward.  So what is Biblioteco?  Biblioteco is a very simple model for representing the bibliographic domain.  The core concepts and models are based on BibFrame.  Work instance item, you can see in the diagram there.  And building upon BibFrame is the Biblioteco ontology itself, which in many ways supplements  BibFrame with an extension, as well as in places, replaces patterns in BibFrame in our  attempt to demonstrate alternative modeling, which we'll talk about in a moment.  On top of that are additional ontologies such as schema, DC terms, fof, et cetera.  All of these are available at the Biblioteco.org site.  All of these links are in the slides later and you can find them through there.  If you want to know exactly which terms we're using from which ontologies.  Alongside of the ontologies are Shackle application profiles, which are in development currently,  although there are some that are available in GitHub already, that define implementation  of the use cases that we are trying to describe or to create data around within the projects,  as well as mappings are also available within the GitHub repo, specifically currently the  BibCo mark Bibliographic standard record mapping to Biblioteco.  So what is the purpose of this?  Why did we bother creating yet another core model?  This really began as an attempt for the ontology group to engage in assessment of BibFrame  2.0.  Conveniently, these two projects began the same month as BibFrame 2.0 came out.  When we said, okay, we're going to use BibFrame in these projects, we started by saying we  don't actually know what's in BibFrame because we knew BibFrame 1.0 pretty well and now BibFrame  2.0 and we have no idea what they changed and we have to assess.  In doing so, that assessment sort of took on a life of its own.  It was evaluation and engagement because we believe that as people who are going to use  these models, we need to deeply engage with them.  And it was also an attempt to look towards extension of BibFrame itself.  We went further to deviate from BibFrame and demonstrate these alternative patterns with  the goal of trying to identify whether or not there are other ways to go about creating  our data that could be more queryable, could be more useful for us.  The verdict is out on some of those because we haven't tested yet.  But the idea here is that we are not in any way creating a competitor to BibFrame.  We are simply demonstrating these alternative patterns so that they can be assessed by the  community such as yourselves and also by Library of Congress who are the, obviously, the BibFrame  developers to be determined whether or not some of them could be folded into future iterations  of BibFrame, future versions of BibFrame.  And all of this alongside trying to assess whether or not we can accept our legacy data  and bring it into a real-world orientation alongside creating new data.  Now future plans for Biblioteco are actually frozen.  We are not continuing development of this model and in fact not even all of the six institutions  who have created this model are using the model.  The goal here, again, really is assessment and evaluation to demonstrate alternatives.  We defined rather robust change management process available in the GitHub repo and have  a ton of work that we identified but never completed because of time constraints.  But we believe that we did succeed in our goal of assessment so we are very proud of  that.  And we also really want to engage with the community around this.  We want issues on GitHub.  We want people to say this is great or terrible.  Why did you do this?  We really like the latter particularly.  So there's plenty of places to get documentation, perhaps a few too many, but there are many.  There's a wiki for this as well as a GitHub repo.  We try to cross-link as much as possible.  But between these spaces there is actually plenty of rich documentation so that the  community who wishes to either implement or analyze has the tools to do so.  There are OWL files, shackle application profiles, mapping spreadsheets, narrative pattern descriptions  and diagrams and speaking of pattern descriptions, these are in a way rather at times very lengthy  analysis of what exactly is within the pattern itself.  These merge modeling and implementation to demonstrate diagrams of how we believe the  pattern should be profiled, what exactly should be, what kinds of data should be produced  through this.  And the patterns that were created where the bib frame patterns are either supplemented  or replaced follow a few principles.  And in discussing three of these patterns in a minute we'll outline which principles  sort of align with which.  Those in general being reused and aligned with existing vocabularies and ontologies.  And also inversely for anything that we do mentor ourselves doing so broadly enough that  we encourage reuse by others.  Trying to use OWL axioms in moderation so that we do not over constrain the ontology  itself.  Preferring object properties and structured data over unstructured literals and not being  mired in our legacy data in hopes that one day we will have more future data created  natively in these models.  And so we're going to focus on three patterns.  I'll take the first and then kick it over to Steven.  The first being activities.  The principles that this aligns with are preferring the simplest and most general model,  capable of faithfully representing the data.  And the second being using OWL constructs in moderation.  So for a just very two second primer within the bib frame model activities in a way are  divided between provisions and contributions with provisions being only on the instance  level and contributions I thought were only on the work level but apparently they're now  work instance or item used with or it says it in the, it says it last time I checked at  least.  And we feel that this is unnecessary complication in that the two profile the same, the two  have the same kind of concept.  We saw the semantics as being at least having a super class there that would allow for it.  And also on the other hand, bib frame also uses BF role to define the agents interaction  with the resource.  In Biblioteco there is a single pattern for representing activities whether they be in  the bib frame mode provisions or contributions.  And that activity uses subclassing as the inherent way of identifying how the agent is  related to that activity or that resource.  The significant features that we feel that this model changes or at least aligns with  are that it's a consistent model across the board for activities on a resource.  There is a super class and a shared super class and a shared property for all types  of activities.  And there aren't any formal constraints about which type of BF core class that something  aligns with.  So the Bibliographic resource is not specified as being this activity is only related to  BF instance for instance.  And I think that's all I'm going to say about activities.  And with that I'll pass it over to Stephen.  Okay.  So jumping into the next pattern.  Bib frame uses two distinct patterns for capturing content carrier and media type.  So if you're familiar at all with RDA these concepts are sort of an embodiment of an  implementation of RDA.  And so what you see here is you see two types of Rx.  You see RDF type and you also see content carrier and media.  And so really what you see is surfaces, multiple query paths that you then have to take into  account in your applications.  And so there's the subclassing of works instance items and then linking also to content carrier  and media resources that essentially captures the same if not similar if not the same ideas.  So at least in the lifetime of this grant we're proposing that we commit to subclasses.  And so this is sort of like what Valentin was saying with their schema.org extensions.  So schema has creative work and then the types of resources can be extended through subclassing.  And so RDF type everybody knows is a pretty ubiquitous property.  Systems know how to use it.  It's a fairly safe way to implement and extend in Bib frame.  And the other thing to point out here, a couple of things to point out here.  An alternative model would be to not ignore these content carrier and media vocabularies  that are often SCOS vocabularies.  But even with that we don't necessarily need a different property per resource.  So CDOC CRM has P2 where you can classify resources and use a single property to say this entity  has this type but we're not actually linking to a class.  We're linking to a SCOS concept that gets around that sort of punning question.  The other thing to point out here is that we haven't extended media type and we're trying  to push the boundaries here on instances so that we say we define instances and we extend  instances in such a way that in their definition is this idea of what it takes to playback.  So the Bib online resource here is a subclass of electronic and electronic in its definition  says requires a computer for playback.  So having another pattern that says here's a media property and computer off from the  resource, we're really striving for some simplicity there.  So moving on maybe a harder pattern to describe is the relations document.  I'm only going to touch on this in surface.  There's a, as Jason said, a document that goes in much more detail.  But in this case we decided that, so for some of the properties that Ray was talking about  with expression of and related to in the sub properties, they reach a limit.  They've held themselves to being a framework and ask that you extend.  And so this is sort of an approach to extending sort of the core relationships between principal  or primary entities in Bib frames.  So an example of this would be the derivative work.  So there's a pretty deep hierarchy of derivative works in RDAU and we're suggesting to use  that and I'll acknowledge Osmo here and say yes, the opaque URIs are a pain, but we'd  rather not mint them ourselves.  Some other motivations behind this or another motivation behind this was that we felt that  we wouldn't have to train catalogers necessarily.  I mean, they're getting a lot of RDA training so hopefully they'll recognize some of these  terms and the other is the RDAU properties if you don't know.  RDA unconstrained has open domains and ranges.  So RDA wants to use the FURBER stack and work expression manifestation and item and this  lets us get around that in the way that Bib frame strives to do.  So some of our more recent work is trying to understand with the definitions that we  or the properties that we've chosen to use, how do we use those in the sort of Bib leotecho  environment.  So we've identified properties like DC terms description and the domain is open and we  want to build these applications that use the properties that we've identified in deliberate  ways and the ontologies themselves don't, aren't enough to build an application.  We have to specify how are you going to use each of these properties and Huda Khan in  the audience has great presentations about ontology to app and I recommend going out  and looking at those.  And so with Shackle, the shapes constraint recommendation out of W3C, there's lots of  ways that it can be used.  A lot of people are considering a validation language.  We were happy to find axioms in the model that allow for form building.  So and really as the Princeton folks pointed out, we got really far behind and bogged down  in modeling so we got behind in building an application that would let catalogers catalog  and so this is our way to a standard way to define what the cataloging tools would use.  Examples of this you can find in the repository, the most mature being the hip hop repository  and really this is coming from a very content specific set of decisions.  So for audio works, what properties and classes do we want in that form so that you don't have  all of the big frame and you don't have all of the other extensions in a big heavy weight  editor so really trying to tune it for a content type and moving images coming along and one  of our goals is to have it for any project that wants to use Vitrolib which is the editor  that we're building to define some shackles so that we can transform the shackle into  what the editor needs.  And so I'm going to leave this out.  I'll just use this slide as a plug for a breakout session because we don't have necessarily  the time to go into it but I'm really interested in the semantics of form building and what  shackle can do versus what it isn't able to do and but we know that there are certain  semantics in form building that we have in JSON configuration files and elsewhere so  there's a lot of experience in the room around building forms so I would love to have a conversation  about a standard space way of doing that and given the shackles RDF-based we can have URIs  and share shapes and share some of these definitions so that across applications we don't have  to recreate some form building.  So leaving question for, or leaving time for questions, really we do hope that people will  engage with our work and either here at the conference or online.  As Jason said there's lots of opportunities.  Please comment publicly.  It's sure we'll have a side conversation but the more that this stuff can be out in the  open I think the more useful it is.  And if you have your own assessments I know we're not the only groups looking at BIP frame  and trying to make these sort of evaluations.  We'd love to hear from you.  And lastly though BIP.ly.lo.techo isn't going to progress as something that we maintain  into the future we're really interested both with our engagement with BIP frame and other  ontologies.  Your experience about building community-based open process for communicating and maintaining  ontologies.  So thank you.  So thank you.  Thank you for your presentation.  Do we have any questions or comments from the audience?  We have time.  Come on.  Okay there's one.  Hi my name is Kristina.  I'm from the Danish Library Center.  I was just wondering actually what your motivation behind this was was it like you saw some data  that wasn't really well represented in BIP frame or was it you mentioned something in  the beginning about making it more searchable or was it what was your motivation for this?  Was it presenting it in a user interface then this doesn't make sense in BIP frame?  What were your thoughts about this?  I think it would depend on the pattern itself or the fragment that we were concerned with.  I can't offhand think of an individual instance where it was like this was about querying  and this was about display or something like that.  But overall it was a sense that as we were going because our assessment was going class  by class property by property through it's easy to especially when you have 20 people  in the room sort of suddenly say oh we really wish it was doing this instead of that and  we really wanted it to be simpler in this one area or more complex in this other or  whatever the case might be.  And it took a life of its own prior to us really having a mode of operation in that  way.  We weren't necessarily, we wasn't thought of as being a massive undertaking a whole  framework before when we began the project.  It was really just let's document some questions that we have and some issues we have.  Okay, thank you once more.
The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_0_71.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_72_155.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_156_515.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_516_1079.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_1080_1151.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_1152_3587.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_3588_4211.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_4212_7727.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_7728_10775.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_10776_11387.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_11388_15395.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_15396_18947.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_18948_19079.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_19080_19931.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_19932_20507.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_20508_21203.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_21204_21491.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_21492_28715.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_28716_28763.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_28764_28919.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_28920_29315.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_29316_29579.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_29580_29711.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_29712_29807.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_29808_30371.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_30372_30503.png The_bibliotek-o_Framework__Principles__Patterns__a_i17bxMbY-UM_30504_30652.png
Okay, so my name is Jason Kovari and today Stephen Folsom and I will be talking about Biblioteco, which is in many ways an implementation of BibFrame. So I'm really glad that we went following Nate and Ray. The work today is part of the link data for libraries, labs, and link data for production, and to WMLN Foundation funded projects, which you had an introduction to this morning by Regine, so thank you for saving us that effort. But that really is, but more specifically, this is an effort of the joint ontology group within those two projects. So that is really to say that this work is the effort of significantly more people than Stephen and myself and our co-presenter Rebecca, or co-author Rebecca. And way too many people to name individually, but they represent six institutions, Columbia, Cornell, Harvard, Princeton, Stanford, universities, as well as the Library of Congress. We're going to keep it fairly superficial because we are limited on time, so with that I will move forward. So what is Biblioteco? Biblioteco is a very simple model for representing the bibliographic domain. The core concepts and models are based on BibFrame. Work instance item, you can see in the diagram there. And building upon BibFrame is the Biblioteco ontology itself, which in many ways supplements BibFrame with an extension, as well as in places, replaces patterns in BibFrame in our attempt to demonstrate alternative modeling, which we'll talk about in a moment. On top of that are additional ontologies such as schema, DC terms, fof, et cetera. All of these are available at the Biblioteco.org site. All of these links are in the slides later and you can find them through there. If you want to know exactly which terms we're using from which ontologies. Alongside of the ontologies are Shackle application profiles, which are in development currently, although there are some that are available in GitHub already, that define implementation of the use cases that we are trying to describe or to create data around within the projects, as well as mappings are also available within the GitHub repo, specifically currently the BibCo mark Bibliographic standard record mapping to Biblioteco. So what is the purpose of this? Why did we bother creating yet another core model? This really began as an attempt for the ontology group to engage in assessment of BibFrame 2.0. Conveniently, these two projects began the same month as BibFrame 2.0 came out. When we said, okay, we're going to use BibFrame in these projects, we started by saying we don't actually know what's in BibFrame because we knew BibFrame 1.0 pretty well and now BibFrame 2.0 and we have no idea what they changed and we have to assess. In doing so, that assessment sort of took on a life of its own. It was evaluation and engagement because we believe that as people who are going to use these models, we need to deeply engage with them. And it was also an attempt to look towards extension of BibFrame itself. We went further to deviate from BibFrame and demonstrate these alternative patterns with the goal of trying to identify whether or not there are other ways to go about creating our data that could be more queryable, could be more useful for us. The verdict is out on some of those because we haven't tested yet. But the idea here is that we are not in any way creating a competitor to BibFrame. We are simply demonstrating these alternative patterns so that they can be assessed by the community such as yourselves and also by Library of Congress who are the, obviously, the BibFrame developers to be determined whether or not some of them could be folded into future iterations of BibFrame, future versions of BibFrame. And all of this alongside trying to assess whether or not we can accept our legacy data and bring it into a real-world orientation alongside creating new data. Now future plans for Biblioteco are actually frozen. We are not continuing development of this model and in fact not even all of the six institutions who have created this model are using the model. The goal here, again, really is assessment and evaluation to demonstrate alternatives. We defined rather robust change management process available in the GitHub repo and have a ton of work that we identified but never completed because of time constraints. But we believe that we did succeed in our goal of assessment so we are very proud of that. And we also really want to engage with the community around this. We want issues on GitHub. We want people to say this is great or terrible. Why did you do this? We really like the latter particularly. So there's plenty of places to get documentation, perhaps a few too many, but there are many. There's a wiki for this as well as a GitHub repo. We try to cross-link as much as possible. But between these spaces there is actually plenty of rich documentation so that the community who wishes to either implement or analyze has the tools to do so. There are OWL files, shackle application profiles, mapping spreadsheets, narrative pattern descriptions and diagrams and speaking of pattern descriptions, these are in a way rather at times very lengthy analysis of what exactly is within the pattern itself. These merge modeling and implementation to demonstrate diagrams of how we believe the pattern should be profiled, what exactly should be, what kinds of data should be produced through this. And the patterns that were created where the bib frame patterns are either supplemented or replaced follow a few principles. And in discussing three of these patterns in a minute we'll outline which principles sort of align with which. Those in general being reused and aligned with existing vocabularies and ontologies. And also inversely for anything that we do mentor ourselves doing so broadly enough that we encourage reuse by others. Trying to use OWL axioms in moderation so that we do not over constrain the ontology itself. Preferring object properties and structured data over unstructured literals and not being mired in our legacy data in hopes that one day we will have more future data created natively in these models. And so we're going to focus on three patterns. I'll take the first and then kick it over to Steven. The first being activities. The principles that this aligns with are preferring the simplest and most general model, capable of faithfully representing the data. And the second being using OWL constructs in moderation. So for a just very two second primer within the bib frame model activities in a way are divided between provisions and contributions with provisions being only on the instance level and contributions I thought were only on the work level but apparently they're now work instance or item used with or it says it in the, it says it last time I checked at least. And we feel that this is unnecessary complication in that the two profile the same, the two have the same kind of concept. We saw the semantics as being at least having a super class there that would allow for it. And also on the other hand, bib frame also uses BF role to define the agents interaction with the resource. In Biblioteco there is a single pattern for representing activities whether they be in the bib frame mode provisions or contributions. And that activity uses subclassing as the inherent way of identifying how the agent is related to that activity or that resource. The significant features that we feel that this model changes or at least aligns with are that it's a consistent model across the board for activities on a resource. There is a super class and a shared super class and a shared property for all types of activities. And there aren't any formal constraints about which type of BF core class that something aligns with. So the Bibliographic resource is not specified as being this activity is only related to BF instance for instance. And I think that's all I'm going to say about activities. And with that I'll pass it over to Stephen. Okay. So jumping into the next pattern. Bib frame uses two distinct patterns for capturing content carrier and media type. So if you're familiar at all with RDA these concepts are sort of an embodiment of an implementation of RDA. And so what you see here is you see two types of Rx. You see RDF type and you also see content carrier and media. And so really what you see is surfaces, multiple query paths that you then have to take into account in your applications. And so there's the subclassing of works instance items and then linking also to content carrier and media resources that essentially captures the same if not similar if not the same ideas. So at least in the lifetime of this grant we're proposing that we commit to subclasses. And so this is sort of like what Valentin was saying with their schema.org extensions. So schema has creative work and then the types of resources can be extended through subclassing. And so RDF type everybody knows is a pretty ubiquitous property. Systems know how to use it. It's a fairly safe way to implement and extend in Bib frame. And the other thing to point out here, a couple of things to point out here. An alternative model would be to not ignore these content carrier and media vocabularies that are often SCOS vocabularies. But even with that we don't necessarily need a different property per resource. So CDOC CRM has P2 where you can classify resources and use a single property to say this entity has this type but we're not actually linking to a class. We're linking to a SCOS concept that gets around that sort of punning question. The other thing to point out here is that we haven't extended media type and we're trying to push the boundaries here on instances so that we say we define instances and we extend instances in such a way that in their definition is this idea of what it takes to playback. So the Bib online resource here is a subclass of electronic and electronic in its definition says requires a computer for playback. So having another pattern that says here's a media property and computer off from the resource, we're really striving for some simplicity there. So moving on maybe a harder pattern to describe is the relations document. I'm only going to touch on this in surface. There's a, as Jason said, a document that goes in much more detail. But in this case we decided that, so for some of the properties that Ray was talking about with expression of and related to in the sub properties, they reach a limit. They've held themselves to being a framework and ask that you extend. And so this is sort of an approach to extending sort of the core relationships between principal or primary entities in Bib frames. So an example of this would be the derivative work. So there's a pretty deep hierarchy of derivative works in RDAU and we're suggesting to use that and I'll acknowledge Osmo here and say yes, the opaque URIs are a pain, but we'd rather not mint them ourselves. Some other motivations behind this or another motivation behind this was that we felt that we wouldn't have to train catalogers necessarily. I mean, they're getting a lot of RDA training so hopefully they'll recognize some of these terms and the other is the RDAU properties if you don't know. RDA unconstrained has open domains and ranges. So RDA wants to use the FURBER stack and work expression manifestation and item and this lets us get around that in the way that Bib frame strives to do. So some of our more recent work is trying to understand with the definitions that we or the properties that we've chosen to use, how do we use those in the sort of Bib leotecho environment. So we've identified properties like DC terms description and the domain is open and we want to build these applications that use the properties that we've identified in deliberate ways and the ontologies themselves don't, aren't enough to build an application. We have to specify how are you going to use each of these properties and Huda Khan in the audience has great presentations about ontology to app and I recommend going out and looking at those. And so with Shackle, the shapes constraint recommendation out of W3C, there's lots of ways that it can be used. A lot of people are considering a validation language. We were happy to find axioms in the model that allow for form building. So and really as the Princeton folks pointed out, we got really far behind and bogged down in modeling so we got behind in building an application that would let catalogers catalog and so this is our way to a standard way to define what the cataloging tools would use. Examples of this you can find in the repository, the most mature being the hip hop repository and really this is coming from a very content specific set of decisions. So for audio works, what properties and classes do we want in that form so that you don't have all of the big frame and you don't have all of the other extensions in a big heavy weight editor so really trying to tune it for a content type and moving images coming along and one of our goals is to have it for any project that wants to use Vitrolib which is the editor that we're building to define some shackles so that we can transform the shackle into what the editor needs. And so I'm going to leave this out. I'll just use this slide as a plug for a breakout session because we don't have necessarily the time to go into it but I'm really interested in the semantics of form building and what shackle can do versus what it isn't able to do and but we know that there are certain semantics in form building that we have in JSON configuration files and elsewhere so there's a lot of experience in the room around building forms so I would love to have a conversation about a standard space way of doing that and given the shackles RDF-based we can have URIs and share shapes and share some of these definitions so that across applications we don't have to recreate some form building. So leaving question for, or leaving time for questions, really we do hope that people will engage with our work and either here at the conference or online. As Jason said there's lots of opportunities. Please comment publicly. It's sure we'll have a side conversation but the more that this stuff can be out in the open I think the more useful it is. And if you have your own assessments I know we're not the only groups looking at BIP frame and trying to make these sort of evaluations. We'd love to hear from you. And lastly though BIP.ly.lo.techo isn't going to progress as something that we maintain into the future we're really interested both with our engagement with BIP frame and other ontologies. Your experience about building community-based open process for communicating and maintaining ontologies. So thank you. So thank you. Thank you for your presentation. Do we have any questions or comments from the audience? We have time. Come on. Okay there's one. Hi my name is Kristina. I'm from the Danish Library Center. I was just wondering actually what your motivation behind this was was it like you saw some data that wasn't really well represented in BIP frame or was it you mentioned something in the beginning about making it more searchable or was it what was your motivation for this? Was it presenting it in a user interface then this doesn't make sense in BIP frame? What were your thoughts about this? I think it would depend on the pattern itself or the fragment that we were concerned with. I can't offhand think of an individual instance where it was like this was about querying and this was about display or something like that. But overall it was a sense that as we were going because our assessment was going class by class property by property through it's easy to especially when you have 20 people in the room sort of suddenly say oh we really wish it was doing this instead of that and we really wanted it to be simpler in this one area or more complex in this other or whatever the case might be. And it took a life of its own prior to us really having a mode of operation in that way. We weren't necessarily, we wasn't thought of as being a massive undertaking a whole framework before when we began the project. It was really just let's document some questions that we have and some issues we have. Okay, thank you once more.
labs, and link data for production, and to WMLN our attempt to demonstrate alternative modeling, application profiles, which are in development available in GitHub already, that define another core model? This really began as an attempt for the ontology group to engage in assessment of BibFrame 2.0. Conveniently, these who are going to use these models, we need to data that could be more queryable, could be more here is that we are not in any way creating a competitor to BibFrame. We are simply they can be assessed by the community such as versions of BibFrame. And all of this alongside We are not continuing development of this model The goal here, again, really is assessment and to engage with the community around this. We want files, shackle application profiles, mapping to demonstrate diagrams of how we believe the we'll outline which principles sort of align with literals and not being mired in our legacy data in hopes that one day we will have more future we're going to focus on three patterns. I'll take class and a shared super class and a shared property for all types of activities. And there media property and computer off from the ask that you extend. And so this is sort of an down in modeling so we got behind in building an engagement with BIP frame and other ontologies. open process for communicating and maintaining doing this instead of that and we really wanted