Design and usability testing

• We experimented with a few different designs for incorporating Wikidata information into the catalog prototype.  Our initial design included an info button next to the title.  We realized that having a button for more information about the work that is already represented in the catalog page was potentially confusing.  We then integrated the information directly into the page.  For the final prototype, we added the Wikidata fields to the bottom of the page, but future work could review where the fields should be placed on the page.  
• For pages where the main title had included works, we used the work info buttons to show more information about the included works and also to lead the user to the author title browse page corresponding to that work.  We used a similar layout for the knowledge panel and for the author title browse page as currently exists for the author knowledge panel and author or subject browse pages in production.
• Usability testing revealed that, in general, users were able to understand and  use the work info buttons listed next to the included works on the page.  Clicking on these buttons display knowledge panels for included works and allow navigating to author title browse pages.  When integrating information from Wikidata directly into the page, we should update the wording of the Wikidata acknowledgment (e.g. changing the asterisk explanation from "some of the information on this page comes from Wikidata" to "this information comes from Wikidata") and/or consider how design options for displaying the Wikidata acknowledgment interact with the Discogs acknowledgment on a catalog item page. For the Wikidata properties we integrated into the catalog prototype, users found thematic catalog numbers, such as Kochel codes, to be useful.  These catalog numbers help distinguish between musical resources.  It may be useful to include both titles in other languages for the same musical resource and catalog numbers nearer the main title of the resource.  Additional research could shed light on where best to place this information from Wikidata as well as which properties are most relevant for different groups of users.

Development and technology lessons

• As we have done in earlier experiments and in our linked data production work, we use the string headings associated with a catalog record to look up URIs using the id.loc.gov lookup service (as seen on this line).  The process of looking up related works would be easier if we could employ URIs for the author title headings we are already including in our pages, either to refer to the item itself or to refer to works included in that catalog item.
• For a page that has included works, the code retrieves the author title facet values for the corresponding Solr record and then locates the included work headings that correspond to the author title facet values we wish to look up in the author title browse index.  These initial set of queries against the catalog author title browse index are specified using a set of promises (i.e. ajax requests).  For the headings that are confirmed as authorized, we include a button for the work knowledge panel.  The process of searching the HTML for the included work section headings and then mapping to the authorized author title facet values we have could probably be streamlined by specifying the heading text or URIs within the included works section. 
• The work knowledge panel brings in information from the author title browse index and also kicks off an AJAX request to retrieve the LOC URI corresponding to the heading for the knowledge panel and then the corresponding Wikidata entity and related information.
• If Huda doesn't update the code again, there are a few console output messages that should be removed.

Data lessons

• During our initial development phase, we considered which metadata fields for a musical recording or score could provide us information that could help us find related Library of Congress headings and then related Wikidata entities.  Although we had reviewed uniform titles earlier, these fields didn't necessarily exist in the musical recording or score examples we used as our initial set of examples.  The "authortitle_facet" fields contained values that could map to the author title browse headings in the catalog author title browse index.  We retrieved this field from the Solr record for an item, reformatted the field to remove the "|" separator between the author and title portions of the heading, and used this string to do a lookup against the author titles in id.loc.gov.  We used the URI that was returned from id.loc.gov to query Wikidata to find the matching entity. 
• We used the "included_work_display" field to retrieve the author title headings for included works.  These headings are formatted slightly different than the authortitle_facet headings, and given the differences in punctuation between the included work headings and the Library of Congress headings, we use this field to determine if an item has included works but use the author title facet values to look up the headings themselves. 
• The information for Wikidata catalog numbers is captured using qualifiers on the statement node.  We had to use a query that used the p, ps, and pq prefixes to get the code statement and qualifying code values as shown here: https://github.com/LD4P/blacklight-cornell/blob/bamwowdemo/app/assets/javascripts/bamwow/work.js#L554 .