file-waveformDataset

DATA COLLECTION

Since ready-to-use open datasets for the domain we modelled were not available, we created one by combining information selected from our sources, in particular the Contested Histories website and digital map, and information extracted from the scenarios generated with ChatGPT.

We organized our data in Excel sheets, one for each Class in our conceptual model. We started with column names in natural language, that we mapped to the properties in our conceptual model in order to transform data in the Excel file into RDF.

The Excel file can be downloaded herearrow-up-right.

file-download
213KB

The Python script used for the RDF production can be seen below.

RDF PRODUCTION

As mentioned, each table represents a Class with multiple properties associated to it in the data model. Each row in the table, thus, represents an instance of that class, whereas each column is either a datatype property or an object property and the values in the cells represent the objects in the triple, either a Literal or a URI.

URIs for classes in our ontology were designed as follows:

https:{domain}/{path}/{concept}/{identifier}arrow-up-right

starting from the URL of the turtle file in our github repository. After organization name, repository and folder, the URI includes the concept an entity belong to (historicalFigure, place, timeInterval, monument, etc.) and its identifier, retrieved from the dcterms:identifier property.

https:github.com/KRKE-monument-debate-ontology/Data_MDO/md-ontology/historicalFigure/historicalFigure_colomboarrow-up-right

The RDF production was carried out using Python rdflib and Pandas. The resulting turtle dataset and the python script can be downloaded here.

PROTÉGÉ

The output turtle file resulting from the Python transformation was then used to formalize our ontology in Protégé. We defined the hierarchical structure of the Monument Debate Ontology by mapping its core concepts to superclasses derived from the Perspectivisation ontology, as specified in our conceptual model. Furthemore, Protégé was used to express properties' characteristics and to add cardinality restrictions. Specifically, we employed cardinality constraints to specify that the ActionProposal class can have at most one Remedy. This implies that while a proposal may results into a single remedy, it can also exist without one if a decision has not yet been reached.

To ensure logical consistency and data integrity, we carefully defined the nature of our properties:

All the properties in our ontology are defined as both asymmetric and irreflexive.

An Asymmetric property represents a strictly "one-way" relationship (if A relates to B, B cannot relate to A), ensuring the hierarchy remains directed and non-reversible.

Complementing this, an irreflexive characteristic prevents an entity from being related to itself (a "no self-relation" rule). The subject and the object must always be different.

Finally, properties like tip:atTime, time:hasBeginning, and time:hasEnd were declared functional. A property is functional when a subject can have only one unique value (object). This is essential for facts that cannot logically have multiple values, such as a specific date or a single point in time, ensuring that each event in our ontology has one clear and consistent time reference.

Last updated