All posts by Gabriel Bodard

Recommendations for EDH person-data RDF

At the first meeting of the Open Epigraphic Data Unconference (OEDUc) in London in May 2017, one of the working groups that met in the afternoon (and claim to have completed our brief, so do not propose to meet again) examined the person-data offered for download on the EDH open data repository, and made some recommendations for making this data more compatible with the SNAP:DRGN guidelines.

Currently, the RDF of a person-record in the EDH data (in TTL format) looks like:

<http://edh-www.adw.uni-heidelberg.de/edh/person/HD000001/1>
    a lawd:Person ;
    lawd:PersonalName "Nonia Optata"@lat ;
    gndo:gender <http://d-nb.info/standards/vocab/gnd/gender#female> ;
    nmo:hasStartDate "0071" ;
    nmo:hasEndDate "0130" ;
    snap:associatedPlace <http://edh-www.adw.uni-heidelberg.de/edh/geographie/11843> ,
        <http://pleiades.stoa.org/places/432808#this> ;
    lawd:hasAttestation <http://edh-www.adw.uni-heidelberg.de/edh/inschrift/HD000001> .

We identified a few problems with this data structure, and made recommendations as follows.

  1. We propose that EDH split the current person references in edh_people.ttl into: (a) one lawd:Person, which has the properties for name, gender, status, membership, and hasAttestation, and (b) one lawd:PersonAttestation, which has properties dct:Source (which points to the URI for the inscription itself) and lawd:Citation. Date and location etc. can then be derived from the inscription (which is where they belong).
  2. A few observations:
    1. Lawd:PersonalName is a class, not a property. The recommended property for a personal name as a string is foaf:name
    2. the language tag for Latin should be @la (not lat)
    3. there are currently thousands of empty strings tagged as Greek
    4. Nomisma date properties cannot be used on person, because the definition is inappropriate (and unclear)
    5. As documented, Nomisma date properties refer only to numismatic dates, not epigraphic (I would request a modification to their documentation for this)
    6. the D-N.B ontology for gender is inadequate (which is partly why SNAP has avoided tagging gender so far); a better ontology may be found, but I would suggest plain text values for now
    7. to the person record, above, we could then add dct:identifier with the PIR number (and compare discussion of plans for disambiguation of PIR persons in another working group)

A Conversation between SNAP and CIDOC-CRM

SNAP:DRGN & CIDOC-CRM conversation
Friday, May 15, 2015: King’s College London

Attending: Gabriel Bodard (GB), Arianna Ciula (AC), Øyvind Eide (OE), Faith Lawrence (FL), Christian-Emil Ore (CEO), Paul Rissen (PR), Valeria Vitale (VV), Hafed Walda (HW).
Apologies: John Bradley, Steve Stead.
Minutes: GB.

We have three main topics of discussion:

  1. personal relationships (the SNAP “bond” ontology);
  2. co-references (and the inferences that derive from them);
  3. SNAP use of ontologies, and mapping to CRM.
1. Personal relationships/bonds
  • CEO: The CRM defines several types of relationship (e.g. event, group, unilateral, family)
  • GB: SNAP will eventually need to cover many more than just family/household relationships, as we currently have in the ontology
  • OE: Is the aim to map all SNAP relationships to the CRM ontology, so we can always represent SNAP in CRM?
  • FL: gave a summary of snap ontology
    • (digression on equivalences between [lawd|crm|foaf|snap|etc.]:Person; is this a union set, rather than a single overlapping definition?)
    • dual-classes of relationships: serious/casual/legally recognized; social contracts; intimate; household; foster/adopted/inlaw/claimed;
    • gender (and other assumptions) not modelled in top-level classes, but could (maybe should) be?
    • CEO: we can model all of these with group relationships, and then type them. Maybe we should make a recommendation for extending CRM with SNAP classes?
    • GB: can we model non-family relationships (at the top-level)?
      • [Not currently.]
    • CEO: We should probably leave events out of the typology for now.
    • VV: How can “ContractualRelationship” and “Relationship” be siblings?
      • (GB: rename “Rel” ~~> “QualifierRel”)
    • GB: then let’s just list all the new non-family relationships we need, and worry about grouping them (or not) later.
  • OE: Suggest a follow-up meeting on CRM-INF (with Steve Stead, Dominic Oldman and Hugh Cayless).
  • PR: BBC programmes ontology defines relationships by membership to groups
    • could build on snap bonds for new relationships; useful for scholarly/journalistic claims, inference etc.
2. Co-references–both unambiguous and suggested (and inference)
  • OE: distinguishing explicit and implicit co-reference:
    • implicit co-reference is what all scholarly systems do, x=y.
    • explicit co-reference requires attributing statement to someone
    • a negative co-reference has no common target
    • do co-references need a target?
    • CEO: CRM doesn’t model identity, per se; two entities with different ids are therefore two different entities. CRM can’t express conflicting/untrue information.
    • AC: it’s the expressing of conflicting opinions that is the problem there, if you want to keep both.
    • HW: is identity a combination of person and context?
      • CEO: They have different identifiers/are in different data-spaces.
    • OE: SNAP needs to make explicit co-reference statements (with “belief system” over the top). Do we want fuzzy reliability values on them? (GB: no!)
3. SNAP ontology(ies)
  • AC: lawd:hasAttestation/hasCitation == crm:isReferredToBy ?
  • AC: lawd:nameAttestation == crm:appellation ?
  • AC: CRM-inf might be more useful for Scenario 3 (unambiguous and unproblematic co-reference) than Scenario 4 (scholarly commentary about co-references/relationship), because CRM is a bit deterministic.

How to find people in the SNAP graph

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 1SNAP 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

Who does SNAP:DRGN serve?

dh-snap-thumbAs we come to the end of the first year of SNAP:DRGN funding, and start planning applications for follow-up funding, it is worth rehearsing the main academic and other benefits of the SNAP:DRGN projects and the prosopographical-onomastic graph that we hope it feeds into. Continue reading Who does SNAP:DRGN serve?

FAQ: What are the limits of SNAP content?

We have often been asked:

“SNAP” contains the word “Ancient,” which suggests a rather inclusive definition of classical antiquity, but “DRGN” includes “Greco-Roman”, which implies more traditional restriction. Are you interested in prosopographies from outside the strictly Greek and Roman world?

Yes! (Short answer.)

Longer answer is in two parts: Continue reading FAQ: What are the limits of SNAP content?

Minutes of second advisory board meeting

SNAP:DRGN Advisory Board (AB)

2nd meeting Skype (voice only) 2014-08-27

Present: Øyvind Eide (ØE, chair), Fabian Koerner (FK), Laurie Pearce (LP), Charlotte Roueché (CR), Rainer Simon (RS), Gabriel Bodard (GB, principal investigator)

Apologies: Sonia Ranade, Robert Parker.

The meeting lasted one hour.

Minutes written by Øyvind Eide based on notes from Laurie Pearce. Continue reading Minutes of second advisory board meeting

(SNA)P

Being a conversation between Gabriel Bodard, Yanne Broux and Silke Vanbeselaere about the SNAP:DRGN project and Social Network Analysis

Cross-posted to Data Ninjas: http://spaghetti-os.blogspot.be/

Gabriel Bodard: So, tell me what is Social Network Analysis, and how is it useful for prosopography projects?

Silke Vanbeselaere: Social Network Analysis (SNA) is basically the study of relationships between people through network theory. First used in sociology, it’s now become popular in many other disciplines, with a budding group of enthusiasts in (ancient) history.
What it does, is focus on relations (of whatever kind) instead of on the actors individually. Through visualisation of the network graph and the network statistics, information can be obtained about the structure of the network and the roles of the individuals in it. Continue reading (SNA)P

Are you a prosopography?

At the SNAP:DRGN project meeting in Edinburgh a few weeks ago, we decided on a couple of definitions that will impact on the ways in which partner datasets interact with the project. Our current thinking is that we need to distinguish between two kinds of data:

(1) The first kind, which we’ll loosely call a “prosopography”, is a curated database of person records, with some ambition to be able to be used as an authority list. Prosopographies such as PIR, Broughton, PBW, etc. would be obvious examples of this category, as would the controlled vocabulary of persons in a library catalog like VIAF, Zenon, British Museum persons, Trismegistos Authors, the Perseus Catalog, etc. Even if the task of co-referencing persons is incomplete (as with Trismegistos, say), the intention to disambiguate qualifies the dataset as a “prosopography”. Continue reading Are you a prosopography?