Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Brand: No longer a sub-class of EditorialGroup? #231

Open
JuergenGrupp opened this issue Feb 10, 2023 · 5 comments
Open

Brand: No longer a sub-class of EditorialGroup? #231

JuergenGrupp opened this issue Feb 10, 2023 · 5 comments
Assignees
Labels
question Further information is requested

Comments

@JuergenGrupp
Copy link
Collaborator

The class Brand is currently a subclass of EditorialGroup.
I would pledge for defining Brand as a standalone class, directly under Thing. Reason: a Brand is not neccessarily an EditorialObject. It is a name and/or a signet to group products or services, in any business domain, not only in media.

@JuergenGrupp JuergenGrupp added the question Further information is requested label Feb 10, 2023
@JuergenGrupp
Copy link
Collaborator Author

From the editorial committee meeting: a brand is a category, not a group of editorial objects.

@JuergenGrupp
Copy link
Collaborator Author

Another observation: two properties "isSeriesOf" and "brand" should be renamed to "hasBrand" and "isBrandOf". "isSeriesOf" should be removed.

@JuergenGrupp
Copy link
Collaborator Author

JuergenGrupp commented Nov 27, 2023

After a few more discussions and examples, I would now keep the class 'Brand. Although I don't like the name very much. For my taste the name "EditorialBrand" would be better. But that is really not an issue.
The thing I learned is that Brand already expresses, what I wanted to express for a group of editorialObjects that are very similar in their "format". Eg. A daily news show like "Tagesschau" has 5 minute issues every hour from 7:00 to 15:00 h, a 10 minute issue at 17:00 h, a 15 min issue at 20:00 h and a 10 min late issue at around midnight. This could be represented as follows: Every issue is an episode of a series. The episodes with the same starting time might belong to a Series like "Tagesschau at 7:00" or "Tagesschau at 8:00", etc, and all of the issues with duration of 5 minutes belong to the Brand "Tagesschau compact". The 17:00 issues might belong to a Series "Tagesschau at 17:00" and a Brand "Tagesschau after work", the 20:00 h issue might belong to a Series "Tagesschau at 20:00" and a Brand "Tagesschau extended". All the Brands might be grouped into the main Brand "Tagesschau".
So, there can be a hierarchy of Brands grouping the series, seasons, serials and episodes.
The benefit of having different grouping mechanisms for the issues here is that we can apply them in different use cases and then link them afterwards. For instance, when examining the portfolio of offerings of a media enterprise, you would prefer to talk about Brands to express editorial concepts (or idea, format, ...?). You would associate genre, target audiences, publication patterns, etc with that and even group other Brands under it. On the other hand, when you use a publication planning system to populate channels and platforms with your content you probably prefer to talk about series and their publication slots.
To sum up:

  • keep the class Brand as it is (unless you vote for renaming it to sth. like "EditorialBrand")
  • isBrand should be renamed to hasBrand (EditorialObject hasBrand Brand)
  • isSeriesOf should be removed, as it is replaced by hasBrand
  • Brand is an EditorialGroup and can use "hasMember" to link to any EditorialGroup (like Series, Serial) or EditorialWork (like Programme)

Please comment!

@kimviljanen
Copy link

Hello dear editorial committee,

I would probably need a drawing to understand this better, but somehow I think that brand is a general business term and not (only) part of editorial domain. In many cases of course our brands are related to content (=editorial domain), but how about our channels and services -- they are typically really strong brands too* - maybe the strongest we have - but in the context of CCDM those brands are located in the Consumption domain. Finally, what about the company itself. It is also a brand.**

Footnotes:

  1. According to this year's national brand research, Yle Areena is the third most valued brand in Finland.
  2. Yle as a company is also high in the same research. (Cannot remember the exact position.)

@JuergenGrupp
Copy link
Collaborator Author

Thank you , @kimviljanen for adding your perspective !
After discussing this in the Editorial Committee, we concluded, that we need both meanings of "Brand":

  • the "current" Brand as a grouping of EditorialObjects, which is often also called an "(editorial) format".
  • and a class representing a "marketing sign", covering the meaning of Kim's description.

To distinguish the two easily, the first one will be called EditorialFormat and the second one MarketingBrand. The labels of the properties will be changed accordingly.

To sum up:

  • rename the class "Brand" to EditorialFormat and isBrand to hasEditorialFormat
  • insert a new class MarketingBrand
  • isBrand should be renamed to hasMarketingBrand and point to MarketingBrand ("EditorialObject" "hasMarketingBrand" "MarketingBrand")
  • "isSeriesOf" pointing to "Brand" should be removed
  • EditorialFormat is an EditorialGroup and can use hasMember to link to any EditorialGroup (like Series, Serial) or EditorialWork (like Programme)
  • Caveat: There's also a class ContentEditorialFormat as a subclass of Type which in turn is a subclass of skos:concept. Although the name is quite similar there is a huge difference: think of EditorialFormat as an EditorialGroup, that can be used everywhere an EditorialGroup can be used. And think of ContentEditorialFormat als a "Type of skos:concept" that can only be used as a type to an EditorialObject.

Happy to take further concerns or questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants