I pushed into production a new SPARQL-based social network graph feature in xEAC. The most interesting places to start are http://numismatics.org/authority/newell and http://numismatics.org/authority/new_york_numismatic_club, but we have a lot of work to do to enhance the linkage between our authorities in order to make these visualizations more useful in the future.
Nearly a year ago, I began implementing a new EAC-CPF to RDF data model that could represent a graph of relationships in order to begin experimenting with rendering a social network graph in real time. After investigating the open source Javascript graph visualization tools, I choose vis.js, as it was powerful, easy to use, and could load JSON on the fly. I got a very basic graph working a year ago in time for Moving People, Linking Lives at the University of Virginia, but it wasn't interactive, in that you could not expand beyond the first level of nodes connected to the authority record you were immediately viewing.
After launching our first EBook a few weeks ago in ETDPub (which is integrated with our production installation of xEAC), I decided to revisit xEAC development of the social network graph interface.
The Concept object is connected to the Thing object with foaf:focus.
The Thing object contains mainly biographical information, using the bio ontology. While much work remains to be done to link individuals to events, basic birth and death dates are represented, as well as a string of bio:relationships. Each bio:Relationship object contains a property defining the nature of the relationship and the target entity of the relationship. I will probably revisit the properties by which people are linked to organizations (using the org ontology more properly), but the model does function well enough to generate a graph of relationships.
Essentially, we get all of the relationships connected to a particular entity (URI), the type of relationship (e.g., rel:spouseOf), and the target entity, whether another URI in the system or a blank node. The SPARQL response is processed and serialized into JSON. When clicking on connecting nodes in the graph visualization--if the target node is not a blank node RDF object (therefore, another authority in xEAC)--vis.js fires off another Ajax call to create new nodes and edges. Arrows in the graph visualization indicate the directionality of the relationship.
I should say that this is just the first phase of social network graph visualization in xEAC. While I have focused mainly on visualizing relationships on the level of the individual authority, my goal is to expand the application to implement a more sophisticated query interface that allows users to select arbitrary parameters to generate their own visualizations. For example, a user may want to view all persons grouped together by family or corporate body. Or group people by occupation or filter by date or place. All of these things are possible by reconceptualizing EAC-CPF into RDF graphs and developing the SPARQL queries that can be rendered into JSON for vis.js.
Nearly a year ago, I began implementing a new EAC-CPF to RDF data model that could represent a graph of relationships in order to begin experimenting with rendering a social network graph in real time. After investigating the open source Javascript graph visualization tools, I choose vis.js, as it was powerful, easy to use, and could load JSON on the fly. I got a very basic graph working a year ago in time for Moving People, Linking Lives at the University of Virginia, but it wasn't interactive, in that you could not expand beyond the first level of nodes connected to the authority record you were immediately viewing.
After launching our first EBook a few weeks ago in ETDPub (which is integrated with our production installation of xEAC), I decided to revisit xEAC development of the social network graph interface.
The Model
The RDF model implements bits and pieces of various standard ontologies. People, corporate bodies, and families have separate URIs for their entity represented as a Concept and as a Thing. The Concept (skos:Concept) of a person can be linked to concepts of that person in other vocabulary systems, like the Getty ULAN, VIAF, Wikidata, or SNAC. This is also the data object where you may also include provenance about the creation and modification of the object record. For example, dcterms:created applied for a foaf:Person would imply that the person was born on the given date, but when used in a skos:Concept, this implies that the concept data object would have been created in the data system at the given date.The Concept object is connected to the Thing object with foaf:focus.
The Thing object contains mainly biographical information, using the bio ontology. While much work remains to be done to link individuals to events, basic birth and death dates are represented, as well as a string of bio:relationships. Each bio:Relationship object contains a property defining the nature of the relationship and the target entity of the relationship. I will probably revisit the properties by which people are linked to organizations (using the org ontology more properly), but the model does function well enough to generate a graph of relationships.
SPARQL to Vis.js JSON
Vis.js renders two JSON models, one for nodes and the other for edges, into a visual graph following HTML5 standards. Essentially, I had to build two web services in xEAC that would deliver these JSON models that could be read in real time via Ajax. The underlying model for these services is the SPARQL query, and the views are generated with two different XSLT stylesheets to generate the JSON that vis.js requires to render the graph. The query is this:SELECT ?sourceName ?type ?target ?name ?class WHERE {<URI> foaf:name ?sourceName ; bio:relationship ?rel . ?rel xeac:relationshipType ?type ; bio:participant ?target . ?target foaf:name ?name ; a ?class }
Essentially, we get all of the relationships connected to a particular entity (URI), the type of relationship (e.g., rel:spouseOf), and the target entity, whether another URI in the system or a blank node. The SPARQL response is processed and serialized into JSON. When clicking on connecting nodes in the graph visualization--if the target node is not a blank node RDF object (therefore, another authority in xEAC)--vis.js fires off another Ajax call to create new nodes and edges. Arrows in the graph visualization indicate the directionality of the relationship.
I should say that this is just the first phase of social network graph visualization in xEAC. While I have focused mainly on visualizing relationships on the level of the individual authority, my goal is to expand the application to implement a more sophisticated query interface that allows users to select arbitrary parameters to generate their own visualizations. For example, a user may want to view all persons grouped together by family or corporate body. Or group people by occupation or filter by date or place. All of these things are possible by reconceptualizing EAC-CPF into RDF graphs and developing the SPARQL queries that can be rendered into JSON for vis.js.