Project Home

Script

The goal of the project needs evaluation is to assess the requirements of prospective users based on the current system in use. As of now, the HBTIN corpus, managed by Laurie Pearce, is the main data set that the tool will be tested on, however, as we anticipate further applications beyond this initial repository, it is important for us to get a wide range of perspective from active scholars in the field, based on their practice.

For the interview (in person or by phone), I will be looking to find out what information you use, in what format(s), when doing prosopography. More specifically, if you're going to explore such an online tool like HBTIN, what kind of questions would you want to be able to ask of the data? How would you expect the answers (graphs, visualization, trees)? If possible, what cross-referencing to other information sources should happen in order to create a meaningful context for you to view/interact with this data?

The procedure we will follow today will go as follows: we’re going to start out and talk for a few minutes about how you use the current system(s) at your disposal (HBTIN, CDLI, ePSD) to explore corpus data, focusing on what you like, what problems you encounter. Then I will have you look at graph forms in which you might get the answers.You will brainstorm and play with them as I’ll ask you a few more questions about these.

After the interview, if you have any further questions, please take a look at the wiki (http://code.google.com/p/berkeley-prosopography-services/wiki/ArchNotes). It may refresh your memory from the conference on the direction this work is taking.

Questionnaire

• what data and metadata elements do you make use of the most in your research work?
• what visual representation formats usually enhance your understanding of the record? which have more important priority?
• based on your current corpus database (filemaker pro), what additional items/forms do you need?
• what kind of navigation/use do you foresee yourself needing support for in your research?
• based on the factoids recorded, what filters would be useful: time, transaction
• how will you recognize whether the information presented is useful or not, and update it?
• what additional value would there be in having such a prosoprography system to use?
• would there be interest in mapping out the process around what you do when working?
• how do you deal with uncertainty in some of the information presented? what should happen?
• what are the rules / logic the system should be aware of (how long people lived, relationships between people, transactions...)?

Findings

The Berkeley Prosopography Services system is used to explore administrative practices, how institutions were structured, hierarchical/familial affiliations as well as use/function of the seals. We interviewed scholars (professors and graduate students) from universities in Berkeley, Chicago, Amsterdan and Germany. The above questionaire was used as a guide for the interview (30 minutes), coupled with a pair of graph packages (GUESS and Prefuse), for feedback on visual representations for the data. Here are the facts summary from interviews with prospective users.

1. Data Elements

Persons
The basic unit is an individual. Individuals may have more than one name, indicated in the text by the phrase "whose other name is ..." following his name. Names can be mentioned in more than 1 tablet (document), thus providing evidence of individuals' participation in many activities. Thus, the broader context around names is useful to view when working with a record (i.e., surrounding text - see HBTIN). This highlights the role(s) people play in different texts. The data elements for an individual stored in an average corpus are: personal names, patronymic, title (particularly referenced in intellectuals' record texts), function, relationships between persons.

Tablets
Tablets contain the date (which includes the data king/year/month/day), as well as the place of composition of the tablet. These data identify the place of origin of the tablets.

Seals
Individuals owned and used seals, which have a motif. Some of the data elements kept on seals include: impression before or after a type of transaction, owner's name, motif design, type of seal, language. Some of the questions one might pose about seals include: - who's using a particular seal over time? - how are the seals shared amongst members of the same clan/family? - what is the motif on a seal, and what are its variations?

Note: family trees useful to quickly trace the seals used by different members

2. Visual Representation
The most important feature request is to visualize networks between people and texts, highlighting anything with regard to a particular person (not just name variants or hypocoristics, but activities, over time, across relationships with people from various groups, etc). There is also the need of a multi-names view showing how people are interacting across different areas, or to be able to distinguish multiple instances of the same person.

Family trees would be nice (the number of generations for which these can be reconstructed depends on the patterns and contents of the data specific to each period). A family tree view or kinship diagram color-coded to highlight occurrences of names in a text (see graph view demo - highlight network of people, see concentration, centrality, directed ties depending on the nature of relationships, density).

For seals, tracking use over a time perspective is a need to compare seals based on the motifs, highlighting the changes in the motif design over time.

3. Data Navigation

The primary navigation need is for a more dynamic exploration of the data, on the fly, and in context.

One navigation mode of the Prosopography Services application should be to start with a name, check title and ethnic origin, and if it appears in multiple texts, display these on a map with a picture of the tablet (when available) as a mouse-over or on-click event layer. There is also a need to combine/compare the multiple titles under which a name might appear, by checking the date on the text or looking at the locations/places associated with this name. From there, one should be able to explore references to other people in the same text and history connected to the name.

Another navigation mode should be an advanced search page taking in a combination of parameters to construct the database query. When possible, visual data (like seal motif) should be displayed in context with the results of a search where this data is relevant. Top-level search fields could include: name, activity (buying/selling), connections (family/witness), title (intellectuals).

In tablet exploration mode, users want to see the document as it is written, identifying the type of document that it is (e.g, marriage contract). One can look at the family trees associated with the names on a particular tablet. The ability to generate a summary report on a group of tablets would be very nice.

4. Search Filters

Interviewee 1: by activity, by transaction, by partner
Interviewee 2: by time, by transaction type, by document type (sales contract, receipt, administrative list), by city, by roles
Interviewee 3: by family relationship, motif type, associated uses for the seal
Interviewee 4: by time and date (normalized), keywords (particular transactions), geographic origin of tablet (when available), title
Interviewee 5: by name variant, by type of transaction, by time period, geography, by document, when personal name appears as witness

5. Validation Rules

Researchers make assumptions about the origins of seals based on information mentioned in the text (Greek, Babylonian...). When possible, BPS should make use of this information through additional fields, explanatory notes or boxed links.

It is often possible to tell which city a tablet came from by its museum number and by the mention in the text itself of the city in which it was composed.

Each city has a specific pantheon. As people's name are often associated with a particular deity's name, we can make use of this information too.

Use keywords of transaction types.

People worked on an average 30 years, although longer "careers" are attested.

Usually, people lived in one place.

Conclusions

Researchers are interested in keeping track of names in an organized fashion (activity, clan, document) and currently keep separate databases, that would need to be normalized into a single shared format (XML). In looking at the graph packages, there were a plethora of answers, highlighting the potential of many graphical formats:

vizster: for displaying names
enron explorer: for transaction relationships (type & intensity)
simulation/monitors - for people activity over time
new visualizations - for grouping people by roles
new visualizations gives a sense of concentration in the population around 1 person (which groups are more mentioned)
near word: size of words represent importance; colors; could represent who or where?
34all: save space by using mouse over and shifting colors (don't need to show pictures)
graphview demo: highlighted network of people, see concentration, centrality, directed ties depending on the nature of relationships, density
docuburst - could have different offices and the people in it would have the same color senior would have bigger size.
nearword - names and orthographic variants
radialgraph - good for offices and how individuals interacted, accounting for familial relationships
graphview - relations between officials and families (same color), with the surrounding network representing the people involved with in transaction