Two exciting projects I've been recently working on at Mediamatic Lab are two highly connected sites around the Jewish Community in the Netherlands during World War Ⅱ. The first is one of the oldest sites we have made, the Digital Monument. This site contains verified information on all of the Dutch jews that have died during WWⅡ along with their households, documented posessions and known documents and pictures. It is maintained by a team of editors of the Jewish Historical Museum.
The second is a brand new community site, to complement the Monument by allowing anyone to add new information, pictures and stories on people at the Monument.
The Monument is very impressive, as I learned back at the first BarCamp Amsterdam, hosted by Mediamatic. You will know what I mean if you spend a little as five minutes paging through the site. Today, however, I want to talk about the technology behind both sites.
Data Model Changes
The data in the Monument is highly semantic in nature. People are part of households, as head-of-family, spouse, son or daughter. Or some other relation. Households have a location and lists of possessions. Tied to all of these are supporting documents and pictures. In anyMeta, all of these are modeled as things with edges between them with a certain predicate. A typical household would be modelled like this:
For the community site, however, we wanted to have more direct relationships between people: parent-child relations, sibling relations, partner relations and a more generic (extended) family relationship. As the community also has most things of the monument imported, this meant a change in the data model and a subsequent conversion in the monument.
In anyMeta, (almost) everything is a thing. As such, the predicate on an edge between two things is also represented by a thing. This has traditionally been named role. Like all things in an anyMeta site have a resource URI, the resource URI of a role is the predicate's URI. We try to use existing (RDF) vocabularies as much as possible for this.
For relationships between people, we've used the
used in FOAF. So this was the first place to look for the desired new
predicates. However, this vocabulary does not have a property for
expressing a generic extended family relationship. Fortunately,
XFN has the
kin relationship type, along with
Richard Cyganiak described how to express XFN relations in
RDF, so we used that to base our predicates on.
Like RELATIONSHIP, most of the XFN properties are subproperties
foaf:knows property, and have some
hierarchy themselves, too. In anyMeta, we didn't have the concept of
subproperties, yet, so we added a new role for expressing subproperty
relationships between roles, and introduced the concept of
implicit edges. These are edges with a
superpredicate of the explicit edge that is being created. For
xfn:child property is a subproperty
foaf:knows. Whenever an edge between two people
gets created with the child role, another implicit one with the knows
role is added, too.
After conversion and with the implicit edges present, the new data model of the example above looks like this:
The blue arrows are the new, derived edges. A spouse edge is made between those people that respectively have a head-of-family and partner relation to the same household (this can be assumed to be correct for this dataset). For person that have a son or daugther edge to a household, a child edge is made from the head-of-family and partner persons (if any) in that household to this person. We haven't (yet) added derived sibling edges, as this relation depends on the parents of both persons, too.
You can also see gray, dashed edges. These are the implicit edges that follow from the property hierarchy. Another thing to notice, is that the biographies are gone. We put the texts in there directly on the persons and households, instead.
Besides the regular pages of all people, households and other things, you can also use our semantic browser to look at the relationships between things. For example, Mozes and his family can be browsed from here.