Ontologies, Knowledge Graphs, and User Interfaces for Exploration of Irish Traditional Music

The paper concerns an important and interesting corpus of traditional music noted for its rich body of related tunes and renditions. It describes LOD and KG models that will permit the discovery of related renditions and related motives.

The resources are well documented and published on Github for others to use and adapt.

All of this is promising! Nevertheless I suggest (as noted on an annotated PDF of the paper, which I share with the editors) some key revisions to content and writing. Keys suggestions:

1) There are many places in which the prose is merely descriptive and not explanatory. Frequently we read short, choppy paragraphs.
2) Musical concepts (and the choices they imply as the authors propose this or that solution for working with them) need to be explained for SWJ readers. Some musical examples of related pieces or patterns, or link to a recordings that could illustrate these, would help.
3) No less importantly: some acknowledgment that the datasets are transcriptions, and ones that might or might not capture the richness of individual performances or renditions, or even the heterophonic character of much of the music in question. What's gained or lost in such representations? What biases are in them?
4) The choice of analytic selection of structural ('accented') tones also requires some illumination. Why is this a good approach? What might be missed through this approach?
5) With respect to the KG examples, can we have some suggestions on how we should read these? Perhaps by linking our key musical examples to the 'segments' in some way that helps tell a story with these?
6) For the annotations: is there any accommodation for giving credit (or blame?) to those responsible for an annotation? Who 'claims' to see or find a pattern? The patterns are not objective, after all, but the result of some process of selection by some person(s) or tools that a person designed.
7) The example queries get more persuasive and interesting as they go along. I think I understand why they need to be built up in this way for readers. But we could benefit by connecting the results to some real instances (in notation, sound recordings). Too frequently: things in the captions are actually important enough that they call our for some narrative interpretation in the body of the argument (which is otherwise often rather descriptive rather than explanatory.

In this paper, the authors construct a knowledge-graph representation of melodic n-gram patterns by formalising them in an ontology adapted from MAP-ODP pattern and operationalising the workflow through SPARQL Anything and an extension of the Smashub toolchain. They extract and rank patterns using corpus-based methods including TF–IDF, encode the resulting annotations using a JAMS schema and populate the KG via a SPARQL-based pipeline.

The paper showcases a browser-based tool that lets users explore tunes, inspect extracted patterns, and run predefined SPARQL queries, effectively serving as a lightweight front end for interacting with the KG.

The evaluation relies on a set of competency questions implemented as SPARQL queries to demonstrate that the knowledge graph can retrieve patterns, relationships and tune-level information as intended. Rather than quantitative metrics, the authors use these query outputs to illustrate the coverage and practical utility of the modelling choices.

The paper reports on technically solid work and refers to several open source contributions and datasets stemming from the Polifonia project. It demonstrates originality by combining a structured music-pattern ontology with an interactive knowledge graph interface for folk music exploration.

The results are significant, showing both analytical depth through SPARQL queries and practical utility via the GUI. The writep is generally clear and readable, though some methodological choices could be more thoroughly justified. While most resources necessary for replication are included, some queries and preprocessing scripts may be missing or not fully documented, which may limit exact replication. The use of GitHub as the repository is appropriate for long-term discoverability and version control. The provided artifacts are mostly complete, but minor gaps could hinder fully reproducing all experiments.

While the paper presents a very promising approach to standardised large corpus-driven music analysis, several of its contributions would benefit from clearer justification and deeper explanation.

I would be leaning to accept the paper after addressing some recommendations below regarding specific aspects of the contribusions.

* Introduction:
While the motivation is clear for readers familiar with the field, the transition from the general motivation (e.g. flexible querying, open access, and interoperability) to the adoption of Semantic Web technologies feels a little abrupt. The authors do not sufficiently explain why an ontology and knowledge-graph framework is preferable to more conventional representations, such as traditional databases or established MIR-specific formats. Readers outside the Semantic Web community may find the choice under-motivated. To benefit the broader music informatics community, could you justify why an ontology-based knowledge graph is the appropriate solution compared to simpler or more established representations?

* Section 1.1:
Regarding the explanation of musical patterns and the particular representation thereof I would question whether the chosen definition of melodic patterns (accented-note n-grams of scale degrees) musically and analytically defensible, and what important information might this simplification omit?

While the decision to define patterns as n-grams of diatonic scale degrees restricted to accented notes is reasonable, but it is perhaps somewhat insufficiently argued. While the authors hint at relevant literature, the consequences of this reduction are not fully examined. It would be helpful to understand which musically meaningful structures are omitted by ignoring unaccented events, contour, or intervallic detail, and why the benefits of this simplification outweigh its limitations.

* Sections 2.1–2.2:
The modelling approach builds on MAP-ODP and adapts the Smashub workflow, but the rationale for selecting this framework is not entirely clear. The fit between melodic n-gram patterns and the MAP abstraction is implicitly justified. Portions of the design appear driven by availability of existing ontologies rather than demonstrated methodological necessity, and further discussion of this alignment would strengthen the contribution.

I generally wondered if the mapping between the musical concepts and the selected ontology design patterns conceptually sound, or does the model appear to be driven more by what is convenient than by what is musically meaningful?

* Section 3.2:
The application of TF–IDF to rank musical patterns is a little under-motivated in this section. The paper would benefit from a clearer explanation of how this approach translates to the musical domain. What constitutes a "document" in this context, why emphasising rare-but-frequent patterns is desirable, and whether any evaluation supports the claim that TF-IDF correlates with meaningful musical salience?

Sections 3.3–3.4:
The introduction of a custom JAMS pattern schema is justified very briefly. Although the schema looks reasonable, more detail might be needed regarding how this maintains interoperability with existing JAMS tooling or whether it can generalise to broader MIR applications. Likewise, the use of hashed URIs is an interesting choice, but the long-term implications such as reproducibility, collision risk and maintainability are perhaps not fully discussed.

* Sections 4-5:
The evaluation leans heavily on listing SPARQL queries and their outputs, but it isn’t always clear what the authors take to be strong evidence of the KG’s adequacy. The reliance on competency questions is reasonable and commonly used in similar research, but the evaluation would feel more grounded if the authors explained why these particular CQs sufficiently span real musicological use cases, and whether any of the tasks surfaced limitations of the modelling choices (for example, in representing variants or distinguishing pattern types).

Through CQ5–CQ7, the authors describe the queries in detail but the justification for some of the design decisions remains a little bit thin. For example, location-based reasoning over patterns (beginning/middle/end) depends on normalising by tune length, but there’s no discussion of whether this heuristic corresponds to meaningful musical structure. A similar issue arises with similarity in Listing 8. The authors imply that shared n-grams are a good proxy for similarity, yet there is no reflection on the musical validity of that assumption.

The treatment of CQ8 and CQ9 outlines potentially powerful capabilities, but the methods feel somewhat weakly explained. The extraction of characteristic patterns for tune families is driven entirely by SPARQL filtering, and it would help to acknowledge the risk of confounding factors—like tune length, density of patterns, or uneven annotation coverage—that might bias what appears “characteristic”. Likewise, containment relationships are demonstrated by virtue of storing multiple n-gram sizes, but the authors never address whether this approach captures musically meaningful containment rather than trivial overlaps.

Finally, the transition into the GUI description is informative, but in places reads more like descriptive documentation / user guide rather than an evaluation of design decisions. It would strengthen the narrative if the authors clarified which user needs actually motivated the final feature set and which insights from co-design challenged or validated the modelling assumptions behind the KG. Similarly, the conclusion could be more reflective rather than just a summary of contributions.

While the study presents a promising integration of a music-pattern ontology with a knowledge graph and interactive interface overall, stronger justification of methodological choices, evaluation rigour and comparison to related systems would increase my confidence in the broader applicability of the proposed approach.

To reference particular parts of the text precisely, I use page:line (for instance, 1:46).

# Originality

Core to the originality of this work is its practical focus. The authors bring together—in a novel way—music ontologies to accurately (but flexibly) record melodic patterns, a data transformation pipeline that creates a knowledge graph of melodic patterns across pieces, a SPARQL query endpoint for more technical users or those happy to adapt the template queries provided, and a user interface for less technically inclined users. I congratulate the authors on working so adeptly across disciplinary and technological boundaries, and the result will be of interest both to musicologists interested in melodic similarity, as well as more technical experts working with ontologies and knowledge graphs more generally.

The authors do an excellent job of reviewing existing work in the music ontology and analysis space, and identifying where their own work on formalising melodic patterns fits in. They build up this context in a logical fashion from first principles (music analysis -> musical patterns -> patterns in folk songs -> ontologies). There are some minor caveats and suggested improvements in the section on “Quality of Writing” below.

The authors correctly note that much of the ontological groundwork in this space focusses on music cataloguing and classification, more than structured musical annotations (3:29). The choice of the authors to build on the Music Annotation Pattern ODP seems like a sound choice, and will hopefully enhance its future interoperability with other kinds of pattern analysis.

The focus of this taxonomy on “n-grams of scale degree” (2:29) is sensible, both because it clearly suits the Irish folk repertory the authors have worked with, and because it can intuitively and broadly be applied to other repertories that are either fully monophonic or have easily separable contrapuntal melodic lines.

While using n-grams as the basis for music analysis isn’t new, the authors distinguish their approach in the specific choices made: 1) a focus on n-grams with a specified range of length, 2) using accented notes to define these pitches, potentially better highlighting “structural” pitches, though of course this will vary by repertory, and 3) the use of diatonic notes in defining patterns: points 2 and 3 have the effect of simplifying the resultant patterns and potentially making them easier to identify despite note-level variations caused by “modal ambiguity” (3:6) or other fine-grained compositional choices like embellishment.

A core contribution of this work is the development of a software pipeline to create a knowledge graph from patterns, giving a structured way of exploring not just what patterns occur in a repertory, but how they are connected. The choice to build on Smashub rather than start from scratch is sound and well-reasoned.

# Significance of Results

Overall, this is an impressive set of work that brings together not just ontological foundations, but data transformation pipelines, a SQARQL query endpoint, and a graphical user interface. The authors are to be commended on their contribution to the study of patterns in Irish folk music and to computational musicology and Music Information Retrieval more broadly.

Section 1.2 does a good job of explaining the potential for this work to support the identification of “tune families” and other forms of melodic similarity and transformation. While it is mentioned briefly that this kind of ngram analysis can be adapted to other repertories, it would be worth mentioning one or two concrete examples to help readers envisage how they might translate this work to other corpora.

Section 4 does a thorough job of stepping through how the eXtreme Design methodology was applied and how the Competency Questions were addressed concretely through carefully-crafted SPARQL queries. The inclusion of a collection of sample SPARQL queries to demonstrate the flexility of the knowledge graph in addressing different types of questions is significant.

Consultation with musicologists through various co-design processes is a strength of the work, which extends to the GUI. Since musicologists would need the help of more technical specialists in crafting SPARQL queries, the development of a simple user-interface should enhance the overall accessibility of the work. I particularly like the network view as a way to simply and intuitively show where musical works share melodic patterns.

An implicit theme across all this work is democratising access to corpora of linked musical patterns, and music analysis more broadly. This theme is hinted at, but it is worth addressing more explicitly in the latter part of the article where the narrative shifts from constructing the knowledge graph to querying it to answer research questions. For instance, the opening of Section 5 could be much stronger in articulating why and how a Graphical User Interface will broaden the impact of this research. SPARQL endpoints are often under-utilised by non-technical domain experts so both the GUI, and the set example SPARQL queries have an important role to play that should be highlighted.

Similarly, given the shifts in the technology landscape since this work was undertaken, it might be helpful to provide some preliminary comment—whether positive or negative—on where advances in LLMs and associated technologies could further democratise access to pattern analysis in musical corpora in the future, be this in identifying these patterns or subsequently querying them. This is particularly salient given the objective of the authors to support “open-ended integration with future work” (2:9). There are a number of projects that leverage LLMs to construct SPARQL queries (https://data.carnegiehall.org/datalab/voicebox/), and many of the Python tools developed in this project could be adapted to support chat-based interactions through the Model Context Protocol (https://modelcontextprotocol.io/docs/getting-started/intro).

# Quality of Writing

The article is well-written and organised overall, but anything that can be done to enhance clarity both at the micro and macro levels would be worthwhile. The comments below are suggestions as to how this might be best accomplished, but I leave it to the editors to make a final determination so long as the manuscript is tweaked with clarity and readability front and centre. This is particularly important when readers from diverse backgrounds will be interested in what has been produced here.

The article can be difficult to read in places due to the density of acronyms of different technologies and ontologies. Personally I’d lean toward a little more verbosity to aid clarity for readers, but this is largely an editorial decision. For instance, the repeated use of KG instead of knowledge graph is particularly jarring, especially when it occurs in headings (like section 1.3) or the abstract.

The capacity of the authors to build effectively on their own past work, as well as ontological and software foundations developed by others, should be applauded. At times, however, it is a little difficult to unpick 1) what constitutes background work, 2) what constitutes new work presented for the first time here, and 3) how everything slots together. I think this could be readily addressed with some modest changes to section 1.4 (4:28), in the lead up to section 2, either in the text or even with a minimal timeline that spells out the sequence of work.

In the same vein, the Introduction would benefit from a high-level summary (or diagram) of how project components fit together, along the lines that we have at the very end in the Conclusion (section 6).


Section 1.4 should also make some mention of Section 4 (Evaluation).

A few other minor details I noticed:

(1:46) “recognizing genres” is perhaps redundant, since genre is mentioned twice earlier in this sentence. This whole sentence could perhaps be simplified slightly.
(2:2) I don’t think “most-common” should be hyphenated here unless it is being used as a special term, in which case it should be elaborated a bit more fully.
(2:22) Capitalise “music information retrieval”?
(2:42) Hyphenate “19th century”?
(5: 6) “common format known as JAMS to represent these JAMS annotations”. This phrasing is a little confusing.
(5:42) “A pattern has contents”. Perhaps describe pattern_content more fully either here or in the paragraph above.
(9:1) It is a little confusing for readers that Table 2, which lists out the competency questions, appears well above the Evaluation section. Similarly for Listing 1. But presumably this was done to optimise the use of space.
(10:6) “To save space, we present just four CQs, listed in 2”. It seems like more than four competency questions are discussed, and I’m not sure what “listed in 2” describes.
(12:7) Stray dash (-) near start of line
(16:13) “useres” -> “users”
(17:36) The pattern ‘1, 3, 1, 7’ in the caption of Figure 4 doesn’t seem to match the screenshot (which instead has ‘1, 7, 1, 3’). There are one or two other subtle mismatches between the figure and the caption so it is worth tweaking this to ensure it matches exactly or simply summarises the figure.
(19:1) It is somewhat jarring to have a Figure placed after the conclusion of the text. It would be good to move this further up if at all possible.
(19:28) References [5] and [6] appear to be duplicates, and it appears there may be other duplicates ([15]/[16]) so worth reviewing these carefully. There also seem to be some inconsistencies in names that could be tidied up (see the author Penuela across [12] to [16)].

# Data and resources

The associated GitHub repositories are neatly organised, fairly well documented, and pass basic testing. The tabular metadata included in each README file is a helpful addition. The code itself is nicely structured with clear and intuitive class names, docstrings, and methods.

A few points that could be addressed with small tweaks to the repositories:

1) There is some inconsistency across repositories as to whether dependency versions are pinned with specific versions of packages. (https://github.com/polifonia-project/patterns-knowledge-graph/tree/main/... does not pin them, but this one does https://github.com/polifonia-project/folk_ngram_analysis). Perhaps in a research context like this, pinning the dependencies makes most sense, but if you go this route, dependencies should likely be updated to the extent possible without breaking functionality.


2) Again along the lines of reproducibility, the Patterns Knowledge Graph repository could benefit from the inclusion of a Dockerfile, since it brings together both Java and Python dependencies, and a container could better encapsulate these in reproducible way.


3) For the FoNN tools specifically, pickle likely isn’t the best format for a “corpus-level Pandas dataframe” (8:5) if there is an expectation that these tables might be a useful output in their own right. There are potential security considerations around pickle files and other formats would be more broadly interoperable.

These points are perhaps minor in isolation so I leave any adjustments to the discretion of the authors and editors, but collectively they highlight the need to explicitly address the reusability and sustainability of the code artefacts. I suggest adding some text to the article about how these GitHub and any other resources are structured to support future use by researchers and practitioners, and how the software and data are organised to align with FAIR principles. This may involve some modest tweaks to the repositories, which don’t seem to have seen new commits in the last couple of years.