Proposal talk:Subject

Not redundant

I disagree that subject=* is redundant to flag:name=*: flag:name=* is the human-readable counterpart to flag:wikidata=*. There are plenty of obscure flags for which there's a subject:wikidata=* but no possibility of a flag:wikidata=* because the flag is too obscure. For example, this flagpole flies a non-notable flag design representing an athletic team that is notable. This is no different than how a non-notable plaque can commemorate someone who is notable: it would have subject:wikidata=* but not wikidata=*. Removing subject:wikidata=* would lose information. As long as it has subject:wikidata=*, subject=* should be allowed, because many mappers dislike "anonymous" Wikidata tags that aren't paired with human-readable tags.

Originally, flag:name=* and subject:wikidata=* were intended to be completely optional, only required for flags without flag:wikidata=*. But then name-suggestion-index added all these tags unconditionally for use in iD, so this distinction was lost.

 – Minh Nguyễn ^💬 19:09, 13 November 2021 (UTC)

I see, thanks for the heads-up! It would be great if this were better documented. For example, man_made=flagpole currently does not mention subject=* at all. I agree that every *:wikidata tag should have a corresponding human-readable tag. In any case I don’t think I would want to deprecate subject=*, precisely for those more fuzzy/niche situations that you mention. Please also bear with me, I just started brainstorming and researching this today! —— AlephNull (talk) 21:04, 13 November 2021 (UTC)

Thanks for adding these memorial/artwork examples. I think they help clarify the intention behind the proposal. More specific keys would be useful when it's necessary to distinguish between the feature's role as artwork versus its role as a memorial. There is an analogy to how a flag of one entity can be used to symbolize another entity. However, I think it would be inconvenient to have to make this distinction everywhere, especially since it could be a very subjective distinction in some cases, so I appreciate the more considered approach this proposal now takes. – Minh Nguyễn ^💬 21:09, 13 November 2021 (UTC)

Not just museums

subject=* is what the feature is "about", regardless of what the feature is. I think that's entirely appropriate, because otherwise we'd have a proliferation of keys for each kind of thing that can be about something. Contrary to the wiki page's older versions, the key has never been exclusively about museum subjects. The popularity of subject:wikidata=* underscores this point: if subject=* were a closed set of keywords in snake_case format, there would be no need for subject:wikidata=*. A lot of flagpoles have been mapped, but this broader use of subject=* certainly didn't start with flagpoles. The documented "common values" are lowercase, but then again, they aren't proper nouns, so I don't see any conflict with their broader use on memorials and flagpoles. That list includes values such as cinematography that have only ever been tagged on one or two features in all of OSM's history, hardly "common". Unfortunately, further improvements have been a contentious process so far. – Minh Nguyễn ^💬 19:29, 13 November 2021 (UTC)

Agreed and thanks for pointing me to that discussion! I’m partly thinking about the use-case of infoboxes/annotated maps. There it might be useful to have very specific namespaced version to show that info in a certain context. The looser information from the subject=* should also show up in such infoboxes, possibly in the form of related Wikipedia articles obtained from a Wikidata link. For example, a memorial might be about a specific person (memorial:subject=*) but a general subject=* tag could still link to other things related to the memorial (e.g. a relevant group that the person was part of). —— AlephNull (talk) 21:14, 13 November 2021 (UTC)