Describing Theses and Dissertations Using Schema.org

Editor's Notes

• #2: My name is Jeff Mixter and I work as a Research Support Specialist at OCLC. My colleagues on this IMLS grant funded project are Kenning Arlitsch, Dean of Montana State University Libraries, and Patrick Obrien, Semantic Web Researcher at Montana State University Library. Kenning and Patrick are not able to attend the conference but we would all like to thank DCMI for inviting me to present today.
• #3: To start out I would like to provide a bit of background information about the project. As mentioned this project is part of an IMLS funded grant project entitled “Getting Found” that Kenning and Patrick were awarded in 2010. The initial scope of the project was to help improve the indexing and visibility of digital collections in search engines. Since the release of Schema.org in 2011, the project has expanded to include modeling Institutional Repository materials, specifically Theses and Dissertations, using terms that are understood and consumed by the major search engines. 
• #4: I am sure that everyone here is aware of what Schema.org is but just to give the 10,000 foot view of  the vocabulary, here are a few important facts. Of particular importance to the library community is the W3C SchemaBibExtend working group that works to propose extension terms to Schema.org in order to allow for better description of bibliographic materials. 
• #5: The data sample that we used for this project was taken from the Montana State University ScholarWorks database. It included 1,909 student theses and dissertations records cataloged using qualified Dublin Core. It should be noted that the metadata underwent rigorous clean-up prior to this study. This will be important when I talk about the process model that we used for converting the data into RDF.
• #6: The initial phase of the work involved developing a data model for the sample set. We chose to use Schema.org as the primary vocabulary for the project. In order to describe in adequate detail the theses and dissertations, we needed to develop a set of extension terms that could be used to further refine the terms already in Schema.org. This set of terms was published using the same conventions as the Schema.org vocabulary. Primarily it was published as an RDFS vocabulary. 
• #7: This is a general conception of the model that we developed for the theses and dissertations.
• #8: As we were developing the set of extension classes, they were grouped into two general categories. The first was those that were created to add more specificity to the existing CreativeWork branch Schema.org terms. For example, we wanted to describe an item as being not only a schema:Creative Work but more specifically a Thesis. The second category of classes were those that in essence did not exist within the Schema.org vocabulary. The Institutional Repository class was one such example. Although there are schema:Organization and schema:LocalBusiness classes (although some people might argue that an IR is not a 'business' per  se), we felt that that the IR class was unique enough to warrant its inclusion in this category. That being said, we still positioned the IR class as a sub-class of schema:Organization. Also one should not read too much into the two categories, we simply used them as a means to help organize the modeling process and to help influence ideas for future work (which I will talk about briefly) 
• #9: The development of the extension properties were also grouped into two general categories, those that added more granularity to existing schema.org properties and those that were needed (and did not already exist) to adequately describe Theses and Dissertations. So here I have listed mont:committeeMember. This property is listed as a sub-property of the schema:member property. In addition to this committee member relationship we also coined a mont:committeeChair property. So in the end, both properties are directly related to the generic schema:member property but each carries with it unique context and meaning that is important when describing theses and dissertations. As stated on the slides the mont:firstPage property was created to help account/model for all of the existing properties in the original DC metadata. It should be noted that since the model was developed, Schema.org has updated its vocabulary to include firstPage, lastPage properties along with other terms that allow for better descriptions of periodicals. 
• #10: We found after some of the initial modeling work that we were able to infer a lot of information that would otherwise require human reading and interpretation. The example here illustrates a few of these inferences. This type of information could be of huge potential to universities as a means to better understand the academic output and impact of their faculty staff and students. More specifically this could help university libraries better cement their role as the 'centers for university information and knowledge management'. I should say that while I present this idea as novel, it is, in essence, just developing a graph for university data. Its novelty lies in leveraging the library and library data to do so. 
• #11: So I have gone on a bit now about the data model, the other major part of this project was developing a process model for creating and publishing the RDF. We began by loading the data in OpenRefine and used its features to reconcile the existing strings to entities in VIAF, LCSH and Dbpedia. Some stats are on the screen so I will not go over them. If there are specific questions about the reconciliation process or results, please feel free to ask me afterwards. This process has been well documented by Ruben Verborgh and Max De Wilde in their book “Using OpenRefine”. This process has also been used in various library projects to convert flat data into RDF. After the reconciliation process, we took all of the remaining 'strings' and created  our own entities from them. This was particularly important for student and faculty names, and university departments, since there are very few repositories that have this type of data in them. With the rise in importance of services such as ISNI and ORCID, is makes a lot of sense for libraries to being to better understand and deal with the unique person entities that exist in their metadata. One could imagine theses entities becoming the type of data that a university library could aggregate and then submit to ISNI or ORCID for bulk upload. It is important to note that we also used OpenRefine to help identify and merge people that had variations in the spelling of their name. Again, this is a topic that I would love to talk about after the presentation if people are interested. 
• #12: So the final step in the process was syndicating that data. As part of our initial study, we published three sample records as Concise Bounded Descriptions (or CBD) within html pages using RDFa. These were added to the ScholarWorks website. We then published descriptions for all of the referenced entities (that were not reconciled) on an HTML page using RDFa, differentiating each descriptions using hash URIs. Since then we have loaded CDB for all 1,909 sample records back into the Dspace database and are now delivering them using JSON-ld on the HTML pages. All of the newly created entity descriptions are stored in a triple store (Apache Fuseki) that is hosted on an Amazon Web Service (AWS) Elastic Compute Cloud (EC2) instance. We have set up a front end for display of the data in the triple store using Pubby, a simple Linked Data front end for SPARQL endpoints. 
• #13: This slide shows the amount of structured data that Google Webmaster tools is now harvesting from the Montana State University ScholarWorks website. Note this does not serve as evidence of improved SEO but rather illustrates the initial transition from, what Eric Miller described as, the invisible web to the visible web.
• #14: The immediate next steps that we will be working on will be to set up a more 'production-ized' triple store and Pubby interface. This primarily means positioning the services at standard port 80 locations and then making the necessary URI pattern changes in the sample data. We also plan to make some tweaks to the structured data that is being delivered to the Dspace html pages in order to improve how it is consumed and indexed by search engines. We might even abandon JSON-ld in favor of RDFa in order to allow users to 'interact' with the structured data (click on and follow links to external entities). The major next step that we plan to undertake as part of a follow-up grant that we were just awarded from IMLS will be to make libraries more visible on the web. This includes building the presence of libraries and library related organizations on the semantic web. An article recently published by my colleagues at Montana State in the Journal of Library Administration outlines the importance of this work and presents a sample that was done at Montana State University. In addition to making libraries present in the semantic web, this work will also help up in future projects that attempt to convert existing metadata into RDF by creating entity datasets that can be used for reconciliation.
• #15: Again, on behalf of everyone on our team, I would like to thank DCMI for the invitation to speak today and invite folks to ask any questions you might have.