xEAC beta 2014a ready for testing

I have finally gotten xEAC to a stage where I feel it is ready for wider testing (and I have updated the installation documentation). This has been a few months coming, since I had intended to release the beta shortly after MARAC in November. The xEAC documentation can be found here: http://wiki.numismatics.org/xeac:xeac

Features

• Create, edit, publish EAC-CPF documents. Most, but not all, EAC-CPF elements are supported.
• Public user interface migrated to bootstrap 3 to support mobile devices.
• Maps and timelines for visualization of life events.
• Basic faceted search and Solr-based Atom feed in the UI.
• Export in EAC-CPF, KML, and rudimentary RDF/XML. HTML5+RDFa available in entity record pages.
• Manage semantic relationships between identities (http://eaditor.blogspot.com/2013/11/maintaining-relationships-in-eac-cpf.html). Target records are automatically updated with symmetrical or inverse relationships, where relevant, and relationships are expressed in the RDF output. TODO: parse relationship ontologies defined in RDF (e.g., http://vocab.org/relationship/.rdf) for use in xEAC.

REST interactions

The XForms engine interacts with the following web services to import name authorities, biographical, or geographic information:

• VIAF lookup
• DBPedia import
• Geonames for modern places (placeEntry element)
• Pleiades Gazetteer of Ancient Places (placeEntry)
• Getty AAT SPARQL (occupation element) (http://eaditor.blogspot.com/2014/03/linking-eac-cpf-occupations-to-getty-aat.html)
• SPARQL query mechanism of nomisma.org in the UI (and extensible, generalizable lookup widgets)

When the OCLC linked data service supports queries by VIAF URI, I will create a lookup widget to provide lists of related bibliographic resources.

TODO list

I aim to improve xEAC over the following months and incorporate the following:

• Finish form: Represent all EAC-CPF elements and attributes
• Test for scalability
• Interface with more APIs in the editing interface
• Employ SPARQL endpoint for more sophisticated querying and visualization, automatically publish to SPARQL on EAC-CPF record save.
• Improve public interface, especially searching and browsing
• Incorporate social network graph visualization (see SPARQL, above)
• Follow evolving best practices in RDF, support export in TEI for prosopographies (http://wiki.tei-c.org/index.php/Prosopography) and CIDOC-CRM.
• Interact with SNAC or international entity databases which evolve from it.

Linking EAC-CPF Occupations to the Getty AAT

The occupation element in xEAC now supports a SPARQL-based lookup mechanism to link EAC-CPF records to terms defined in the newly-released linked open data Getty AAT.

I won't go into great detail about how this works in the back end, because it is basically identical to the process by which I hooked EADitor into the AAT with EAD genreform elements, which I covered in a blog post last month.

One thing to note, however, is that the xEAC occupation lookup filters for terms that contain "Agents Facet" in the gvp:parentStringAbbrev property. There are different categories of terms--object types, agents, stylistic periods, etc.--that are not semantically distinguished, but at least contain a string in a generic field which allows filtering. I hope that the Getty will move forward with a more formal representation of these facets to improve querying efficiency.

Therefore queries for occupations look something like this:

SELECT ?c ?label WHERE {
?c rdf:type gvp:Concept .
?c skos:inScheme aat: .
?c skos:prefLabel ?label .
?c luc:term "president" .
?c gvp:parentStringAbbrev ?facet 
FILTER regex(?facet, "Agents Facet") 
FILTER langMatches(lang(?label), "en")}
ORDER BY ASC(?label)
LIMIT 25

I plan to apply these filters to the LOD thesaurus editor for kerameikos.org in order to provide a more accurate list of style periods, pottery techniques, wares, and shapes for linking kerameikos URIs to Getty AAT identifiers. For example, "Black Figure" is defined by the Getty as both a technique and a style or period, so "Black Figure" on kerameikos, defined by http://kerameikos.org/ontology#Technique, should refer to the Getty's technique facet (not the style or period) for the term with owl:sameAs.

xEAC: Current and Future Work this Month

I am in the process of migrating various projects to Bootstrap 3, which greatly improves mobile support. Numishare's master branch has been migrated to Bootstrap from jQuery UI (with the exception of multiselect, which is on the agenda). I recently completed the migration of xEAC to Bootstrap (including multiselects on the browse page), and EADitor will be next. Now that I have successfully implemented Bootstrap Multiselect, I will be able to apply these changes back to Numishare. Frankly, the AJAX lookup mechanism for dynamic Solr facet terms is much simpler in Bootstrap Multiselect compared to the older jQuery UI one I had been using for three years--far less javascript required on my end.

While I was at it, and since I'm having Orbeon (the engine powering both the front end user interface and the back end editing in both xEAC and EADitor) output pages in HTML5, I went ahead and applied fairly basic RDFa to EAC-CPF record pages so that machine readable data can be extracted by using the W3C distiller.

I will be traveling to London at the end of this month to participate in the Standards for Networking Ancient Prosopographies meeting to discuss EAC-CPF and xEAC to some degree. The meeting consists mainly of digital humanists who have a lot of experience with TEI and CIDOC-CRM, but may be completely unaware of the emergence of EAC-CPF as a LAM standard for modeling entities and their relationships. Since we at the American Numismatic Society are moving forward with our own prosopography of the Roman Empire (which will tie into other projects, such as Online Coins of the Roman Empire and nomisma.org), we aim to contribute our entity URIs into SNAP, which will facilitate larger scale aggregation of cultural heritage materials related to ancient people. In order to broaden access and use of our data, we will not only provide the source EAC-CPF XML documents, but also alternative serializations in various forms of RDF (like CIDOC-CRM) and TEI conforming to the prosopography recommendations. By the end of the month, I plan to have some basic CIDOC-CRM and TEI exports functional, as well as possibly hooking xEAC up to a RDF triplestore/SPARQL endpoint as a proof of concept of publishing EAC-CPF as linked open data right out of the box.

Integrating EADitor with the Getty linked data AAT

I've been following linked open data developments at the Getty pretty closely over the last few months, especially related to incorporating Getty AAT URIs (and eventually ids from other vocabulary systems) into Nomisma.org and my side-project Kerameikos.org, a LOD thesaurus geared specifically toward Greek pottery.

For some reason, it occurred to me only yesterday that I should adapt EADitor to incorporate Getty AAT identifiers into EAD finding aids.  After all, XForms applications communicate nicely with other REST services (such as SPARQL), and I've already done SPARQL query work in XForms with Nomisma's backend.  I spent about a half hour this afternoon improving the Genreform functionality in EADitor to make AAT (as opposed to the Library of Congress Genre/Format Terms) as the default lookup mechanism.

Here's how it works:

User Interface

1. Add a genreform element into your controlled access headings in your EAD finding aid.
2. Click the Getty AAT radio button (selected by default) to activate the query interface.
3. Type a term and click the search button.
4. A list of results (limited to 25, filtered by English labels, and arranged alphabetically) will appear in the select list.  After clicking an option, click the "Select" button to set the text of the genreform node to the skos:prefLabel from the Getty SPARQL results and to set the @authfilenumber attribute of the genreform element to the Getty id.

Under the Hood

Clicking on the search button does two things: First it replaces 'SEARCH_QUERY' in the SPARQL query, below, with search text in the XForms input. Then it sends an XForms submission with the following action: http://vocab.getty.edu/sparql?query={encode-for-uri(instance('sparqlQuery'))}&format=xml.

SELECT ?c ?label WHERE {
?c rdf:type gvp:Concept .
?c skos:prefLabel ?label
FILTER langMatches(lang(?label), "en") .
FILTER regex(?label, "SEARCH_QUERY", "i") .
}
ORDER BY ASC(?label)
LIMIT 25 

Assume that the query above includes the necessary SKOS and GVP prefixes. The options in the select box in the user interface are supplied by the SPARQL XML results.  You can see the code here.

What's it do?

Other than being an excellent controlled vocabulary source and universally recognized system of identifiers, incorporating Getty AAT ids into finding aids created with EADitor opens the door to the aggregation of content (in a useful way) in other large systems.

EADitor's flickr integration enables the injection of Getty-based machine tags into photo metadata.  AAT URIs are treated as dcterms:format in RDF serializations.  While the Digital Public Library of America doesn't yet make use of linked open data identifiers, it is on their agenda.  Therefore, finding aids which incorporate AAT identifiers, in addition to VIAF, Geonames, and LCSH ids will be among the most useful to researchers, since these are the most easily categorized and filtered in a large information system, such as DPLA.

Improving Date Functionality

The default EAD templates  in EADitor have been updated to require the @normal attribute for the encoding of dates, and I have finally gotten around to improving the interface for entering in standard ISO-compliant dates (and automatically generating human-readable text).  This will ultimately improve the finding aids created in EADitor by making contents sortable by creation date.

When inserting a date or unit date anywhere in the document, the user may select the Date or Date Range radio button to display the associated data inputs.  These values (and the machine-generated human readable text) are not inserted into the finding aid until they are valid.  So therefore, the Date, From Date, and To Date must conform to the xs:date (yyyy-mm-dd), xs:gYearMonth (yyyy-mm) or xs:gYear (yyyy) formats.  Furthermore, the To Date must be a greater value than the From Date.  This is a small step, but it should have a great impact on the usefulness of the data with respect to querying.

Maintaining Relationships in EAC-CPF with xEAC

As I mentioned in my recent presentation at MARAC, the most challenging aspect of developing a system for creating and maintaining EAC-CPF records lies in linking identities together and managing these relationships.  I have made some progress in this regard in the two weeks leading up to MARAC.  I introduced two template blocks into xEAC's config.xml, one which binds to the @xlink:arcrole in CPF (corporate, personal, family) relations, the other which binds to @xlink:arcrole in resource relations.  The nature of these two types of relationships differs.  CPF relationships tend to be reciprocal while resources are one directional.  The xEAC Settings page now allows you to set the inverse of a relationship, e.g., parentOf is inverse of childOf, and the update workflow in the EAC editor will keep linked records up to date with the appropriate relationship.

If you go to the Semantic Relationships tag on the Settings page, you can begin by importing all of the distinct arcrole attributes found in the EAC-CPF collection into the appropriate tables.  You may then add new relationship types and select the inverse from the drop down menu.  Furthermore, since the xlink:arcrole may contain the xs:anyURI data type, you may define your own namespace, employing a customized relationship ontology.  You could even employ existing ontologies, such as http://vocab.org/relationship (which will come pre-populated in the xEAC config in the next beta).

 

If you use a prefix in your relationships, you are required to define the URI.  The prefix and URI will be stored as an abbreviation and citation in a localTypeDeclaration inserted into your EAC-CPF records.  CPF relations with arcroles under a bound prefix will be pulled into RDF.

See this extremely rudimentary, beta RDF output which says that Alexander the Great is childOf Philip II:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
 xmlns:skos="http://www.w3.org/2004/02/skos/core#"
 xmlns:foaf="http://xmlns.com/foaf/spec/#"
 xmlns:arch="http://purl.org/archival/vocab/arch#">
 <foaf:Person rdf:about="http://admin.numismatics.org/xeac/id/alexander_the_great">
  <skos:altLabel>Alexander the Great</skos:altLabel>
  <skos:altLabel xml:lang="pt">Alexandre, o Grande</skos:altLabel>
  <skos:altLabel xml:lang="fr">Alexandre le Grand</skos:altLabel>
  <skos:altLabel xml:lang="sv">Alexander den store</skos:altLabel>
  <skos:altLabel xml:lang="ja">アレクサンドロス3世</skos:altLabel>
  <skos:altLabel xml:lang="pl">Aleksander Macedoński</skos:altLabel>
  <skos:altLabel xml:lang="zh">亚历山大大帝</skos:altLabel>
  <skos:altLabel xml:lang="ru">Александр Македонский</skos:altLabel>
  <skos:altLabel xml:lang="it">Alessandro Magno</skos:altLabel>
  <skos:prefLabel xml:lang="en">Alexander the Great</skos:prefLabel>
  <skos:altLabel xml:lang="nl">Alexander de Grote</skos:altLabel>
  <skos:altLabel xml:lang="de">Alexander der Große</skos:altLabel>
  <skos:altLabel xml:lang="es">Alejandro Magno</skos:altLabel>
  <skos:related rdf:resource="http://dbpedia.org/resource/Alexander_the_Great"/>
  <my:childOf xmlns:my="http://example.org/my#"
   rdf:resource="http://admin.numismatics.org/xeac/id/philip_ii_of_macedon"/>
 </foaf:Person>
</rdf:RDF>

 After setting up these relationships, the @xlink:arcrole will be bound to the values in the config template, with values controlled by a drop-down menu.

 

The system handles creations and deletions of relationships, but does not yet handle changes, so there is still work to be done in this area, plus scalability testing.

MARAC Fall 2013 Presentation

I presented last weekend on xEAC at MARAC in Philadelphia, following about two weeks of furious development following the official re-releases of MANTIS and OCRE.  I will discuss the latest changes in xEAC in greater detail in another blog post, but the introduction of relationship ontologies and updating reciprocal relationships automatically are the main advancements.

Building Interlinked Prosopographies: A New Approach from ewg118