Skip to content

2. Entity Attributes and Relationships

rebmizrahi edited this page Apr 8, 2024 · 1 revision

This page will explore how the data model is set up. See developer documentation for full details of models and their attributes at: https://elvis-project.github.io/simssadb/html/index.html. Some of the attributes are outdated, as there were some simplifications made, but for this purpose it is a helpful tool. The entity relationship diagram below describes the database. To make it more digestible, we will walk through each model to understand the structure of the database and link the corresponding documentation that describes its attributes more in depth in case that is of interest.

SIMSSA DB ERD 1_4_3c_Gustavo_Update

We can start by looking at abstract entities. SimssaDB defines a separation of an abstract work and a particular instantiation of a work - for example, a particular symbolic file of a musical work. This is helpful for representing multiple versions of abstract work, such as different arrangements, encodings, and editions.

Further, SimssaDB allows for a complex representation of abstract relationships in music. This is achieved with separation of music into abstract musical works, sections, and parts. So, if an orchestral score and a keyboard reduction of a single abstract work have different parts, this can be represented by an abstract musical work having two distinct parts. Specific details of entities are explained below.

A Musical Work can be manifested in different versions due to its abstract nature. It has attributes that include a many-to-many mapping to other musical works, representing related works; one-to-many mapping to sections in a work; variant titles that refer to the work; and so on. It has a few other mappings which are explained below.

Related models include Type of Work, or genre referring to type, maps many-to-many with musical works. Similarly, there is Style, or genre referring to style of musical work.

A Section of a Musical Work - for example, an Aria in an Opera - is an abstract entity that can manifest itself in different versions. A Section can be divided into one or more sub-Sections, and can contain one or more Parts. It has a foreign key of a musical work, a parent section (that it is a sub-Section of), and the Type of Section. Many child sections as well as many parts may map to one section. Source instantiations map many-to-many, as do related sections.

A Part is a single voice or instrument in a section of a musical work. Its foreign keys are musical work, section, and the instrument it was written for. It maps many-to-many with source instantiation, which refers to the instance of a source that instantiates this part.

Next, it is important to define Sources. Sources are necessary for tracking provenance of each digital object in the database. A source is a reference to an actual physical or digital document containing the music defining a MusicalWork or a set of Sections or a set of Parts. A source can be derived from a parent source, allowing representation of a chain of provenance. A source can therefore map one-to-one to a parent source and/or child source. Its foreign keys are Archive, denoting the archive where the source can be found. It maps one-to-many to source instantiations.

Source instantiation is an instantiation of a musical source, relating an abstract source and an abstract musical work/section/part with specific file(s). So, its foreign keys are musical work and source, and it maps many-to-many to sections and parts. It may also have multiple files mapped to one source instantiation, for any files that instantiate the source linked to the source instantiation.

Next, we may look at Contribution. Contribution acts as a relation to map a person to the musical work they contributed to. Contribution's foreign keys are therefore person, location, and musical work. Contribution maps many to one of each key - i.e., many contributions may be made by one person.

As mentioned, Person has a many to one mapping of contributions to person with two foreign keys of Geographic Location representing birth and death location. Person also has useful attributes such as name and birth date.

An Extracted Feature refers to the content-based data extraction by a software (like jSymbolic) from a symbolic music file. For example, an extracted feature may be the prevalence of acoustic guitar in a work. Foreign keys include a reference to the Feature Type of this Extracted Feature, the software that extracted this Feature, and the type of feature. The Extracted Feature be a feature of one and only one Symbolic Music File and must be a instance of a Feature Type. It maps many to many with Feature files, or files that contain this Feature.

A File refers to a file containing or representing music, which may be a Symbolic Music File, Image, Text or Audio. Foreign keys include references to encoding and validation workflows and the Source Instantiation manifested by this file. It maps many-to-many to the Research Corpa that contain this file, and maps one to many to Feature Files that contain features extracted from this File and Extracted Features extracted from this File.

A Feature File is a file containing all the features extracted from a symbolic music file. It has foreign keys of a reference to a File model from which these features were extracted as well as the Software used.

Encoding Workflow is a workflow used to encode a symbolic music file. Its foreign key is a reference to the software used in encoding and it maps one-to-many files encoded with this workflow.

Validating Workflow is what is used to validate a symbolic music file that has been inputted into the database. Its foreign keys include a reference to the file that was validated using this workflow as well as to the software used in validation.

As mentioned, a Software maps one-to-many Encoding and Validator Workflows, Extracted Features, Feature Files containing features extracted with this Software, and Feature Types that can be extracted with this software.

An Experimental Study is an empirical study based on a particular Research Corpus.

Future Work

The ERD below shows our future plans for the database architecture. Note the difference around Source Instantiation; they will link Sources to Text Files, Audio Files, Image Files, and the already-implemented Symbolic Files, with encoding software specific to that type of file. SIMSSA DB ERD 1_4_3