CIDOC CRM v4.2.1

CIDOC CRM v4.2.1 (domain_administrator)

The CIDOC CRM freebase 'domain' is a mapping of the 'CIDOC Conceptual Reference Model (CRM) version 4.2.1', which provides an extensible ontology for concepts and information in cultural heritage and museum documentation. It has been standardized und as ISO 21127:2006. It was created by an international group of specialists using collective common sense. It is applied to a growing number of real data sets.

The CIDOC CRM is provided here in order to map it to the freebase data model. The mission target is to merge the 'CIDOC CRM entities' with the aequivalent types and properties in freebase. This should simplify the import of a wide range of cultural heritage data. In addition freebase can function as a credible scholarly reference tool (see below).

'CIDOC CRM entities' and 'CIDOC CRM properties' are mapped as freebase 'types'. Each CIDOC CRM 'property' is represented as a Freebase 'compound value type' (i.e. a class or a node) with two Freebase properties for 'CIDOC CRM Entity Domain' and 'CIDOC CRM Entity Range'. This allows for the representation of the 'CIDOC CRM Property Hierarchy' and a subsequent annotation of each single link.
If this mapping results in a (temporary) downside, concerning data entry and vizualisation, remains to be seen. Please read further down for some reasons, justifying the current mapping. The alternative would have been to represent 'CIDOC CRM properties' as simple 'Freebase properties'. Consequently it would not have been possible, to represent the 'CIDOC CRM Property Hierarchy' as intended by the CRM. Most important the alternative mapping would make it impossible to annotate single links, given the current (Sept. 2007) definition of the freebase data model.

The annotation of single links, which is made possible by representing 'CIDOC CRM Properties' as 'freebase types', is important in a scholarly environment dealing with disparate sets of data. An example would be the link from an 'Architect' to his or her built 'structures'. In a simple definiton, as currently found in freebase, a building like the 'Pantheon' has to be connected directly to the supposed architects ('Apollodorus of Damascus' and/or 'Hadrian'), which is wrong according to the standards of good scholarship. Each of the two attributions is an opinion, which is based on specific documents or at least on a scholarly discussion. In order to make the link credible we have to annotate it with it's sources of opinion. By representing 'CIDOC CRM properties', just like 'CIDOC CRM entities', as freebase types, we can annotate them accordingly by linking them to their proper sources of opinion. In addition to the CIDOC CRM specification, each topic (i.e. 'CIDOC CRM entities and properties') will therefore bear a link to it's 'document(s)' and it's 'data source'. The 'data source' could be a museum or another publisher, which delivers data according to the CIDOC CRM standard to freebase. The 'document(s)'-link could for e.g. point to a scholarly publication.
As a consequence freebase can function as a scholarly reference tool, including both, credible and not so credible information. The more topics and links (i.e. compound value types) are annotated, the more credible freebase will be and the further back we can trace the sources of opinion.

Furthermore there are two other advantages of this proposed mapping of the CIDOC CRM:
First the sources of information can be preserved in the process of normalization (The two links 'Article1 says the architect of the Pantheon is Hadrian' and 'Article2 says the architect of the Pantheon is Hadrian' can be normalized as 'Article1 and Article2 say the architect of the Pantheon is Hadrian' without losing information of who says what, for e.g. 'Article3 says the architect of the Pantheon is Apollodorus').
Secondly the mapping should facilitate (network) data analysis, as it is easy to export edgesets from a result of nodes ('CIDOC CRM property' types).

ATTENTION: The Mapping is not yet complete.

The following steps are to do:
1. Definition of 'CIDOC CRM entity' types (finished)
2. Setting up the 'CIDOC CRM Class Hierarchy' (finished)
3. Definition of 'CIDOC CRM property' types (in progress)
4. Setting up the 'CIDOC CRM Property Hierarchy (todo)
5. Defining 'CIDOC CRM Entity Domains and Ranges' (todo)
6. Adding CIDOC CRM Documentation to types and properties (todo)
7. Adding 'document(s)' and 'data source' property to CIDOC CRM types (todo)
8. Documenting an import procedure for CIDOC CRM Instances including 'data source' information.

Once the mapping is complete the following steps can be made:
1. Merging the CIDOC CRM types to aequivalent freebase types.
2. Importing CIDOC CRM instances into freebase.

For more information on the 'CIDOC Conceptual Reference Model (CRM)' see the respective freebase topic or the project's homepage cidoc.ics.forth.gr/.

This implementation of was presented in the following talk:
Implementing the CIDOC CRM in Metaweb's Freebase.com. Presentation at 15th FRBR - CIDOC CRM Harmonization meeting, Germanisches Nationalmuseum, Nürnberg, December 4-7, 2007