the code of things

As I push more of the site into operation with real data it is apparent that certain design choices may not have been as great as I would have liked them to be. The advantage of using Django is, so long as I do not do anything weird with primary keys (I already did something weird with the primary key on one of my models and had to rebuild the whole database), I can use migrations to change the structure of the models.

Early on, one of the biggest compromises I made was to make the data fit the very loose data structures I was getting from Zotero. It is both strangely over specified, there are only certain item types you can have, and underspecified, there is no restrictions to the data going in a field, date can be “Spring”. Python is great at converting date data if it knows what it is getting so I manually (and still do for new references and sources coming in) converted the date data on all my Zotero items to ISO 8601. The actually item types, though, so that I could use them sensibly rather than generically, I have set up as specific classes that inherit from my generic Zotero item class. That has worked fine so far with the only hiccup being the Pyzotero update to the API v3 which returned the data in different structures.

The other issues have been in setting up the poems for the different media types. It does not really make sense to put the print poems online (given they are print) but I made that section with the electronic poems in mind. The tweaking there has not been too much of a problem but I imagine I will adjust it quite a bit more over the next few months until it is reflecting the way I would like the poems to be presented.

I plan to do an accessibility audit. My accessibility checking skills are a bit rusty but I have tried to keep everything as clean as possible. I intend to make some alternate stylesheets for contrast and make sure some of the features like date ordering are clearly labeled and useable.

The last major update is to fix up the templates to add RDFa (Resource Description Framework in Attributes) and to set up the SPARQL (SPARQL Protocol and RDF Query Language) endpoint. The data is already fairly explicitly structured in the database so expressing the RDFa in the HTML should not be too much of a problem. The only decisions is which schemas to use and whether I need something more specific than already available. I am yet to find an ontology that is good for describing online literary works (not that I think one does not exist—I am just yet to find it). So, marking up the poem index pages will be interesting or, like all good compromises, generic. A further problem is defining unique identifiers for the pre-ISBN books and documents. I could use their URLs as they appear on this site but that is both artificial and defeats the purpose of having interoperable data.

For the SPARQL endpoint I am thinking of pushing the data out to a graph database, Neo4j in this instance, and hosting it on one of my other servers. That way I will not be complicating my current server set up and I can experiment a bit before providing the endpoint. I had initially thought of using D2R but I decided a model with greater separation would be better. That way if I do change my underlying database so long as I keep pushing the data out in the same format I will not have as many problems.