Ontology Design

This section presents existing ontologies or data models relating to cultural heritages, the strategy for the ontology design, and the design itself - including node labels, node properties, relationship labels, relationship properties, and relationships.

Existing Heritage Ontologies

Other scholars and institutions have previously created ontologies for cultural heritage information, some of which are applicable to a graph database. As mentioned by Doerr (2009), the main ontologies dealing with cultural heritages are the CIDOC Conceptual Reference Model (CIDOC-CRM), Functional Requirements for Bibliographic Records (FRBR), ABC, DOLCE, as well as the Europeana Data Model (EDM) (not mentioned by Doerr as it was released in 2013). These data models were designed with a variety of purposes in mind – some more conceptual and broad, like the CIDOC-CRM, which is closer to an ontology than a practical data model, or the FRBR, which facilitates documentation of a variety artistic and literary works, while others are more functional and specific, like the EDM, which was designed specifically for documentation of items in the Europeana collections.

There have also been explorations of ontologies or data models about Korean cultural heritages, in particular using the models referenced above as a framework, including the work of Kang (2016), Kim (2016), Kim et al (2013), Kim et al (2016), Lee et al (2014), Seo (2014), and kadhlab103 (2017). However, none of these have been geared directly toward an end-goal of facilitating interpretation or the generation of interpretive resources.

Related to cultural heritage graph database models are databases which depict the relationships of historical figures in Asia (such as the China Biographical Database and Wagner-Song Munkwa Project). While these databases are not about cultural heritages, historical figures play a key role as contextual elements of cultural heritage interpretive information, and therefore, these databases could become meaningful resources for data on historical figures and their relationships to one another.

All of these ontologies and data models were designed with the objective of describing cultural heritage-related information. However, their scopes and objectives differ. Many of the ontologies or data models were designed from the perspective of managing institutions, and, as such, are designed for experts who already know what they are looking for (Stiller 2013) and focus on providing metadata information on the heritages themselves, rather than as a way to describe the relationships between heritages and their greater contexts. Some of them have very specific scopes that cannot describe the broad range of cultural heritage information. The CIDOC-CRM does attempt to facilitate a broad description of cultural heritage contexts, but it is too abstract and broad, and not practically applicable to Korean cultural heritage interpretation. Furthermore, none of the existing ontologies are optimized for future use in interpretive resources (in other words, data stored via these ontologies could not be reutilized in various interpretive interfaces, such as an automatically generated, personalized interpretive text). These various limitations of existing ontologies when it comes to the description of Korean cultural heritage interpretive information necessitate the development of a new ontology, designed to convey Korean cultural heritage information in particular, and optimized for future use in various interpretive resource interfaces.

Ontology Scope

This ontology was developed based on a review of the content of the interpretive texts of on-site cultural heritages were translated by the Academy of Korean Studies Korean Cultural Heritage English Interpretive Text Compilation Research Team between fall 2015 and spring 2017 (as discussed in section III.4). The various potential contextual elements, as well as their relationships to the heritage and one another, were extracted from the texts. These were then reviewed and organized, and this has been presented as the following ontology. These texts cover over 130 heritages of 27 different types, thus providing a diverse range of cultural heritage information which reflects the diversity of on-site cultural heritages and their contexts at large.

Design Strategy

This ontology is designed to be applicable to a labeled property graph, such as that facilitated by Neo4J, due to the benefit of being able to more fully incorporate labels and properties of relationships, which is not possible in RDF/OWL ontologies. As mentioned in the previous section, the utilization of a database – a graph database, in particular – in and of itself has the potential to address many limitations of current heritage interpretation practices in regard to the five ideals of heritage interpretation. However, this ontology attempts to take these ideals into particular consideration, while also improving on existing shortcomings in Korean cultural heritage interpretative resources, in the following ways as demonstrated in the following table.

Table 16 Summary of the ontology's features

Interpretive Ideal	This Ontology's Features
Clear / Accurate	Transparency of information sources, creators, and editors Maximum reutilization of nodes so there is less need for data input and translation, which means fewer typos and easier proofing/consensus on information Contextual elements and relationships are clearly defined which minimizes vagueness, and these can later be displayed in timelines, diagrams, etc.
Personal / Tailored	Options for selection of the kind of content displayed Options for the quantity (i.e. length, depth) of information to be displayed Options for language display, measurement units, calendars (including mixed display) Options for inclusion of additional helpful information for those with less background information, such as definitions of terms Data can be displayed as a network graph or in a table; Can be displayed in the future in a countless variety of forms when interfaces are developed (timelines, diagrams, automated texts, games, virtual or augmented reality, etc.)
Contextualized / Holistic	Includes information not just on cultural heritages, but on their contextual elements and the relationships among contextual elements, as well (people to people, concepts to concepts, etc.) Can approach information on any kind of heritage contextual element (not just heritages) from any starting point (concept, historical figure, event, year, dimension, color, value, etc.)
Facilitates Engagement	Inclusion of “engagement” relationships between contextual elements and various related digital resources, events, and other materials to make users aware of opportunities for more in-depth, self-directed learning on areas of interest Content from the database can be selected (i.e. someone can do “storytelling”) in one language and that content can be displayed automatically in another language even if the original “storyteller” does not know that language, which has potential for more in-depth learning opportunities for non-Korean audiences
Sustainable / Innovative	Minimization of redundant information input, explanation, and translation which saves time, effort and money and allows for more focus on enriching the database by adding new nodes and relation, or adding more source citations or engagement opportunities, or improving the translations/definitions of existing nodes The same data can be used over and over again in multiple interfaces, which can be developed and improved on separate from the “content” itself Because it is digital, it can be continually updated and accessed from all over the world, and can always be turned into analog form (developed into interpretive texts or brochures, etc.) if needed

These various features were achieved by taking the following approaches to the ontology design:

1. Minimization of node properties in favor of relationships with other nodes: In the existing CHA metadata, for example, the time period of a particular heritage is stored as text. This means that for each heritage, the name of the time period has to be re-inputted by hand. This increases the likelihood of errors and inconsistencies, and increases work - including repetitive translation of the term. However, if a heritage is just connected to the time period via a relationship, the information (including translation) about that time period does not need to be re-inputted again and again. Included in this are measurements, dates, and addresses, for example, which are all their own nodes rather than as properties. This minimizes redundant translation work and facilitates personalization of display and visualization.
2. Utilization of node IDs in relationship properties to convey more detailed information about the relationship:*Unlike nodes, relationships cannot have relationships to nodes. Therefore, if additional information about a relationship is needed, this needs to be included as a property. By utilizing the IDs of other nodes in the relationship properties, such the node along with its properties can be accessed and reutilized in an explanation of a relationship, while the number of total relationships in total is minimized. This minimizes graph clutter and redundant information input, and while facilitating richer detail of relationships.
3. Minimization of event nodes in favor of relationships with properties: In CIDOC-CRM event nodes are used for even relatively simple actions. However, this makes the path between nodes unnecessarily long. This ontology uses relationship properties to convey additional information about relatively simple actions (such as re-tiling, renovation, etc.), and only includes complicated events with many actors and sub-events in the event label (such as a war or political event). This minimizes redundant translation work and shortens the path between related nodes.
4. No separate label for cultural heritages:Although this database is designed around Korean cultural heritages, cultural heritages are not given their own label. This is because they are not fundamentally different from other tangible objects. However, their status as a CHA-designated cultural heritage is trackable via designation relationships which connect a tangible object to its heritage designation, if it has one.
5. Facilitation of multi-language (measurement, calendar system) display via node properties:Included in node properties are various languages (Korean, English, and Chinese characters), measurement systems (metric or imperial), and calendar systems (solar, lunar, and reign years) to allow for searching and display of information in diverse ways suited to the needs of the user. With measurements and dates/years stored as nodes themselves, this minimizes redundant translation work of simple things like dates and measurements. This also allows for one user to search for and present information in a particular language (or measurement/dating system), and display it in another, even if they do not know that language themselves. Simple definitions of difficult terminology are also included as properties to allow users with less background knowledge to understand the terminology.
6. Inclusion of objective and subjective value judgments (such as oldest, first), quality judgments (such as refined, grandiose):The reason cultural heritage become cultural heritages is that experts deem they have some particular value which warrants preservation. However, often these claims are not clearly conveyed in current interpretive texts, or they are subjective (such as saying a painting is “refined” without any specific reason for such a claim or any clear definition of what “refined” means). By including value judgment in the ontology, heritages which have similar value will be able to be searched for. In addition, we will be able to see how often heritages are described with vague or baseless subjective descriptions, so that we can research more specific and meaningful ways to express the subjective value of heritages and minimize unhelpful filler words all so common in current interpretive texts.
7. Tangible object parts described as nodes: It is useful to have parts of heritages – such as the rooms of a building or the various body parts of a Buddhist statue – as their own nodes so they, too, can have type and quality relationships which can be compared to other similar heritage parts and so that users can search/browse for heritages via the characteristics of its parts.
8. “Meta” labels for transparency of data and data management:Meta labels for relationships, as well as a user label for nodes, allows for information on the creation, translation, editing, and source citation for information within node properties and relationships to be included in the database, but also easily excluded from search results if necessary. This allows for searching for relationships which do not have any cited evidence and may be less reliable. There is also a relationship property, “veracity,” which can identify “presumed” relationships which do not have any specific source (such as guesses about the time period of a heritage). This addresses current problems of lack of responsibility and oversight for information and translation in interpretive texts and gives users the power to judge the evidence behind claims.
9. Inclusion of resources for further engagement via an “engage” relationship label: In order to facilitate user's discovery of further reading and educational opportunities related to heritages, an “engage” relationship label was included so that users can easily access to further information about the heritages, concepts, historical figures, places, etc., in which they are interested.

These features will be explained in greater detail in the following section on the ontology design itself and via the ontology examples in section VII.

Design

This section outlines the ontology design itself, including node labels and properties, relationship labels and properties, as well as the relationship types themselves. In other graph database frameworks such as RDF/OWL, nodes are referred to as entities or individuals, labels are referred to as classes, node properties are referred to as attributes or datatype properties, and relations are referred to as object properties. However, since the ontology presented here is implemented via a labeled property graph as presented in Robinson et al (2005), the terminology of labeled property graphs will be used instead of RDF/OWL terminology.

Node Labels

The node label design took inspiration from the classes of the CIDOC-CRM. However, the CIDOC-CRM is more complex than is needed to convey interpretive information, and furthermore, its event-based perspective is unconducive to providing content in multiple languages. More simple ontologies which use just actor, event, place, object, and concept are intuitive and can be used broadly for many purposes, but lack systematic rational and nuance, failing to take into consideration the differing node properties and relationships for the kinds of entities which would fall into those labels (for instance, person, institution, and group, are all “actors,” but would each have very different attributes and relations). Therefore, the ontology presented here strives to find a middle point on this spectrum, such that the ontology is not too specific that a wide variety of users can use it to various objectives, but also not so general that nodes with different property and relational needs are grouped together.

The ontology proposed here has six main labels: tangible object, intangible object, person, concept, digital resource and value. These labels were determined based on the ideas of tangibility and whether or not it can have more than one existence. For example, tangible object and person are tangible, digital resource is digital, and intangible object, concept, and value are intangible. Tangible object, person, intangible object, and value can only have once instance, while concept and digital resource can have multiple instances. Value and concept were differentiated because the definition of value is permanent, while concepts can change meaning over time. Person was differentiated from tangible object, partially on the basis of being alive (although in this case, plants and animals would also need to be differentiated from tangible objects), but mostly out of usefulness for the user.

Table 17 Rationale for node label design

Label	Tangibility	Instances	Notes
Tangible Object	Tangible	1
Intangible Object	Intangible	1
Person	Tangible	1	Living/Useful to differentiate
Concept	Intangible	1+	Changing definition
Value	Intangible	1+	Permanent definition
Digital Resource	Digital	1+

In addition to these six main labels are 22 sub-labels, making 28 labels in total, as shown in the visualization below. These labels, their super-labels, and their definitions outlined in the table which follows.

Interactive version of the ontology design graph

Table 18 Node labels

Super-label	Label	Definition	Examples
-	Concept	an entity with a definition that can be applied to many instances of other nodes	Confucianism, maintenance
-	Digital Resource	an entity that exists in digital form and are referents to other entities	See below
-	Intangible Object	an entity that has a singular manifestation, but which is not physical	See below
-	Person	an individual human being	Sin Suk-ju
-	Tangible Object	an entity that has a singular, tangible manifestation, and that is not a human	See below
-	Value	an entity that is singular, can be used to describe multiple entities, and has a single interpretation	See below
Value	Address	a specific geo-spatial location that can be described by a single GIS coordinate pair or a street address	323 Haogae-ro Bundang-gu Seongnam-si, Gyeonggi-do; 37.391792, 127.054396
Value	Name	an entity that is a simple string that refers to a name (pen names, posthumous names, re-naming of buildings, etc.)	Hyewon, Jiseonjeong,
Value	Date	an individual day	17-May-17
Value	Measurement	an entity used to express dimensions	2 feet, 2 meters, 200 centimeters, 4 kan by 2 kan
Concept	Descriptive Concept	an entity which describes the quality or nature of another entity (i.e. adjectives)	Simple, ornate, strong, refined
Concept	Typal Concept	an entity which can describe the form or type of other entities	Men's quarters, three-story stone pagoda, portrait
Digital Resource	Primary Resource	a digital media entity in their direct form (i.e. the file itself, .jpg, .mp3, etc.)	Sinsukjuchosang.jpg
Digital Resource	Secondary Resource	a compilation of digital media (web page, database, etc.)	CHA Cultural Heritage Digital Hub
Intangible Object	Event	an entity comprised of various actions by various actors that occurs over a period of time	Imjin War, the Battle of Cheongju; the Civil Service Exam of 1492, the Independence Movement
Intangible Object	Institution	an entity which is popularly or legally recognized and has agency, but which need not necessarily have physical manifestation	Joseon, the Academy of Korean Studies, the Empire of Japan, the Korean army
Intangible Object	Linguistic Object	an entity composed of linguistic content; not the physical or auditory manifestation of the content, but the content itself	The text of the Gwanggaeto Stele; the content of the Jikji
Intangible Object	Spatial Object	an entity with geographic coordinates, either a specific location or a range of land/sea/space	Unjung-dong, the site of Heungdeoksa Temple
Intangible Object	Temporal Object	an entity which is a span of time with a start and end	The early Joseon period, the turn of the 20th century, the 15th century
Person	Group	a group of people	Goryeong Sin Clan, the four civilian military commanders of the Imjin War; the kings of Joseon
Person	User	a user of the database	user101
Temporal Object	Year/Month	a month or year	2017, May 2017
Tangible Object	Collection	an entity which is a group of multiple tangible entities	A traditional Korean house (with multiple quarters), a temple, a group of Buddhist statues
Tangible Object	Part	an entity which is a section of a tangible object which, while can be described in isolation, cannot exist apart from the tangible object	The head of a particular Buddha statue, and roof brackets of a particular wooden structure
Measurement	Length	a measurement entity for height, width, depth, diameter, and circumference	12 cm
Measurement	Weight	a measurement entity for weight	12 kg
Measurement	Area	a measurement entity for area	12 sq meters
Measurement	Unit	a measurement entity for miscellaneous units, such as “kan”	4 (kan)

As mentioned in the previous section, an effort was made to facilitate the node-ification of items typically stored as properties, such as appellations, dates, addresses, and dimensions. This allows for equivalent information to be conveyed via multiple languages, calendar systems, measurement systems, etc. Furthermore, address and spatial objects, as well as date and temporal object, were differentiated rather than grouped as “place” or “period.” This is because addresses and dates are permanent, while spatial and temporal objects can change over time. Furthermore, events and temporal objects were distinguished from one another in that events must involve various actors engaging in a variety of connected actions, while a temporal object can be just a general period of time.

Node Properties

As explained in the section on design strategy, node properties were minimized in favor of more discrete nodes which are connected to via relationships whenever possible to minimize redundant translations and other data input. Therefore, the node properties were limited to the following as shown in the table below.

Table 19 Node properties

Domain Node Labels	Property	Data Type	Description
address	GIS_lat	gis	latitude and longitude coordinates
address	GIS_lon	gis	latitude and longitude coordinates
ALL	ID	string	id
ALL (except measurement, date)	kr	string	main node name in Korean
ALL (except measurement, date)	en	string	main node name in English (translation)
ALL (except measurement, date, year/month, address)	ch	string	main node name in Chinese (hanmun)
ALL (except measurement, date, year/month, address)	rr	string	main node name in Revised Romanization
ALL (except measurement, date, year/month, address)	mr	string	main node name in McCune-Reischauer
ALL (except value, year/month)	URI	string	link to a webpage describing the node
ALL (except measurement, date, year/month, address)	def_kr	string	definition, summary, explanation in Korean
ALL (except measurement, date, year/month, address)	def_en	string	definition, summary, explanation in English
linguistic object	def_ch	string	the original Chinese character text of a linguistic object
date	date_sol	date	date in the solar calendar
date	date_lun	date	date in the lunar calendar
length	cm	number	centimeter
length	in	number	inch
weight	kg	number	kilograms
weight	lbs	number	pounds
area	sqm	number	square meters
area	sqft	number	square feet
area	pyeong	number	Korean pyeong
unit	no	number	a simple number to describe other units
year/month	reign_kr	string	Korean reign year in Korean
year/month	reign_en	string	Korean reign year in English
year/month	reign_ch	string	Korean reign year in Chinese (hanmun)
digital resources	source	string	ID of the institution or individual from which a resource was taken
secondary resources, linguistic objects	lang	string	the language of a secondary digital resource or linguistic object

Some limitations of these node properties are that there can be only one main title for each language. For example, the primary name that will show when the node is displayed in Korean or English will need to be decided. For example, “pagoda body” is referred to by many names in Korean, while events such as “Imjinwaeran” are translated variously in English as the 'Japanese Invasions of Korea,' the 'Imjin War,' etc. Which term appears as the primary title of the node in each language should be determined based on research of 1) how it has been most commonly referred to or translated as, and 2) what is easiest for most audiences to understand. However, all equivalent terms or translations can be saved as appellation nodes, which allows for users to search for and find the nodes via these alternate names.

Relationship Labels

Relationships were also given labels. These were based on the kind of relationships found within on-site interpretive texts, as well as the property needs of each relationship type. There are 15 labels as follows. Including these relationship labels will be helpful later when users want to find specific kinds of relationships among the many relationships; For instance users can sort for information about the value of the heritage, the history of the heritage, the history of related historical figures and events, related concepts, the various elements of the heritage and their artistic qualities, related multimedia or reference materials, etc., depending on their areas of interest.

Table 20 Relationship labels

Label	Definition	Domain Node Labels	Range Node Labels
action	actions done by humans	Person, Institution	Person, Tangible Object, Intangible Object (the direct object)
address	the specific GIS coordinates of an object	Tangible Object, Spatial Object	Address
des	information about cultural heritage designations	Tangible Object, Intangible Object	Date, Spatial Object, Typal Concept
dim	connect dimensions	Tangible Object	Measurement
end	ends (death, destruction)	Person, Tangible Object	Date, Temporal Object
layout	directional/spatial relations of tangible objects or its location	Tangible Object, Spatial Object	Tangible Object, Spatial Object
meta	information about creation, editing	ALL	User, Date
name	relations to appellations	ALL (except value)	Appellation
occur	relationships between temporal events	Temporal Object	Temporal Object
part	part and collection objects	Tangible Object, Intangible Object, Concept	Tangible Object, Intangible Object, Concept
rel	relations between people and groups	Person	Person
start	beginnings (birth, foundation, creation)	Person, Tangible Object	Date, Temporal Object
trans	transformations (repair, relocation)	Person, Tangible Object	Date, Temporal Object
type	classifications to explain what something is or describe it	Person, Tangible Object, Intangible Object	Concept
use	how something was used	Tangible Object, Intangible Object	Concept
value	cultural heritage value	Tangible Object, Intangible Object	Concept, Spatial Object, Person, Event
engage	connections to engagement opportunities	ALL (except value)	Digital Resource, Linguistic Object, Event

Relationship Properties

In addition to labels, relationships were given properties. Which properties a relationship has depends on the label it has, just like nodes. All relationships have some basic properties. These allow the relationships to be displayed in various languages and to identify the creator, creation date, and reference material of the relationship. However, relationships with action, start, end, transformation, value labels also have additional properties as follow. These utilize the IDs of other nodes which can be drawn upon to describe information about additional factors of the relationship – including when, where, why, and by whom it happened. Examples of how this feature can be used is explained in the next section.

Table 21 Relationship properties

Property	Domain	Definition	Example	Same As ID For
id	ALL	an id for each relationship	rel21023	another relationship
type	ALL	the relation code	Birth
en	ALL	the display name in English	was born on
kr	ALL	the display name in Korean	~에 태어났다
user	ALL	the ID of the user who created the relation	ID	User
date	ALL	the ID of the date on which the relation was created	20170518	Date
ref	ALL (except des)	the ID of the reference which supports the relation	ID	Digital Resource, Linguistic Object, Tangible Object
bc	action, end, start, trans, type, rel, name, dim, value	because; the rationale behind or cause of the relation	ID	Concept, Event
by	end, start, trans, name	actor; who was the actor who initiated or oversaw the start/end/trans	ID	Person, Group, Institution
on	action, name, des	time; when a specific date is known	ID	Date
in	action, end, start, trans, name, value	time; when a specific year/month is known	ID	Year/Month
before	action, end, start, trans, name	time; when an exact date is unknown, but it is known to have had happened before a certain date, event, or temporal object	ID	Date, Event, Temporal Object
after	action, end, start, trans, name	time; when an exact date is unknown, but it is known to have had happened after a certain date, event, or temporal object	ID	Date, Event, Temporal Object
during	action, end, start, trans, name	time; when an exact date is unknown, but it is known to have had happened during a certain event or temporal object (excluding year/month)	ID	Date, Event, Temporal Object (excluding Year/Month)
at	action, end, start, trans, des	location; the spatial object (like neighborhood) or tangible object (like building) in which the start/end/trans occurred	ID	Spatial Object, Tangible Object
nearby	action, end, start, trans	location; the spatial object (like neighborhood) or tangible object (like building) nearby where the start/end/trans occurred	ID	Spatial Object, Tangible Object
to	action, trans	location; the spatial object to which the trans occurred (i.e. where a building was relocated to, where a person was exiled to)	ID	Spatial Object, Tangible Object
from	action, trans	location; the spatial object from which the trans occurred (i.e. where a building was relocated from)	ID	Spatial Object, Tangible Object
with	action, end, start, trans	concurrence; when a trans occurred concurrently (like two buildings relocated together at the same time, two people who died together)	ID	Person, Group, Institution, Tangible Object, Concept, Intangible Object
attribute	meta	for identifying the attribute of the node which was edited	def_kr
veracity	ALL (except meta, des)	to denote if the relationship is just presumed	presumed
no	des	the designation number	56
start	action	time; start of an action	ID
end	action	time; end of an action	ID
for	action	whom or what the action is done for	ID

Relationships

The following is a list of the relationships and their inverses for the ontology. The relationship label determines the possible domains and ranges for the relationships, which can be found in the previous section on relationship labels.

Table 22 Relationship types and their inverses

Label	Relation	Inverse Relation
address	hasAddress	isAddressOf
des	hasDesignation	isDesignation
dim	circumference	isCircumference
	depth	isDepth
	height	isHeight
	kan_front	isKan_front
	kan_side	isKan_side
	volume	isVolume
	weight	isWeight
	width	isWidth
layout	Facing	Facing
	hasInMiddle	hasInMiddle
	ismade_TogetherWith	ismade_TogetherWith
	inEachDirection	inEachDirection
	intheMiddleOf	intheMiddleOf
	made_Separately	made_Separately
	isNearby	isNearby
	NextTo	NextTo
	Above	Below
	Behind	inFrontOf
	Between	hasBetween
	hasInEast	totheEastWithin
	hasInNorth	totheNorthWithin
	hasInSouth	totheSouthWithin
	hasInWest	totheWestWithin
	hasToEachSide	toEachSideOf
	isLeftPath	hasLeftPath
	In	Within
	Inside	Outside
	isLocatedTopOf	Underneath
	totheLeftOf	totheRightOf
meta	meta_created	meta_wasCreated
	meta_edited	meta_wasEdited
name	alt	isName_alt
	alt_en	isName_alt_en
	Courtesy	isName_courtesy
	Former	isName_former
	Pen	isName_pen
	Personal	isName_personal
	Posth	isName_posth
	Temple	isName_temple
	Name	isNameOf
occur	Concurrently	Concurrently
	After	Before
	During	hasContainedEvent
	hasRecurrentEvent	Recurrent
part	hasManifestation	isManifestationOf
	part	isPartOf
	part_missing	isMissingPartOf
	part_remnantof	isRemnantPartOf
	partlyremaining	isOnlyRemainingPartOf
ref	AcademicResource	isRefOf_AcademicResource
	Evidence	isRefOf_Evidence
	FurtherReading	isRefOf_FurtherReading
	hasRef	isRefOf
	Media	isRefOf_Media
rel	Colleague	Colleague
	Daughter	isDaughterOf
	isDescendant	isAncestor
	Father	isFatherOf
	Husband	isHusbandOf
	isMemberOf	hasMember
	isMemberOf_Clan	hasClanMember
	isFounderOf_Clan	hasClanFounder
	MatGrand	isMatGrandOf
	Mother	isMotherOf
	Owner	isPropertyOf
	Son	isSonOf
	Wife	isWifeOf
type	hasColor	isColor
	hasCondition	isCondition
	hasFormation	isFormation
	hasMaterial	isMaterial
	hasMethod	isMethod
	hasQuality	isQuality
	hasType	isTypeOf
use	hasUse_Main	isUse_Main
	hasUse_Secondary	isUse_Secondary
value	Best	hasBest
	Commemorates	isCommemorativeOf
	DocumentsHistoryOf	hasHistoryDocumentedBy
	Enshrines	isEnshrined
	hasBuried	isBuried
	hasCraftsmanship	hasExampleOfCraftmanship
	hasFirst	isFirst
	hasHistory	isHistoryOf
	hasIndicator	isIndicatedBy
	hasOldest	isOldest
	hasUncommonExample	uncommonFor
	hasValueAs	hasValuedExample
	hasWellKnownExample	wellKnownFor
	TypicalExampleOf	TypicalOf
	isRelatedTo	hasRelated
value, engage	aidsInTheUnderstandingOf	UnderstandingIsAidedBy
	Depicts	isDepictedIn

However, it was found that the potential relationships and inverses for action, start, end, and transformation relationships were more complicated than basic standard-inverse relationships. This is because the domain and range of the relationship can depend on the nature of the relationship. Therefore, there are four columns - active, passive, date, and place. Passive, date, and place can all be inverses of active. However, date and place can also be the inverse of passive as well. This depends on whether the relationship is centered around a human action, or a passive effect on a person or heritage object in which the actor of that effect is insignificant. For example, if a building is renovated, it is usually the date of renovation which is important, and who renovated it is secondary. In this case, the relationship would be between the heritage and the date via the “wasRenovated” relationship, and who renovated it would be stored as a property. However, there are also cases in which who did the action is more important than when it was done - for example, who created a piece of art. In this case, the relationship would be between the creator and creation, with the date saved as a property. This allows for flexibility in deciding which should be the target (range) of a particular relationship, but also may prove to be problematic as the range type is then selected based on the subjective judgment of the relationship creator. However, regardless, all the important information about the relationship - actor, place, date, reason, etc., can be stored as a property.

Table 23 Complex start-trans-end-act relationships

Action Types	Label	Active	Label	Passive	Date	Place
abolishment	act	shutdown	end	wasShutDown	shutdown_on	shutdown_at
destruction	act	destroyed	end	wasDestroyed	destruction_on	destruction_at
end	act	ended	end	wasEnded	end_on	end_at
death	act	killed	end	died	died_on	death_at
execution	act	executed	end	died	execution_on	execution_at
patrioticdeath	act	killed	end	died_patriotically	died_patriotically_on	died_patriotically_at
calligraphy	act	calligraphed	start	wasCalligraphed	calligraphy_on	calligraphy_at
carving	act	carved	start	wasCarved	carving_on	carving_at
composition	act	composed	start	wasComposed	composition_on	composition_at
construction	act	constructed	start	wasConstructed	constructed_on	construction_at
contribution, resource	act	contributed	start	wasContributed	contribution_on	contribution_at
creation	act	created	start	wasCreated	created_on	creation_at
erected	act	erected	start	wasErected	erected_on	erected_at
foundation	act	founded	start	wasFounded	foundation_on	foundation_at
naming	act	named	start	wasNamed	naming_on	naming_at
painting	act	painted	start	wasPainted	painting_on	painting_at
printing	act	printed	start	wasPrinted	printing_on	printing_at
start	act	started	start	wasStarted	start_on	start_at
birth	act	birthed	start	wasBorn	born_on	birth_at
addition	act	added	start, trans	wasAdded, hadAddition	addition_on	addition_at
copy	act	copied	trans	wasCopied	copy_on	copy_at
damage	act	damaged	trans	wasDamaged	damaged_on	damage_at
discovery	act	discovered	trans	wasDiscovered	discovery_on	discovery_at
enlargement	act	enlarged	trans	wasEnlarged	enlargement_on	enlargement_at
excavation	act	excavated	trans	wasExcavated	excavation_on	excavation_at
public presentation	act	presentedPublically	trans	wasPresentedPublically	public presentation_on	public presentation_at
receiving award	act	receivedAward	trans	wasReceived	receiving award_on	receiving award_at
reconstruction	act	reconstructed	start	wasReconstructed	reconstruction_on	reconstruction_at
relocation	act	relocated	trans	wasRelocated	relocation_on	relocation_at
removal	act	removed	trans	wasRemoved	removal_on	removal_at
renaming	act	renamed	trans	wasRenamed	renaming_on	renaming_at
renovation	act	renovated	trans	wasRenovated	renovation_on	renovation_at
repair	act	repaired	trans	wasRepaired	repair_on	repair_at
research	act	researched	trans	wasResearched	research_on	research_at
restoration	act	restored	trans	wasRestored	restoration_on	restoration_at
retiling	act	retiled	trans	wasRetiled	retiling_on	retiling_at
robbery	act	robbed	trans	wasRobbed	robbery_on	robbery_at
visit	act	visited	trans	wasVisited	visit_on	visit_at
passing examination	act	passed	trans	wasPassed	passing_on	passing_at
arrest	act	arrested	trans	wasArrested	arrest_on	arrest_at
award	act	awarded	trans	wasAwarded	award_on	award_at
bestowal	act	bestowed	trans	wasBestowed	bestowal_on	bestowal_at
discharge	act	discharged	trans	wasDischarged	discharge_on	discharge_at
exile	act	exiled	trans	wasExiled	exile_on	exile_at
failure in defense against	act	failedToDefendAgainst	trans	wasNotStopped	failInDefenseAgainst_on	failInDefenseAgainst_at
fighting against	act	foughtAgainst	trans	wasFoughtAgainst	fightAgainst_on	fightAgainst_at
imprisonment	act	imprisoned	trans	wasImprisoned	imprisonment_on	imprisonment_at
holding office	act	heldOffice	trans	wasHeldBy	holdingOffice_on	holdingOffice_in
asylum	act	soughtAsylum		-	asylum_on	asylum_at
praise	act	praised	act	wasPraised	praised_on	praised_at
burial	act	allowedRespectfulBurial	act	hadRespectfulBurial	respectfulburial_on	respectfulburial_at
homage	act	paidHomage	act	hadHomagePaid	homagepaid_on	homagepaid_at