Long ago, and far away, I had a thousand other blogs, all lost to the sands of time on the internet. Well, not lost per say, more abandoned as I realized I would not be able to faithfully shepard them along the winding roads of internet time. My goal was to consolidate here, hunkering down in the welcoming leaves of markdown and GitHub.

In the shuffle, however, I lost a blog I was most fond of, a simple “Word of the Day” or “For the Word”, or something along those lines. It was posts dedicated to a single word, a meditation on the wonderful acorns of knowledge and enshrined history that exist within a single word. And so, upon reading a word last night that fit the bill, I’d like to bring it back here. And so, without further ado…


The impetus for blogging about this word can be traced back to a recent trip to Denton, TX to visit an old friend. While there, we saw the legendary performer Paul Slavens perform. He takes money from the audience and makes up songs on the spot based on song titles or themes they scribble on bar napkins.

Some estimates have him at more than 2,000 improvised songs in the last 20 years. So, needless to say, there are plenty of examples on YouTube. But, despite what you might see in the following video, it’s hard to capture his charm and wit that exists between songs; the real appeal and virtuoso.

Wikipedia says this about him,

“In the mid 90s Slavens began creating improvisational songs based on audience suggestions, and has created an estimated 2000 songs over the last 2 decades, many recordings exist, although few have been released. Often these songs are humorous in nature and can be quite ribald.”

And such was my (re)acquaintance with ribald. Without any objective definition, I knew precisely what this word meant. How is that possible? Moreover, can a definition ever replace this initial correlation of ribald that I now hold?

In Philosophical Investigations, Wittgenstein opens up with a quote from St. Augustine,

“The individual words in language name objects—sentences are combinations of such names. In this picture of language we find the roots of the following idea: Every word has a meaning. This meaning is correlated with the word. It is the object for which the word stands.”

But, interestingly, immediately begins to push against this idea, suggesting it’s a far too simplistic understanding of language, and by proxy, words. I think it’s safe to assume that Wittgenstein would support the idea that a word does not have a single meaning, but is actually given meaning from context, learning, and much more.

And so, returning to ribald, this word was perfectly defined for me through a personal experience and the persona of Paul Slavens. Now, sure, of course, I realize there is an agreed upon definition of ribald. From the venerable OED, for ribald as noun:

“1. a. In the medieval period: a person of low social status, esp. regarded as worthless or good-for-nothing; a rascal, vagabond. Also as a form of address. Now arch. or hist.

“2. A foul-mouthed or blasphemous person; one who uses offensive, irreverent, or scurrilous language; one who jeers or jokes in a rude or lewd way. Now rare.”

“3. A promiscuous or loose woman; a wanton, a harlot. Obs.”

“4. A wicked, dissolute, or licentious person; a villain. Now arch. and regional (Sc.).”

and so on, and so forth. Also from the OED, for ribald as adjective:

“1. Of a person or persons: (in early use) lewd, coarse, or licentious in language or behaviour; deliberately and offensively abusive or impious; (now usually in weakened sense) given to bawdy, vulgar, or irreverent talk or behaviour; amusingly rude.”

“2. Of language, humour, etc.: coarse, vulgar, scurrilous, irreverent; (subsequently esp.) referring to sexual matters in an amusingly rude or irreverent way. Now the most common sense.”

of which appears to be much more common.

So we have these definitions, and they are, unsurprinsgly, expansive to say the least. We love words like this; forged in the streets of pre-industrial London, tumbled around during the bawdy – notice the similar ‘ald’, ‘awd’ sounds, coincidence? – early 1900’s. And yet, with all that history and lyrical verse dedicated to this word, I meet it halfway with my intuited, pop-culture, internal definition.

It reminds me of work we’re doing with objects in digital repositories. There is a tension between front-ends that extract disconnected information from disparate sources, reconstituting client-side for a conceptual whole, vs. opinionated server-side models that pull some suggestions for stylings from here and there, but for the most part “push” or impell themselves through a series of pasta makers (I’m consciously choosing to move away from meat-based metaphors, you know, for the planet). The net effect is often the same to the unaware user, but the mechinations that move the system are fundamentally different in their approach. Both have pros and cons. And relevant to this discussion, there is very rarely an ideal state that adheres entirely to one philosophy or another. These systems we build and work with are muddy, confused over time, and contorted to work in the real word.

Much like words; those great and wonderful puzzles.

ps. all typos and mis-spellings are my own, no editing has been performed.



I’m excited to say, work has commenced on a rewrite of Digital Collection’s primary API (pinning this link to a commit before the API disappears as we know it). I also use the term “API” a bit loosely here, as it has served almost exclusively for internal use, powering our decoupled front-end. Now an API that is used wholly internally certainly qualifies under the myriad of API definitions out there. Where I challenge that coveted title is the lack of consistency and documentation it has exhibited until this point.

And that’s okay! Which, if one hasn’t noticed already, is a running theme around here.

The API grew piecemeal with the rest of the ecosystem. Where once it queried Solr directly for an object’s metadata, later it would retrieve that Solr doc via a method buried in an Ouroboros content-type object. Where once we would fire off multiple API functions to fire – member of collections, related objects, comprehension of images, etc. – later they were grouped under a singleObjectPackage class that aggregated and returned all that information in single, sprawling response. It’s come a long way, and has proved to be extremely versatile, reliable, and fun to build.

But as mentioned in a previous post, we are in the process of re-building / refreshing the front-end, and the opportunity presented itself to rework, refine, and wildly improve a meandering bit of code.

With this opportunity to completely restructure the API, it’s a great time to leverage a library that might help with building out an API. After a bit of poking around, Flask-RESTful emerged as a very enticing option, and the route I think we’re going. For a variety of reasons:

ability to handle client content negotion (with a bit of finagling)

One of our goals with the Digital Collections is to treat our collections as data in many ways (a quick Googling will reveal the blossoming ideas and literature around this idea, perhaps fodder for another typing). Mark Phillips from UNT has a neat post about hacking their resource URLs, that left a lasting impression. Excited about the thoughtful way in which the URL could be leveraged for different views and pieces of a resource. It percolated for a bit until this opportunity for API and front-end reworking, and the simulataneous emphasis on collections as data, presented itself.

Without losing the thread too quickly here, I would like our API for routes such as /item/wayne:foobar/metadata or /item/wayne:foobar/? to return metadata in JSON form, but then have a route like /item/wayne:foobar/txt – if it’s a book – return raw text, with a text/plain Content-Type header. More to the point of content negotiation, let the client request different forms of the same information at the same route.

parameter parsing built-in

Good grief, this is just a no brainer. We can enforce parameters types (string, int, etc.), and automatically return responses specific to a particular parameter, with appropriate HTTP codes, as well. Sign me up.

and more

This is really just the tip of the iceburg. Instead of wiring and hand-rolling each response or error, we can pipe our data through this library in a coherent fashion each time. Moreover, this pattern I keep encountering, I would like to put the kibosh on:

  1. dreaming up new thing, exploring options
  2. begin to build from scratch, stumble on other libraries
  3. great excitement
  4. realize that libraries have a learning curve
  5. sense of “meh”, continue building from scratch
  6. progress slows as better understanding of requisite bits and pieces emerges
  7. continue building…
  8. cobbled code meets minimum requirements
  9. begin to improve and refactor, realize that original libraries held functionality all along
  10. realize spending much more time on writing bits and pieces than would have spent learning library
  11. vow to never make this mistake again

And SO, mistake made not again! Flask-RESTful has been an utter delight thus far, and looking forward to pressing on.

Framework V2 Frontend

Choosing a framework for our v2 Digital Collections front-end

https://digital.library.wayne.edu/digitalcollections/item?id=wayne:vmc3024 https://digital.library.wayne.edu/digitalcollections/item?id=wayne:vmc3024

We are currently in the midsts of refreshing our Digital Collections front-end. It has been a workhorse for us, still functions, and still looks respectable, but the foundation is beginning to crack as we push the original design and corners of spaghetti code beyond their original visions.

The front-end was visually imagined back in 2012-2013. At the time, our “back-end” consisted of nothing more than raw Solr endpoints and some hacked together scripts that returned more complex queries from Fedora Commons, specifically for RDF queries. Javascript grew in the front-end like weeds, with functions and files springing up whenever new functionality was introduced:

  • user login and authentication
  • iteratively improved search
  • full-text vs. structured metadata refinement
  • improvement of facets
  • collection browsing
  • serials browsing and interfaces
  • inter-linked learning objects
  • introduction of hierarchical content types such as archival materials and serials
  • and the list goes on…

I’m proud of what we’ve built, something that is remarkably usable and cohesive given the breakneck pace of change and learning that ran parallel. It has survived entire re-imaginings of how digital objects are structured, a full-fledged API on the back-end that powers it, migration of servers, introduction of vagrant provisioning, you name it.

But its time has come. As we push into more digital objects, we’ve started to notice some performance hits that are a result of inefficient JS tangles and approaches. Our initial approach was a “lightweight” JS front-end that relied heavily on AJAX calls to retrieve information from our back-end API, that was drawn on the page with jQuery-Mustache templating. We’ve made a handful of improvements that keep it humming along, but any substantial changes would require reworking a lot of ugly JS code. And I can say that, because we wrote it all.

The visual style is also feeling a bit dated, or perhaps if but only stale. It needs a refresh there too.

And there was the important issue of sustainability. We know the ins and outs of the JS code, but thar be dragons thar, and feels near impossible to document in a lucid fashion.

So, the time is right. We have at our disposal someone who is going to put together front-end wireframes that we can use to wire and implement. The next big decision: what kind of organization and/or framework for the front-end?

We spent a bit of time going round and round, discussing the pros and cons of emerging JS, Python, and other frameworks. It is worth noting, all while simulataneously congnizant that we may migrate to a more turn-key solution down the road, if projects like Hydra-in-a-Box provide a truly, and palatable kit-and-kaboodle option. Another goal, briefly alluded to above, is sustainability in a front-end; something that can be worked on, improved, fixed, and loved for some time.

I can’t believe I’m typing this, but we are starting to hone in on using a PHP framework. Considering Slim and Lumen at this point. Why a PHP framework? Why not Flask to augment the other python components in the stack?

For a combination of reasons.

First, PHP is a language commonly used here in the libraries. More people know it now, and though you could debate this a bit, it’s probable that anyone coming in later will at least be familiar with PHP. Perhaps you could say the same about Python, but as long as the website is PHP based, we’ll have people “in shop” who know PHP. Perhaps the same can’t be said for Python. And that’s important.

Second, we would like to keep front-end and back-end cleanly separated. At our initial wireframing meeting, the individual creating a working wireframe leveraged our quirky and undocumented API and created a working demo. That was amazing. It reinforced the idea of treating our collections as data, maybe even first and foremost. Front-ends will come and go, amaze and disgust, but our underlying, structured digital objects will remain. An organized API for access to those materials means a multitude of front-end interfaces are possible, and migration down the road is easier.

We also know ourselves well enough that if we created a python-based, Flask front-end, we would inevitably start importing libraries and models directly from the back-end Ouroboros ecosystem. While this may be programatically efficient in some ways, maybe faster in others, it would muddle clean lines between our back and front ends that we would like to maintain.

And so, PHP is looking good. We still get the following from a PHP framework:

  • URL routing: as easy to return machine-readable data as rendered pages
  • built-in templating: likely with syntax nearly identical to Jinja in Flask
  • models: make a nice connection between front-end models and API
  • ORM: room to grow into user accounts, etc.
  • conventions to organize our code
  • and many more these tired fingers haven’t yet gotten to

Undoubtedly there will be updates and twists in this adventure to a new front-end – no little one, being a complete rewrite of our digital collections API – but it’s exciting to have a path to explore at this point.