evidence
evidence copied to clipboard
evidence-dev
Evidence in an Academic Setting
My primary use-case for evidence.dev is to use it to publish archaeological fieldwork reports (and similar academic outputs[^1].) It would be nice to have an entirely self-contained workflow that I can encapsulate into a github action such that depositing a sqlite file into the repo is sufficient to generate something not wholly unlike my colleague's https://minicomp.github.io/wax/. In the best of all possible worlds, I'd be able to deploy this on a raspberry Pi (and/or a stone dvd[^2]) and use it as part of data repatriation to Indigenous communities here in Australia.
As such, being able to point to within-repo SQLite (and/or well-formed CSVs that are effectively SQLite tables) to run queries against would make it wonderfully self-contained and excellent for archival academic publishing.
[^1]: I'd love to see how it does against the TSVs scraped using the Latin Epigraphy scraper I made https://github.com/mqAncientHistory/Lat-Epig, but since that's tsv->sqlite...
[^2]: Archival media is really tedious. Being able to have FAIR data on archival media is even harder. I can see this being a major tool to display said archival media.
@Denubis this is fascinating. The map on your project page is 👌
Just some housekeeping: I am going to open an issue for CSV support and one for SQLite, and I am going to rename this to 'Evidence in an Academic Setting' and open it up to be more of a discussion.
Upfront, I'll also flag that today, Evidence is not the right answer for long-term archival of data :) The project is only about 80 days old, it's still very much in Alpha and it's built on top of a web framework which itself is very new. Hopefully we can get it to that point though. I would be stoked if there were Evidence projects running on raspberry Pi's in Indigenous communities in Australia.
I took a look at WAX, and was really nodding my head on this piece:
The skills needed to create Wax sites are agnostic. This means they are largely transferable for use in other digital projects. ‘Learning Wax’ does not mean learning how to use a platform.
I love that sentiment, and that's definitely how we want to build Evidence. The web is the platform, let's build tools that make it easy for data people to build great stuff for the web.
My biggest question for you is why are you thinking of Evidence for these purposes? You are obviously very adept with Jupyter. Why not Jupyter or WAX?
@mcrascal Good questions.
Very much noting that this is in alpha :) (Having my own project in alpha, I rather understand the shape of things here...)
Let me rephrase your question as: "What tools are available to present data to a static site in an academic setting"
Many of my projects attempt to answer this question:
- onwork.edu.au has paperpile -> python to recursively trawl paperpile citations -> generate many many many markdown pages -> serve on github pages. The upside is that it works. (Rather a big upside, TBH). However, it's clunky and needs a dedicated server and the hacks I needed to do for categories were tedious in the extreme. (Lots of list-writing to YAML). Having something that could write citations into a relational database (SQLite) to reduce the complexity of the presentation layer means that there would be a chance someone else might be able to maintain the frontend. Also, Jekyll/Ruby is... really frustrating and slow. The specific value proposition is that instead of writing liquid to iterate over lists generated by python writing categories and themes recusrively and having a 20 minute jekyll build, I could
Select category from citation_category where citation_id = foo;and... be done with it. Massive reduction in complexity. - I'm working on a publication with @ewansc which is literally a SQLite db of roman inscriptions to an Open Context publication. It would be great to have a github pages SQL/GIS layer so my PhD student can show work-in-progress stuff to his other supervisors. (It turns out that supervisors aren't very keen on CSVs, much less SQL). We have tried to show this with datasette but the various hacks we had to do to get something that could run datasette from a url (I can't even find the messages where we figured out how to do it) were utter hacks. In many ways, this request is "What if Datasette, but for static sites?" -- I've also poked at https://phiresky.github.io/blog/2021/hosting-sqlite-databases-on-github-pages/ which... is a lovely proof of concept, but lacks the markdown formatting that you folks promise.
- There are also some in-uni projects which would have benefited from this. In short, the need is "The ability to present structured, relational, data in a maintainable fashion" (Also maps. Always maps. ::sigh:: Let me know when you want to talk about GIS stuff)
- As part of the major project I'm on, we're getting to the point where we need to think about data export. That project is using a NoSQL (CouchDB) backend, but archaeologists and field researchers expect their output in ... spreadsheets. Having a proof of concept "Here's your project report" as part of an export is very exciting to me indeed.
The idea of a Node project (As a note, they just bumped LTS up to 16 from 14. I've yet to transition my CI infrastructure, but... it's probably worth doing sooner rather than later) that is part of a robust archival workflow ... should be hilarious. But if I do anything serious with this I'll smush it into a docker image and ship that, to prevent dependency hell from breaking everything.
@denubis - this might be worth another look for you! We've added early support for maps, added sql lite, and duck db, might be worth another look! Closing this for now, but thank you again for all the great ideas early on.