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).
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.
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.
