[EPIC: DRK UC3] Modelling metadata for theater showtimes (Theaterspielplan)

[rohitadeshmukh13]

Use case scenario and data source details

• UC3 scenario: Machine-readable theater schedule (showtimes) / Maschienenlesbarer Spielplan
• Stakeholder - Data Provider: Theatres and opera houses, independent groups
• Data Source Type (API / Dataset): API
• API Endpoint: https://staatstheater-augsburg.de/drk
• Data format (JSON, JSON-LD, CSV, etc.): JSON
• URL to API specification: https://peret.github.io/uc3-openapi/v2/
• Further data model documentation: (Internal link to ER diagram)
• Any Additional Information such as the Data Fields it Contains and How it is Structured, any Referred Ontologies, Standard Data Models, etc.: schema.org (Please see the data model documentation for further details)
• Stakeholder - Data Consumer: OWL Live/UC1
• License / Data Usage Policy: CC-BY
• Access Policy: Everyone + unlimited (Reason: OpenData)
• Issue for modelling access/usage policies: #3

Example use case scenario

Resources for UC3 related modelling

• draw.io space for creating a visual metadata model for UC3: https://app.diagrams.net/#G1HUUDtPLwjkMWHwYPbjJDMMN7ygCTloWA
• Temporary branch: uc3

Subtasks

• 2

• 3

• 6

[rohitadeshmukh13]

Important points from DRK IM UC3 meeting

Date: 03.07.2024 Participants: @rohitadeshmukh13 (RD), @peret (PR), @Daham-Mustaf (DM) Information:

• draw.io space for creating a visual metadata model for UC3: https://app.diagrams.net/#G1HUUDtPLwjkMWHwYPbjJDMMN7ygCTloWA (RD).
• RD is still looking for a notation for visually representing RDF data that is intuitive and can be understood by people who are not familiar with Semantic Web, e.g., domain experts. UML Class diagrams, ER diagrams, RDF graph have been considered so far.
• New branch uc3 will be used for creating semantic models for UC3, until they are finalized and merged into the main branch (RD).
• The concepts from Miro board "Smarte Theaterdienste" have been considered while creating the Theater Showtimes API spec (PR).

Discussion points:

• (p1) "Theater" as an organization vs "Theater" as a physical place: The (meta) data model presented by PR emphasizes "Theater" as an organization (schema:Organization), while RD's metadata model emphasizes "Theater" as a physical place (schema:PerformingArtsTheater). Additionally modelling "Theater" as a physical place would have the following benefits:
  1. Consumer Convenience: It would enable consumers to query theater showtimes for a particular theater (place) in their vicinity.
  2. Preference-Based Search: Consumers can discover showtimes for theaters in a city operated by their preferred company.
  3. Map Integration: This approach facilitates easier integration with mapping services.
  4. Organizational Benefits: Maintaining a historical database of theaters as physical places, and linking them with theater organizations, would help organizations find rentable venues for their performances. Therefore, combining these two approaches would be beneficial.
• (p2) Linking Event to CreativeWork: RD's metadata model currently uses schema:about predicate to link the subject drk:Event to the object drk:CreativeWork. PR advises reviewing the use of schema:about predicate here.
• Info: schema:isBasedOn property: PR's data model currently uses the property schema:isBasedOn to link the CreativeWork (production) being described to the original CreativeWork that this work is based on.

@ all, please feel free add points from our meeting that I might have missed.

[rohitadeshmukh13]

Important points from DRK IM UC3 meeting

Date: 10.07.2024 Participants: @rohitadeshmukh13 (RD), @peret (PR), @Daham-Mustaf (DM)

Information:

• DM presented translation of "CC" licenses to "ODRL", which is required for enabling their use in data spaces.
• DM also presented a GUI that can be used to assign CC licenses to assets and generate ODRL representation. This will be integrated with the GUI of the DRK-maintained instance of EDC (Eclipse Data Space Connector).
• The discussion specific to usage and access policies will continue in this issue: https://github.com/Fraunhofer-FIT-DSAI/drk-information-model/issues/3

Discussion points:

• (p1) "Theater" as an organization vs "Theater" as a physical place:
  • We have agreed to model "Theater" both as an organization and as a physical place.
  • PR advises modeling "Theater" as a physical place carefully, because cultural events may take place in locations that are not necessarily "Theaters." For example, an event could occur in a general-purpose building or even as a virtual video meeting.
  • RD: schema:PerformingArtsTheater (Theater as a physical place), and schema:TheaterGroup (Theater as an organization) both have schema:event property which can be used to link these Theater-related classes with schema:Event class.
• (p2) Linking Event to CreativeWork: PR: Instead of using schema:about predicate to link the subject drk:Event to the object drk:CreativeWork, we can use the schema:workFeatured predicate here.

Next steps:

• Visual metadata model: RD to create an editable visual metadata model which also identifies concepts and properties from existing ontologies/vocabularies (e.g., Schema.org) that can be reused. This would form a basis for discussion and would be refined in the subsequent meetings.
• Competency questions: PR to extract competency questions / expected queries from data consumers (UC1) from the user stories discussed and documented so far, as a comment here.

[peret]

Additionally modelling "Theater" as a physical place would have the following benefits

Some more thoughts on our discussion around "Theater as a place vs. organisation":

Most of the benefits you mentioned in an earlier comment arise from the fact that we can assign an address/location to certain events, right? Obviously it is important for us to have location information for our events, but I think it might be enough to model this in terms of a general event location, without focussing too much on the fact that it is specifically a theater building in some cases. We should also keep in mind, that "event locations" as a general concept will probably come up in the modelling of other use cases as well (Use Case 1 for sure, at least)

Another aspect of this, that I wanted to mention: It's often the case that a "theater" isn't restricted to a single building/physical location. Two examples of this are the Staatstheater Augsburg (performances take place in 2-3 different locations throughout the city) and the Hans-Otto-Theater in Potsdam (two locations that are in close proximity to each other, but nevertheless have slightly different addresses). I'm sure there's many more. So, modelling a theater just as a place isn't an option, for that reason alone, I think. Not sure if that has any impact on your modelling, though, since we already agreed, that we need both, the location and the organisational entity :D

[peret]

As promised, here are some queries that we expect/want to support:

• Searching for the programme of a specific theater, by name
• Searching events/programmes by location: Searching by city, state, or even zip code (range) might be useful
• Searching by branch/category, e.g. theater, opera, concert, dance performances, festivals, theater for children and teenagers ("Kinder- und Jugendtheater"), musical, circus/new magic/Varieté. Note that a lot of theaters offer more than one of these in the same programme, e.g. they might show theater performances as well as some form of musical theater
• Searching specifically for performances that can be experienced online
• Searching for events that have certain accessibility features, e.g. the location is accessible with a wheelchair, performance is translated into Sign Language, etc.
• Searching for events with certain pricing conditions, e.g. events that are accessible for free or part of the "Kulturpass"
• Searching by person, e.g. finding events/programmes that a certain actor/singer/director is involved in
• Searching by date, e.g. get events only of next week

This list is intended as a record of all the different queries that we think might be useful. I'm aware that some of these might be hard to accomplish with our current setup. Of the ones I listed, I think searching by name and locations are two obvious must-haves that should also be achievable. The rest of them we can discuss and prioritize together, if you want.

[rohitadeshmukh13]

Some notes from DRK IM UC3 meeting on 17 July 2024:

Representing ENUMs:

• New issues have been created for finding controlled vocabularies for representing ENUMs: EPIC: #5

Connecting to existing concepts:

• Several vocabularies define same/similar concepts. While we can reuse one of these and build on top of it, it would be beneficial to like to the others using owl:sameAs, skos:exactMatch, skos:closeMatch, etc.
• E.g., For Theater: (1) https://d-nb.info/gnd/4059702-7 (2) http://zbw.eu/stw/descriptor/13364-4 (3) http://www.wikidata.org/entity/Q11635 (4) For skos:closeMatch, see >> https://d-nb.info/gnd/4059702-7/about/lds

Reusing / Connecting to existing instances:

• It is preferable to use new identifiers in the DRK IM namespace for instances to avoid dependencies and maintain complete control.
• Examples of existing instances: (1) Staatstheater Augsburg in GND knowledge graph: https://d-nb.info/gnd/1170044093 (2) Augsburg in GND knowledge graph: https://d-nb.info/gnd/4003614-5

[peret]

@rohitadeshmukh13 As promised, I updated the draw.io chart with some of the recent changes/additions that I made to our data model and marked them accordingly.

[rohitadeshmukh13]

Hi @peret, I've updated the concepts of Event, Play and their characters/performers relationships. Here's the latest version:

Some additional details: Plays:

• Plays can have the properties: characterRole and nonCharacterRole
• characters can include persons, animals, organizations, puppets, robots, inanimate objects and so on.
• nonCharacterRole is for roles such as author, scriptwriter, creator, editor, publisher, translator, etc.

Events:

• Events can have the properties: performanceRole and productionRole
• performanceRole is for onstage roles such as cast/actor, protagonist, antagonist, supporting characters, cameo, singer, dancer, etc. as well as other performance roles that might not be onstage, such as musician, singer, chorus members, etc.
• Similar to characters, performers can include persons, animals, organizations, puppets, robots, abstract entities, inanimate objects and so on.
• productionRole is for production related roles (or behind-the-scenes roles) such as director, music composer/director, organizer, stage manager, set designer, costume designer, choreographer, makeup artist, understudy, etc.

[peret]

Hi @rohitadeshmukh13,

thanks for the update, as discussed, I just had a look at the Model as well to see if I can spot any issues. The modelling looks reasonable to me, but I do have some remarks around the modelling of production and performance roles:

1. I wanted to mention that schema.org already provides a sub-class of Role, specifically for a character being performed by an actor: PerformanceRole with schema:characterName.
2. Regarding nonCharacterRole: Can you clarify for me what the difference is between this field and the creator field? I.e. you list "author, scriptwriter, creator, editor, publisher, translator" as examples for non-character roles, all of which could also be classified as "creators" of the production, couldn't they?
3. I would also suggest using a more explicit name for this field. E.g. something like creatorRole might make the intent of this field clearer.
4. Can you also clarify for me the semantics of Play.characterRole vs Event.performanceRole and Play.nonCharacterRole vs Event.productionRole? E.g. in your mind, what would it mean if I specified a role on both the Play as well as the event?

[rohitadeshmukh13]

Hi @peret, Thanks for the prompt remarks. Please find my comments below:

I wanted to mention that schema.org already provides a sub-class of Role, specifically for a character being performed by an actor: PerformanceRole with schema:characterName.

• IMHO, there are some limitations to how Schema.org currently models characters and performers.
• Play.character has expected type (Object) Person. But this will not always be the case, as Play.character can be an animal or a robot, etc. Therefore I've used the property Play.characterRole instead.
• Similar is the case with Event.performer, and there, I've used the property Event.characterPerformanceRole instead.
• For all properties (Play.characterRole, Play.nonCharacterRole, Event.characterPerformanceRole, Event.productionRole) pointing to the Role class, this parent class would need another property to indicate who the performer for these roles is. Therefore, I extended schema:Role to add another property called performer.
• As per the updated diagram, Play.characterRole and Event.characterPerformanceRole will point to the class drk:characterPerformanceRole which additionally contains the property drk:characterName.

Regarding nonCharacterRole: Can you clarify for me what the difference is between this field and the creator field? I.e. you list "author, scriptwriter, creator, editor, publisher, translator" as examples for non-character roles, all of which could also be classified as "creators" of the production, couldn't they? I would also suggest using a more explicit name for this field. E.g. something like creatorRole might make the intent of this field clearer.

• Yes, as you can guess, this property nonCharacterRole is for all roles that are not related to characters in a play. So, in that sense, creatorRole can indeed be used as an umbrella term and more specific role can be indicated using the roleName property. I've updated the model accordingly.

Can you also clarify for me the semantics of Play.characterRole vs Event.performanceRole and Play.nonCharacterRole vs Event.productionRole? E.g. in your mind, what would it mean if I specified a role on both the Play as well as the event?

• Play.characterRole is related to a character in a Play, whereas, Event.characterPerformanceRole (previously, Event.performanceRole) is related to the performance of a character in an "instance" of a Play (i.e., an Event).
• Similarly, Play.creatorRole (previously, Play.nonCharacterRole) is the umbrella property for all non-character related production roles involved in the the creation, development, and refinement of the play as a literary or creative work, whereas Event.productionRole relates to the behind-the-scenes roles in an "instance" of a Play (i.e., an Event) such as director, music composer/director, organizer, stage manager, set designer, costume designer, choreographer, makeup artist, understudy, etc., many of which are specific to an Event, but not to a Play.

Further feedback on this / suggestions to update the terminology, etc., are of course welcome!

[rohitadeshmukh13]

Some notes from DRK IM UC3 meeting on 7 August 2024 and further comments on what we discussed:

Modeling Play and Event:

• Currently, our model consists of classes drk:Play (extends schema:Play) and drk:TheaterEvent (extends schema:TheaterEvent).
• According to Schema.org:
  • Play (schema:Play) is modeled as a form of literature (Schema.org puts this term in the "new" area, so it's subject to change)
  • TheaterEvent (schema:TheaterEvent) is modeled as a 'theater performance' event happening at a certain time and location.
• Therefore, as @peret pointed out, we are probably missing a middle step related to production activities other than literature.
• @peret also pointed out that even when schema:Play is modeled as a form of literature, it contains properties such as funder, sponsor which perhaps relate more to such production activities happening in the middle. Also, some plays might not even have a written script beforehand (Please, CMIIW).
• So, for this 'Alpha' version of the DRK IM, we decided to model drk:Play to represent both, literature and such production activities.
• For this reason, in this version, drk:Play can no longer extend schema:Play, but it needs to directly extend its parent class schema:CreativeWork. IMHO, we should provide Schema.org community with our feedback.

Backlog: @peret, while we're on this subject, for the next version of the DRK IM, we need to consider how to model the concepts of 'Play,' 'Staging,' 'Production,' and 'Event,' as well as the relationships among them. Looking at some sources such as britannica, it seems that Production includes every stage of Play from writing, planning, casting, to rehearsal and presentation of work (i.e., Event). I'm adding this to our backlog for discussion in future meetings. If you have any comments or additional tasks to add to the backlog, please let us know.