Modelling Festival Headliners

[dlh28]

In addition to the existing fields in the Festival Structured Data templates, some festival organizations may also find it helpful to add festival headliner(s) to their structured data.

@fjjulien did some research and found a Wikidata item, headliner (Q1571829), that could be used as an additionalType to describe a performer in structured data – providing that the subclass in Wikidata is expanded to "artist" as opposed to just "performance artist" (aka visual artists who do performance art). I also found a Schema property called subjectOf that can be used to connect a Thing to a creativeWork or Event, along with its inverse property about.

This document contains three different modelling options (1.1, 1.2, 1.3) using the Wikidata URI additionalType and either subjectOf or about to connect the headlining performer to their respective festival edition/day. Do you think that any of these options in particular could be added to the Festival templates?

@saumier @christianroy

[fjjulien]

@dlh28 Thank you for raising this tricky modelling question and for proposing modelling options.

Before I comment on your three options, I would like to deconstruct the question by proposing a different perspective on the concept of “headliner”:

Does the term (or tag) “headliner” apply to an artist (person or group) or does it apply to a performance (and, by extension, to its performer)?

A headliner is a kind of “act” – or at least it should be modelled in a similar fashion as the “opening act” or as support acts, since it only exists in opposition to these preceding acts. An act is a “thing done” or in the context of the performing arts, a part of a dramatic work meant to be performed at an event. Similarly, the French translation, « première partie », is also understood as a part of an event.

Let’s consider the pros and cons of these two modelling approaches – headliner as an artist vs headliner as a performance – from the perspective of competency questions: “What are the questions that the model needs to answer?”.

The modelling of the headliner as an artist is meant to answer a single competency question: “who will be (or who was) the main performer at an event?”

If “headliner” and “supporting acts” were used as qualifiers or additionalType for performances rather than for artists (persons or groups), would we lose any information that might otherwise have provided an answer to this question?

I don’t think so. It would still be possible to retrieve the artist information via the performance data record (and, in music, the name of the performance name is almost always the same as the name of the performer – which might explain why no one bothers making a distinction between the performance and the artist when talking/thinking about a headliner). If the data was flattened and/or simplified and rendered as text, “CityFolk 2023: has headliner: The Arkells” would be the outcome, either way.

If “headliner” and “supporting acts” were used as qualifiers or additionalType for performances rather than for artists (persons or groups), would we gain any information that might provide answers to additional competency questions?

If the headliner type is associated with a performance, we can still answer the question “who will be (or who was) the main performer at an event?” AND we can address additional competency questions:

• “On what day will headliner X be performing?”
• “At what time does headliner X’s set begin?”
• “Will there be any guest performers alongside the headliner?”
• “Is this a ticketed event?”
• “How much does a day pass cost?”

If we want the modelling to answer as many competency questions as possible, it may be useful to shift the perspective and to consider “headliner“ as a qualifier for a performance rather than an artist.

[dlh28]

I would hesitate to use the word “headliner” specifically to designate a performance, because it doesn’t make logical sense in English. The -er suffix denotes an actor or agent and a performance cannot be an actor or agent. In this case, it would be more accurate to say “headlining performance”.

“Opening act”, however, could logically refer to a performance, since it’s more ambiguous whether or not the “act” is the “actor” or the “thing that is acted”. If we wanted to proceed in this direction, I would strongly encourage ditching the word “headliner” altogether.

[fjjulien]

I would hesitate to use the word “headliner” specifically to designate a performance, because it doesn’t make logical sense in English.

The primary function of conceptual modelling is not so much to represent information from a linguistic standpoint, but to represent information in relation to specific use cases in a given domain. How the concept is labelled – "headliner", "headliner act", "headlining performance" or "featured performance" – doesn't matter quite as much as how the concept is defined and modelled – and the capacity of this modelling to answer competency questions related to the use cases. This being said, I fully appreciate the importance of choosing the right name for a concept when comes the time to communicate a modelling strategy to potential adopters.

At present, my mind isn't set on any particular modelling strategy. I'm only attempting to tackle the question from a different angle, to broaden the range of options. I'm sorry if that is unsettling.

[fjjulien]

I would now like to comment on specific parts of your modelling options.

"performer":{
    "additionalType":"http://www.wikidata.org/entity/Q1571829",
    }

This additionalType is only TRUE in relation to a given event. If an artist entity was extracted from a festival event and minted an Artsdata ID, we wouldn’t want to import this additionalType in Artsdata, as it would not be meaningful or useful for data consumers.

In other words, “headliner” is not a defining characteristic of the artist entity itself. It is rather a ‘role’ in relation to an event.

Do I have any alternative suggestions? Not really.

It would be possible to represent “headliner” as a schema:role type. However, this would require intricate nesting of entities, which would represent an obstacle to adoption. I can try to code it, if you would like to visualize what it could look like.

[fjjulien]

"performer":{
    "subjectOf":{--Nested Event object--}
    }

This is conceptually accurate and elegant.

This statement remains TRUE with or without the performer relationship: if the artist entity is extracted from the festival entity and represented as a stand-alone entity, the statement would still be meaningful.

The only downside is that it may feel a little redundant.

[fjjulien]

Option 3

  "http://purl.org/ontology/mo/headliner":[{--some nested foaf:agent--}],

This is a very simple and conceptually correct modelling strategy. The fact that the word “headliner” appears in the URI would make this code meaningful to anyone. Simplicity and meaningfulness would help with adoption.

In addition, I could see this modelling be used at the initial announcement of a festival edition, before performance start times are confirmed.

I would recommend that the headliner be represented as a nested entity, rather than just as a text string.

[dlh28]

I would hesitate to use the word “headliner” specifically to designate a performance, because it doesn’t make logical sense in English.

The primary function of conceptual modelling is not so much to represent information from a linguistic standpoint, but to represent information in relation to specific use cases in a given domain. How the concept is labelled – "headliner", "headliner act", "headlining performance" or "featured performance" – doesn't matter quite as much as how the concept is defined and modelled – and the capacity of this modelling to answer competency questions related to the use cases. This being said, I fully appreciate the importance of choosing the right name for a concept when comes the time to communicate a modelling strategy to potential adopters.

At present, my mind isn't set on any particular modelling strategy. I'm only attempting to tackle the question from a different angle, to broaden the range of options. I'm sorry if that is unsettling.

Why would this be "unsettling"? I was merely pointing out the potential implications of using an English label that doesn't logically make sense for the definition/core concept we would be aiming for if we chose to focus on performances rather than artists. I didn't mean to imply that you had made up your mind (hence why I said, "if we wanted to proceed in this direction"). I'm sorry if that was unclear in my response

[dlh28]

I would now like to comment on specific parts of your modelling options.

"performer":{
    "additionalType":"http://www.wikidata.org/entity/Q1571829",
    }

This additionalType is only TRUE in relation to a given event. If an artist entity was extracted from a festival event and minted an Artsdata ID, we wouldn’t want to import this additionalType in Artsdata, as it would not be meaningful or useful for data consumers.

In other words, “headliner” is not a defining characteristic of the artist entity itself. It is rather a ‘role’ in relation to an event.

Do I have any alternative suggestions? Not really.

It would be possible to represent “headliner” as a schema:role type. However, this would require intricate nesting of entities, which would represent an obstacle to adoption. I can try to code it, if you would like to visualize what it could look like.

Good point

[dlh28]

Option 3

  "http://purl.org/ontology/mo/headliner":[{--some nested foaf:agent--}],

This is a very simple and conceptually correct modelling strategy. The fact that the word “headliner” appears in the URI would make this code meaningful to anyone. Simplicity and meaningfulness would help with adoption.

In addition, I could see this modelling be used at the initial announcement of a festival edition, before performance start times are confirmed.

I would recommend that the headliner be represented as a nested entity, rather than just as a text string.

I believe this was one of your initial modelling strategies, as I'm not familiar with it (I only expanded Option 1). I will defer to the rest of the group if everyone feels that this makes the most conceptual sense.

[fjjulien]

@dlh28 evenko uses schema:Role to assign a particular contribution role to performers (see this issue).

This modelling strategy would work fine for describing a headliner. Here is a fictive example:

{
    "@context": "https://schema.org/",
    "id": "someURI",
    "type": "Event",
    "additionalType": [
        "http://kg.artsdata.ca/resource/Festival",
        "http://www.wikidata.org/entity/Q27968043"
        ],
    <--!  startTime, endTime, location, etc. ...  -->
    "performer": {
        "type": "Role",
        "roleName": "Headliner",
        "sameAs": "http://www.wikidata.org/entity/Q1571829",
            "performer": {
            "type": "PerformingGroup",
            "name": "Some Really Cool Band"
            }
        }
}