Friday, February 21. 2014
Over at the Metadata Matters blog, Diane Hillman wrote Why Are We Waiting for the ILS to Change?, asking (in the context of the difficulties libraries experience in making their systems work with RDA):
What I saw underlying that conversation was the assumption that the only way change could happen was if the ILS’s themselves changed; in other words if the ILS vendors decided to lead rather than follow. The situation now is that system vendors say they’ll build RDA compliant systems when their customers ask for them, and libraries say that they’ll use ‘real’ RDA when there are systems that can support it. This is a dance of death, and nobody wins.
I took this as a jumping-off point to discuss the state of linked data support in library systems and discovery software and posted the following comment (currently awaiting moderation):
Who's waiting? Sweden's LIBRIS took essentially the approach you suggested back in 2007, and Bibliothèque Nationale de France and Deutsche Nationalbibliothek have also followed similar paths.
Jumping from RDA to linked data might be a bit of a stretch, but the lack of movement by proprietary vendors in particular hit a sore point that I developed during some of our early W3 Schema.org Bibliographic Extension Community Group discussions. I had asked if anyone else was trying to actually implement what we were discussing. A response from one of the proprietary software representatives was "No, we're waiting to see what develops..." -- which is exactly the attitude that leads to the "dance of death" that Diane described. It can also lead to decisions that are suboptimal, ambiguous, or unimplementable because nobody actually tried to put theory into practice.
Thankfully, a small investment of effort into modifying open source systems to serve as reference implementations can provide a significant amount of insight into flaws or possibilities with otherwise theoretical directions, as well as delivering practical benefits to everyone who uses that software if those modifications are accepted by the parent projects. Here's hoping that the more agile options like Koha, Evergreen, VuFind, and Blacklight continue to push the evolution of their proprietary competitors.
Monday, February 3. 2014
Back in August, I mentioned that I taught Evergreen, Koha, and VuFind how to express library holdings in schema.org via the
The language for some of the terminology may seem a little overly commercial right now, but the next iteration of the schema.org standard will adopt language that more broadly supports non-commercial activities... and this broadening of a number of schema.org definitions is also an outcome of the Schema BibEx community efforts. I'm pretty happy with the results of the group over the last six months! Hopefully this sheds some long-overdue light on some of the results of our efforts, and helps other systems adopt our group's recommended practices for exposing metadata via schema.org.
On , I'll be participating in Laurentian University's Research Week lightning talks. Unlike most five-minute lightning talk events in which I've participated, the time limit for each talk tomorrow will be one minute. Imagine 60 different researchers getting up to summarize their research in one minute each, and you have what is likely to be a brain-melting hour. Should be fun!
Here's a rough draft of what I'm planning to say (which, when read at an even cadence with decent intonation, comes out to exactly one minute:)
What would you understand if you read the _entire_ world wide web?
Thursday, January 30. 2014
Tuesday was not the greatest day, but at least each setback resulted in a triumph...
First, the periodical proposal
for schema.org--that I have poured a good couple of months of effort
into--took a step closer to reality when Dan Brickley announced
on the public-vocabs list that he had created a test build that
incorporated the RDFS that I had written up. Excitement rapidly turned to
horror, though, as I realized that I had made a classic copy/paste error, in
which I had changed the displayed name of the
Luckily, after I fixed the RDFS, Dan was able to put together a revised test build later that day that actually reflected our intentions. So that can continue moving forward...
Second, our Evergreen instance started acting up rather badly. All of the connections to the database server were being gobbled up, and we were scrambling to figure out why. While I'm on sabbatical I'm not really supposed to be involved in the day-to-day operations, but when a core service stops running it's okay for research to wait for a little bit... Eventually I tracked down a fix for a potential denial of service problem (Search result rendering can crush the system) that hadn't been merged into our production system (the fix came out after the start of my sabbatical), and shortly after I put that into production we were back up and running.
Third, after the Evergreen problem was resolved, Bill Dueber pinged me
innocently on IRC. He had run into a problem with File_MARC; when serializing
MARC as MARC-in-JSON format, fields with a subfield
(Page 1 of 43, totaling 169 entries) » next page
This work is licensed under a Creative Commons Attribution-Share Alike 2.5 Canada License.