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)
- One other thing to consider is, that this is the performances list, so describing in great detail the different aspects of the place and circumstances might not be the best and most efficient way to do so. E.g. like having the location/venue in each and every song entry for her two Vegas concert. In regards to the context hierarchy, we could (as you suggested) have different fields for the different types, like "festival": "Kongsberg, "year: 2016", "gig?": "Gulljazz", and "show": "Allsang pa Grensen", "year": 2016, "episode": "1". But it's a high effort to explain the different fields to users, and to write code to combine them in the intended way, which would need to be adopted once another field type is added. A more flexible approach would be to have this stored as a list, e.g. "context": [ "Festival", "Kongsberg Jazz Festival", "2016", "Gulljazz" ], ["TV Show", "Allsang pa Grensen", "2016", "Ep. 1"], or [ "Concert", "Summer tour", "2017", "Kurbadhagen" ]. I might even skip the first list item for the sake of brevity, leaving that categorization to any wiki article about that context, which would have the name of the 2nd list item, possibly via a redirect. --Most2dot0 (talk) 16:24, 21 August 2025 (UTC)
- I have a working prototype for the list based approach ready at User:Most2dot0/Performances-devel. All pages/modules involved have "-devel" appended, and where possible in my user space. Initially I copied the each event entry to item one of the context lists. I splitted them for some examples, e.g. Kongsberg Jazz Festival, Allsang pa Grensen, and summer concerts 2017 and 19 (so I did not yet include the ÅrsteinØYA 2019). For Kongsberg 2016 I implemented a 3rd level for the three different gigs. I haven't checked it, but I assume IDs get no longer duplicated here. The "All events" table has the IDs for the to level (I tried to integrate deeper levels, but I think that ID generation doesn't work with the multiple links in the field; possibly we should remove that grouping here, and have the starting letter of event madness as highest level). It has up two the different links, going to wiki pages (or sections via redirect) for the series, the year, and the various gigs (in 2016), see e.g. User:Most2dot0/Performances-devel#Kongsberg_Jazz_Festival. The "All songs" table links to this table for the event series, and to the "Events by year" table for the 2nd level. See e.g. User:Most2dot0/Performances-devel#Ev'ry_Time_We_Say_Goodbye (please ignore the missing video links there, there's another trial for video lists prepared). I'd like to have your feedback on this before going much further. --Most2dot0 (talk) 10:28, 22 August 2025 (UTC)
- I added a 3rd level to the songs table, and I splitted all context entries, that ended with a year, into two levels. Turns out there in at least on occasion are still duplicate ids, as the year indication in the context is not necessarily the same for all the songs it contains: the New Year concert 2017 has rehearsals from 2016, so that get still split into two with different ids. And same is likely true for some others, that were prevously in the "spread over years" table. That would only be solved, if the 2nd level context would ensure in all cases that it only targets on year, otherwise we need to rework the jump anchors, they should probably not be contained in table grouped by years. --Most2dot0 (talk) 20:22, 23 August 2025 (UTC)
- I have a working prototype for the list based approach ready at User:Most2dot0/Performances-devel. All pages/modules involved have "-devel" appended, and where possible in my user space. Initially I copied the each event entry to item one of the context lists. I splitted them for some examples, e.g. Kongsberg Jazz Festival, Allsang pa Grensen, and summer concerts 2017 and 19 (so I did not yet include the ÅrsteinØYA 2019). For Kongsberg 2016 I implemented a 3rd level for the three different gigs. I haven't checked it, but I assume IDs get no longer duplicated here. The "All events" table has the IDs for the to level (I tried to integrate deeper levels, but I think that ID generation doesn't work with the multiple links in the field; possibly we should remove that grouping here, and have the starting letter of event madness as highest level). It has up two the different links, going to wiki pages (or sections via redirect) for the series, the year, and the various gigs (in 2016), see e.g. User:Most2dot0/Performances-devel#Kongsberg_Jazz_Festival. The "All songs" table links to this table for the event series, and to the "Events by year" table for the 2nd level. See e.g. User:Most2dot0/Performances-devel#Ev'ry_Time_We_Say_Goodbye (please ignore the missing video links there, there's another trial for video lists prepared). I'd like to have your feedback on this before going much further. --Most2dot0 (talk) 10:28, 22 August 2025 (UTC)
- One other thing to consider is, that this is the performances list, so describing in great detail the different aspects of the place and circumstances might not be the best and most efficient way to do so. E.g. like having the location/venue in each and every song entry for her two Vegas concert. In regards to the context hierarchy, we could (as you suggested) have different fields for the different types, like "festival": "Kongsberg, "year: 2016", "gig?": "Gulljazz", and "show": "Allsang pa Grensen", "year": 2016, "episode": "1". But it's a high effort to explain the different fields to users, and to write code to combine them in the intended way, which would need to be adopted once another field type is added. A more flexible approach would be to have this stored as a list, e.g. "context": [ "Festival", "Kongsberg Jazz Festival", "2016", "Gulljazz" ], ["TV Show", "Allsang pa Grensen", "2016", "Ep. 1"], or [ "Concert", "Summer tour", "2017", "Kurbadhagen" ]. I might even skip the first list item for the sake of brevity, leaving that categorization to any wiki article about that context, which would have the name of the 2nd list item, possibly via a redirect. --Most2dot0 (talk) 16:24, 21 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)
