Wikidata:Property proposal/film crew member

Originally proposed at Wikidata:Property proposal/Creative work

Motivation

Film crew members may assume numerous job titles. As per a previous discussion only the traditionally most important ones (those receiving a main billing) need their own property, for miscellaneous roles this property could be used. Also, this property could act as superproperty for the already existing ones. Should be used with qualifier (probably P794 (P794)). Máté (talk) 19:42, 18 July 2016 (UTC)[reply]

Discussion

•   Support. Thryduulf (talk) 22:19, 18 July 2016 (UTC)[reply]
•   Question What's specific to cinema here ? We would another similar property for Opera ? Not sure this proposal is mature. author  TomT0m / talk page 18:33, 23 July 2016 (UTC)[reply]
  • @TomT0m: opera (Q1344)'s are pretty well covered by composer (P86) and librettist (P87). Normally, they are the only ones contributing to it. If you mean a theatrical production (Q7777570), yeah, there may come a time when we need a catch-all property to cover the leftover tasks, but nor are there many items about theatrical productions (only nine items are defined as such right now), nor am I sure that a programme (Q1508646) would consist that many different job titles that we wouldn't have separate properties for them (as opposed to motion picture credits (Q4458345)). However, I wouldn't like to see a common generic property for the two industries, as they are too different in nature, and where there are similarities they are already mostly covered by the specific properties. On the other hand, if that is the only thing that would stop this property from happening, I wont force my opinion. – Máté (talk) 18:55, 23 July 2016 (UTC)[reply]
    • @Máté: I'd have the opposite point of view : there is no real need for specific properties if it adds no value. I think you're totally wrong for opera as the item : an opera is produced, certainly, but the essence of opera is not exactly just the script and the music, it's the art of singing and the performance as well. We can see an opera as the class of all the performances. The big problem with creating specific properties then create a property for the leftover is consistency and duplication. A good generic property is better in what : the scheme is consistent and does not depends of local peculiarities for no good reasons, so it's easier to learn for everyone, and it's more easy for the coders to reuse their code. It's less messy. You don't have several ways to model things, one correct and the other possible but not recommanded. Thinking property by property is time consuming in discussions, encourage local peculiarities like "what, you do like this to enter the costume designer (Q1323191)      ? But we do like that ! Why should we have two ways, it's confusing. author  TomT0m / talk page 19:14, 23 July 2016 (UTC)[reply]
      • @TomT0m: Sorry, but you completely lost me with the last part. As for the first part: any item that is instance of (P31): opera (Q1344) needs not production specific credits (hell, that would be chaos). I don't see how I could be totally wrong with that, as you claim. The item that has all the singing and performance is what is instance of (P31): theatrical production (Q7777570) (linked of course to the previous item). That is, Jesucristo Superstar (Q242667) should by no means have a cast member (P161) or director (P57) statement on it (only characters (P674), composer (P86) etc.), while Jesus Christ Superstar (Q23835864) should. That is what I meant, and I don't see how that's totally wrong. Since the property would have a clear industrial distinction (audiovisual), it would hardly cause any confusion. If we want as few properties as possible (for reasons mentioned above, but restricting ourselves in other ways, like not being able to build specific constrains or have larger control over the content), we can still change this into "personnel of creative production" that is usable for videogames (see above), theatrical productions, audio recordings, concert tours, as well as audiovisual works. (Creative crew would not cover non-creative personnel, and I couldn't come up with a better name.) For non-production works we already have creator (P170) as generic property. (I still prefer it as proposed, but not that emotionally invested.) (@Thryduulf:) – Máté (talk) 19:47, 23 July 2016 (UTC)[reply]
        • @Máté: We would still have the possibility to write specific constraint, it just take an "if ... then", and I wrote the code to do this. But constraints only to check that the domain is correct for this constraint are counter-productive, I mean to check that a cinema costume designer (Q1323191)      is used with the corresponding property, while theater one are used only with the respective equivalent property for theater is useless. One property with domain the domain agnostic occupation is enough, I can't imagine which actual errors that separating would catch. For opera, creation is a complex process usually and far not always industrially standardized. The creators can co-create live with the actors for example. I think it's not so easy to separate the script from the production, sometimes. author  TomT0m / talk page 19:58, 23 July 2016 (UTC)[reply]
          • @TomT0m: I think I see your point now about costume designers. In that case, there is already a common property (costume designer (P2515)), but I see the point. – Máté (talk) 20:19, 23 July 2016 (UTC)[reply]
•   Support Sounds like a useful property. I also wonder whether we could have a more general property, but I can't come up with anything better. --Srittau (talk) 21:57, 19 August 2016 (UTC)[reply]
•   Support --Pasleim (talk) 11:06, 20 August 2016 (UTC)[reply]
•   Done Máté: please make good use of it.
  --- Jura 11:27, 20 August 2016 (UTC)[reply]