As you probably know, the pilot SNAP:DRGN project ended in December 2014, and although there are nearly seven hundred thousand person records visible through the public triplestore (SNAP 1 – SNAP 673934), we are currently lacking a user-friendly way to search within and find these records. (We’re working on this, as we’ll report here soon.) Most of the person records in SNAP so far are from LGPN, Trismegistos and PIR, but if you have a reference to PIR² M 436, say, or LGPN V.2 Θουκυδίδης 11, and want to find the SNAP URI with which to annotate your texts, there’s no obvious way to know that these are SNAP 9024 and 33624 respectively. Continue reading How to find people in the SNAP graph
With the end of the pilot project scarily in sight it is time to review where we are and where we hope to be by the end of December.
The big news is that (hopefully) the first set of SNAP identifiers are now frozen!
What this means is that for the first 5 datasets have now been ingested and had SNAP identifiers linked to each of the persons and those identifiers are fixed. There may still be a few tweaks to the RDF descriptive data coming in from the projects but the identifiers will remain the same. Continue reading State of the Snap-Nation
In the process of working with a few of our partner projects, we have produced some sample RDF fragments, which we thought might be useful as an illustration of SNAP RDF format for other projects currently planning to expose a version of their data via our graph. We hope to include at least some examples of this kind in a later version of the SNAP:DRGN Cookbook. Continue reading Some example RDF fragments
We’ve been discussing lately how to merge person records in SNAP, so that when we encounter partner projects that each have a record for the same person, SNAP can provide a useful service by combining those into single, merged records, and we can start to get an idea of the requirements for performing operations like merges on our data. This discussion has proved something of a rabbit hole. Continue reading You Aren’t Gonna Need It
One of the decisions that has to be made when creating an ontology is which concepts you encode as classes and which you encode as properties of those classes. One of the difficulties is that there is no overarching ‘right answer’ (although there are wrong ones) to how you should model your domain, in has to be decided on a case-by-case basis of what works best for the type of world view that you are trying to encapsulate within your model. This post is a request for feedback to help us decide which model works best for both the project and the wider community. Continue reading The Old Classes vs Properties Debate (or Relationships Are Hard, Part 2)
Last week, Faith gave a great overview of some of the issues involved in describing the relationships between people. This week, I’m going to come at the problem from the other side, looking at what data we have, and how SNAP plans to represent them.
Our initial datasets include Trismegistos People (TM, described by Mark), the Lexicon of Greek Personal Names (LGPN, described by Sebastian), and a set of names (article headwords) from the Prosopographia Imperii Romani, 2nd edition (PIR²) put together by Tom Elliott. TM has web pages that document the references to names and people found in papyri, many of which are hosted at Papyri.info, as well as resources describing the names and person; references, names, and persons all have unique identifiers. LGPN comes at the problem of modeling people from a different angle. They start with persons and add names and references; persons and names have unique identifiers. From PIR², we have only persons, with a “principal” name and identifying number (the article number) attached to them. Continue reading Tensions
People are inherently social creatures. This means any project about people almost always has to deal with the relationships between people. In this, SNAP:DRGN is no exception. Since this is not a new problem there are a number of different models that already exist and are in use in other projects. Ideally we would reuse an existing, standard ontology to describe the relationships—this would allow us to be easily compatible with other similar projects that had (one hopes) gone through a similar thought process and came to the same conclusion. Continue reading Relationships Are Never Easy…