View source for Help talk:ToDo notes

== Previous content and structure discussions ==

This is a collection of discussions and questions that have been resolved, for future reference.

===[[Item:Q763]], [[Item:Q897]] and others===
I wonder if we should not add in some titles "principles of" ... [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 16:26, 22 July 2024 (UTC)

It's a temptation I'm actively trying to resist. "Basics of", "principles of", "fundamentals of"... could be added to most items. I agree it's important to give a proper and precise idea of scope and not imply one needs a ph.d. in all of those fields, but as long as we clearly define the scope through knowledge and skills, I prefer short and assertive titles. Let's look out for clear scope and for erroneous implications like the one I had made in "Safeguard artistic quality" ([[Item:Q672]], now fixed) instead. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 16:42, 22 July 2024 (UTC)

I agree we have to be carefull with this, but for example hearing physiology [[Item:Q900]] is clearly not what a doctor or hearing specialist would understand under it. Moreover there is almost everywhere "has heard of in the knowldge detail. There I would use your temptation. [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 20:53, 22 July 2024 (UTC)

For the hearing physiology example I agree and have changed the text accordingly. For clocking, basics don't cut it, it's an all or nothing issue. For artistic concepts, well, it's kind of an abstract skill anyways that's difficult to measure. I'd aim high in this case. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 19:11, 26 July 2024 (UTC)

===[[Item:Q889]] and others===
In some cases the title became unclear without the prefix / code. I added in some cases a clarification. (I left the German untouched for your reference.[[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 16:29, 22 July 2024 (UTC)

Ah, I misunderstood your intention here, I thought you just wanted to unify the various syntaxes (such as EL or PR or Digital Systems), not remove the prefixes altogether. I think we do need some sort of prefix for the time being unless the interface allows us to first choose a field and then a subfield with a two-layer dropdown. Until that happens, I actually prefer "Acoustics / Practice" over "acoustics practice" because it makes that hierarchy explicit. Now I find it really difficult to know what to type into the field to find the desired knowledge subfield, and constantly have to refer to a knowledge field list in a separate window.
Is a two-layer dropdown field/subfield even feasible? If not, should we keep consistent and written-out prefixes for now? I can do that if you want. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 16:47, 22 July 2024 (UTC)

Oeps, I read this only now. I removed already most of them. You can see the drop down structure at https://competencebase.eu/wiki/Item:Q36.
For most that seemed to be less clear I found a rather elegant solution in the naming I think. But I kept out of the real tech sound ones. [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 18:57, 22 July 2024 (UTC)

With "drop-down", I mean we need something in the item forms, so that it is possible to find knowledge blocks easily while editing/translating/proofreading. That is a bit messy right now, I have to look it up at the link you mentioned, and then type the beginning of the name. Until that is fixed, I would rather have the name of the field redundantly included in the subfield, separated by a "/" or similar. Yours is better in terms of data hygiene (which I usually favour), but at this point it has usability issues. Could you accept the redundancy for now, at least until the editing and reviewing dust has settled? If yes, I'd restore the status quo ante. For a person who browses later it's not so bad, just for editors. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 19:58, 22 July 2024 (UTC)

In any case, we would need a name that is distinctive when the coding is out. I can ask Jan to add the codes + Label in the "also known as". You can then type the code and see only the ones in that part.I made an example: You can try typing "AR MU" in a [knowledge] property. [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 21:08, 22 July 2024 (UTC)

==== Read musical score ====
Don't we need a competence "read musical score" ? (see http://data.europa.eu/esco/skill/d60f6482-39b0-4a8d-acdc-ac26fbe5fca7 ) [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 21:13, 22 July 2024 (UTC)

We had decided that it is out of scope at level 5 for a sound operator. This is something that requires many years of musical training, which should also be reflected in pay grade at some point. So level 6 the earliest, and then also as an optional competence. In Germany, if you want score-reading skills, you have to be willing to pay a level 7 Tonmeister. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 09:41, 26 July 2024 (UTC)

=== Knowledge field documenting vs production management===
We do have a knowledge field documenti,g and also a knowledge field production - production management. I think it would meke sense to move the knowledge under documeting to production management. [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 19:13, 22 July 2024 (UTC)

Agreed, and done. That also means that [[Item:Q882]] and possibly [[Item:Q860]] are due for recycling (unless you plan to use them in other contexts), but since the recycle option dropped a SPARQL request on me, I got scared. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 19:18, 26 July 2024 (UTC)

===[[Item:Q763]]===
This was copied from ESCO. I changed it to Level 5 (was 3), copied the DE translation from ESCO, and amended the description to include "and support the artistic process by technical means or, if desired, creatively", to differentiate from the original level 3 competence. Ok? [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 22:08, 21 July 2024 (UTC)

CVG: I would make it: "Interpret an artist's explanation or demonstration of their artistic concepts, inceptions and processes '''in order to'''  support the artistic process by technical means or, if desired, creatively." (It is about the understanding, but the expected result makes it a level 5. [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 14:50, 22 July 2024 (UTC)

Agreed, and applied. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 16:19, 22 July 2024 (UTC)

===[[Item:Q790]]===
Added "and emotion-driven behaviour", because that is often key for understanding conflict situtations. Ok? [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 22:08, 21 July 2024 (UTC)

CVG: think that is a good addition indeed! [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 14:51, 22 July 2024 (UTC)

===[[Item:Q826]]===
If we don't make it sound-specific, take it out and refer to the generic ESCO one instead? [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 22:08, 21 July 2024 (UTC)

CVG: we updated it to level 5 in the content, so I would leave it in. [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 14:51, 22 July 2024 (UTC)

Agreed. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 16:19, 22 July 2024 (UTC)

===[[Item:Q825]]===
Upgraded to level 5 and made specific to production intercom systems. Ok? [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 22:08, 21 July 2024 (UTC)

CVG: I think it is a good idea to update to level 5. But I think we shoudl keep it open in which systems it will be integrated (could be also video, the house system, the emergency communication system, ... I would propose to generalise in the title and give more detail in the skills and knowledge elements. (for example add signal routing to the knowledge) [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 14:51, 22 July 2024 (UTC)

I agree to your point about openness to related systems - in fact the current wording does include or allow for all the additional interpretations your suggested, and the title is still in the generic format. I've added your suggestions to the skills and knowledge. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 16:19, 22 July 2024 (UTC)

===[[Property:P58]]===
Changed definition from "example" to "content", as that is how we are using it. No other projects should be affected. But it means that the Dutch translation needs to be amended. Anyone? [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 07:17, 22 July 2024 (UTC)

CVG: Ok, updated the translation in Duch [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 14:51, 22 July 2024 (UTC)

===[[Item:Q903]]===
Here's my take on the sound/ear training: [[Item:Q864]]. If you feel this is going in the right direction, please update the Dutch translation, and then also for [[Item:Q903]] and [[Item:Q904]]. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 18:58, 22 July 2024 (UTC)

Looking deeper into this, I have the idea we do miss a crucial competence, which is hard to describe, something like "apply an absolute and selectif hearing" or "develop a absolute and selectif hearing". Listening in this way would be a skill, that is supported by as well the knowledge blocks you mention as the ones under ART - Music. Maybe we should write this skill first and then see what knowledge is needed? [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 20:38, 22 July 2024 (UTC)

===[[Item:Q671]]===
I don't get the point of this competence. It would be useful if we understand it as "make sure it's there", but ESCO uses it in a very indefinite manner - if we use it likewise, we have it covered by numerous other competences. Remove from profile, or make more specific? [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 22:08, 21 July 2024 (UTC)

CVG: The number was wrong (30 at the end), I updated it.
CVG: I see this more like a planner that ensures everything is there. But the content does not reflect that completely (see also the TeBeVat version Q385) I don't think it is sound specific, but someone has to do it? Question is if we use it, would it simplify the other competences, where it is probably repeated several times? Worst case I would move it to optional, but the question remains, if this is not done, will there be a show? [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 14:51, 22 July 2024 (UTC)

To me, the way it is described in ESCO, it's purely a producer's or artistic director's task with mostly economic connotations, and not at all a job for the sound engineer, not even optionally. We have taken care in other planning-related competences to cover both things that are covered by the planner personally, and things that third parties will provide but the planner is responsible for ensuring, so that aspect of the original skill is covered. We have a few that are dealing with related issues but in more specific way: [[Item:Q660]] [[Item:Q662]] [[Item:Q736]]
I'd argue to remove, or to take out economic aspects completely and move it towards "take responsibility that all needed sound, sound logistics and sound crew resources are there, even if subtasks are delegated to other people", a bit more like the TeBeVAT version. What do you think? [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 16:19, 22 July 2024 (UTC)

In a Belgian (and I guess also Dutch context, it would definately be the sound person responsable for the production who would coorinate the resources (be it that the financial means would be minimal. He/she would talk to the vennues, the providers and the other services to ensure there are enough people and equipment to run the show. We could adapt to "Coordinate and negociate human and material  resources within artistic productions."[[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 19:08, 22 July 2024 (UTC)

In this case, I would like to remove "artistic", because it applies to industry events in just the same way, and I would say it's an optional competence for the sound specialist. Instead, I would make sure that things like crew, logistics and other auxiliary resources are clearly mentioned in the planning competences we already have - I guess we're already pretty good, but I'll double-check. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 20:01, 22 July 2024 (UTC)

Removing artistic without replacing it would get confusion with other industries. What about "organise resources for performing arts and event production"? To be honest, I would go the other way, removing these things in all the other competences, because they will double up several times.  [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 20:43, 22 July 2024 (UTC)

I thought long and hard about this, the original intention of this competence is for a producer-like skill in a film or theatre environment, as is evident from the word "script". Changing it to what you have in mind would change the underlying concept, so I'd advocate taking it out of ESSENCE entirely and create an entirely new competence like you suggest (or rather, edit this one and remove the ESCO backlink. I've done this here, let me know what you think: [[Item:Q671]] [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 08:07, 29 July 2024 (UTC)

===[[Item:Q672]]===
Changed definition to something closer to the ESCO original, but on a higher artistic level. Ok? [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 22:08, 21 July 2024 (UTC)

CVG: I am only wondering if we should limit her to technical problems, now it looks like the artistic quality is only depending on technical. If we leave technical out, it also could be timing or other issues. [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 14:51, 22 July 2024 (UTC)

I agree to your points and improved the wording, but wasn't able to reflect the "timing" and "other" issues, maybe those could be skills? I had trouble keeping it short, the point is: play along as if your own ass was on stage and fight for your artists. If you can nail that, please rephrase the item completely if necessary, I have writer's block here :o) [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 16:19, 22 July 2024 (UTC)

"Observe the show and the individual performers, to quickly identify and react to possible issues or provide tailored support to performers, to ensure the artistic result." ? [[User:ChrisVanGoethem|ChrisVanGoethem]] ([[User talk:ChrisVanGoethem|talk]]) 20:47, 22 July 2024 (UTC)

I've given it all I could within 250 chars. Yell if you're still unhappy. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 19:07, 26 July 2024 (UTC)

===Some drop-down menus are assigned wrong values/categories===
* With knowledge subfields such as [[Item:Q862]], try to edit "field". The suggested values seem to be TeBeVAT knowledge fields, not ESSENCE ones. I'm open to exploring unification potential, but we will need to restructure our own fields within ESSENCE. Example: [[Item:Q862]] Digital systems should not be in a field of its own, but needs to become a subfield of the ESSENCE field "sound". We could merge it all into TeBeVAT "sound", but their subfield structure is not sufficient for ESSENCE, so we would have to add our own subfields to their fields. [[User:JoernNettingsmeier|- Jörn]] ([[User talk:JoernNettingsmeier|talk]]) 18:51, 26 July 2024 (UTC)

=== terms to be explained/defined ===

==== hierarchy of knowledge ====
[Result of a discussion between Jörn and Chris]

* knowledge field (instances are items, DE: Wissensgebiet)
** knowledge subfield (instances are items, DE: Wissens-Teilgebiet)
*** knowledge unit (instances are items, DE: Wissenseinheit) (<- changed, was knowledge block before)
**** knowledge detail (a property of a knowledge unit, DE: Wissens-Detail)
***** knowledge content (a qualifier of the property "knowledge detail", DE: Wissensinhalt)