Data talk:Performances.json

Multiple-year events vs. annual events

The multiple-year events currently being shown at Performances just "happen to be" events that span multiple years in the data set. There's not much difference between, say, "Allsang på Grensen" and the "Kongsberg Jazz Festival", except that the former only uses that one label for every instance and the latter uses different labels for different years. There's also little difference between those things and, say, "God Sommer Norge", except that she only appeared on that show once. So I think for consistency all events that happen more than once, regardless of whether she participated in them more than once, should be listed under their generic names (e.g., "Kongsberg Jazz Festival") with a separate field identifying which instance of the event we are talking about (e.g., "2017" for the KJF, maybe "Season 6" for NGT, and "Larkollen", etc., for "Christmas concert tour 2017"). But see also my comment in the next section. - dcljr (talk) 21:19, 16 August 2025 (UTC)

Splitting event field

The "event" field is currently doing a lot of work here. I think we should consider breaking down the information into more narrowly-defined fields, like "city", "country", "venue", "social" (for TikToks, etc.), and so forth, reserving "event" for 'real' event names, like "Rotary Club Convention", and let Module:Performances worry about constructing unique labels (used as linked page titles) depending on which information is present. (The result could be overridden when necessary by using another field.) I assume it is possible somehow to use a "computed" field in keys= (i.e., a field constructed within the module itself, not in the call to the module)? That way users wouldn't need to figure out / remember any naming conventions when adding information, so long as they understand the meanings of the separate fields. - dcljr (talk) 21:19, 16 August 2025 (UTC)

I basically agree to your suggestions, also in regards to the previous section. But as just explained in Talk:Performances#Repeated_'id's, I think it's more a configuration task, and a construct to combine those individual fields could be done there. It's possible to use a template for that to ease the config, and that template could then also be used elswehere when linking to the event entry. I think we could make the id generation optionally independent from what is displayed in the table header, though that might have the disadvantage that it becomes more difficult/less obvious what is the right id to link to it. --Most2dot0 (talk) 09:17, 17 August 2025 (UTC)

"Events" were used so far to achieve a grouping, to look up further performances in the same context as given performance, and to give that context a meaningful name. So let's use "Context" at least as the working title for this usage. Context can have categories with hierarchies, and can be meaningfull on different levels. E.g. Festival / Kongsberg Jazz Festival / 2016 / Gulljazz as the event category, and Norway / Kongsberg / Skavangertun (nursing home) in the location category. There is an issue, though: this can create many potential link targets, but for many it would not make much sense to create them. Wiki pages are static, so everthing that is linked to other database presentations, must have that presentation in place. But if wie stick to hierarchies, and sort the target pages according to that, we might be able to efficiently combine different grouping levels in the same table. We could then have the context column field with parts of such a hierarchie, e.g. "Kongsberg Jazz Festival / 2016 / Gulljazz", and each of the three elements could be clicked and yield a different link target: "Kongsberg Jazz Festival", "Kongsberg Jazz Festival 2016", "Konsgsberg Jazz Festival 2016, Gulljazz". The 2nd one would not lead to a "Context by year" table, but to an "All Context" table, where the year appear specifically in the hiearchie for the Kongsberg Jazz Festival. Now, the table generator currently only supports two grouping levels, so we might need to skip the top ("Festival") and buttom ("Gulljazz") levels for now, which were also in no way in use up to now. Though if want to have the top categorie, we could realize it by having seperate tables. And I would at first ignore the location category for creating links.

--Most2dot0 (talk) 19:41, 20 August 2025 (UTC)

Performance != video

Currently we acknowledge (in the structure of Data:SongsToVideos.json) that a song can have many videos associated with it and that many songs can be in a single video. But what about the fact that many videos can document the same performance (i.e., videos shot by different people at the same time)? How is that going to be handled? Seems like this will require another dataset (and a decision on a standard naming scheme for performances). - dcljr (talk) 21:19, 16 August 2025 (UTC)

The very first upload actually had the videos in lists, I changed that towards the first day of coding because of difficulties accessing the urls in construciton the computed fields configuration, but with the change comment "[...] Flattened structure, only one url per performance instead of video list (likely will be changed back later)". I was also contemplating before that we likely need to distigush between event related entries (like date), and video releates entries (like duration). Both should likely have sperate comment fields. I somehow reflected this, in that I put the duration entries after the url field in the JSON, but from the sementics, location doesn't matter. It's indeed preferable to seperate the videos from the events as you suggested. I discussed that idea already in the Common Database Structure section of my ideas: "Another table the would list recordings linked with the song title to the songs table, the event name to the event table, and with the URL to the video source info table." This Performances table is actually this "another table" that links the various information pieces, where songs and events primarily exist as indivdual wiki articles. However, there are some data pieces that can hardly be seperated strictly in performance and video releated, as a video can also hold several performances. So a comment like "duration" with values like "fragment" related to the combination of both. I guess the best way would be to thus have them in this Performances table, as it links both. It could be done by instead listing just urls (though they contain start/stop times already), have a list of structures: videos: [ { url: "<video1 url>", "duration": "fragment", "quality": "good"}, {url: "<video2 url>", "duration": "full", "qualtiy": "acceptable"} ] . Now, that makes access for many applications more complex than currently (regarding writing the configuration of the table, e.g. <videos[1].url> instead just "<url>" ). It coudl be aided by templates, or we keep the current flat structure for the first video, and list only additional videos in this style (when available). --Most2dot0 (talk) 10:04, 17 August 2025 (UTC)