[Tagging] Feature Proposal - RFC - artwork_subject=sheela-na-gig

[Anne-Karoline Distel]

Thanks for your replies. Linking to subject:wikipedia and
subject:wikidata is supposed to help people looking up what they're
looking at, I always presumed. "oh, there is a plaque here about such
and such a person, I wonder what else they did apart from being born in
this house". I just checked, and not even the Kilpeck Sheela has her own
Wikipedia article, even though she is the example used everywhere
(because she was one of the first to be described by scholars, I
presume). The tags subject:wikipedia and subject:wikidata could be
automatically generated like it is done with brands, I guess.

I don't think it can be compared with linking to the wikipedia article
about water, because everyone has a fair idea what water is and the
numbers of features tagged with natural=water and the potential
artwork_subject=sheela-na-gig are quite different.

I agree that the artwork_subject key is a mess, but that is an argument
I have heard for several of my proposals, and just because I became very
active on OSM when there was a mess already cannot mean that my
proposals should be rejected.

I'm also not a fan of key=yes tagging, when there is no key=no option.

Anne

On 08/03/2022 09:06, Mateusz Konieczny via Tagging wrote:
>
>
>
> Mar 8, 2022, 09:54 by dieterdreist at gmail.com:
>
>     Am Di., 8. März 2022 um 09:17 Uhr schrieb Mateusz Konieczny via
>     Tagging <tagging at openstreetmap.org>:
>
>         Using both
>
>         artwork_subject=sheela-na-gig
>
>         and
>
>         subject:wikidata=Q509424
>         subject:wikipedia=en:Sheela na gig
>
>         seems to be not needed for me.
>
>
>
>     this is (or should be) generally the case for all "...wikipedia"
>     and "...wikidata".
>     Our data should be self contained (not sure if this is the right
>     term, I mean that the semantics should be clear without having to
>     use another database in order to make sense of it).
>
> species:wikipedia / taxon:wikipedia and its wikidata variant is at
> least helping
> with being linked to specific species while species / species:en /
> species:pl etc
> are often having massive number of synonyms, variants etc.
>
> The same for vehicle:wikipedia/vehicle:wikidata where vehicle type/model
> is not really appearing in name and parsing description would be a
> nightmare
>
> But in this case it is like linking "Water" page on every single
> natural=water
>
>     There doesn't seem to be a conceived system behind the
>     artwork_subject in general
>     https://taginfo.openstreetmap.org/keys/artwork_subject#values
>     the second most used value, "religious", has potential overlap
>     with all the other values (and could possibly be expressed with
>     the standard religion=* tag), although with some few it may be
>     less likely (e.g. lgbtq). There are only 3800 objects with this
>     tag, and you cannot see yet where it may evolve to. The
>     documentation is a bunch of referrals to wikipedia, so that they
>     will change by the time without us noticing in the OSM-Wiki
>     https://wiki.openstreetmap.org/wiki/Key%3Aartwork_subject
>
> I agree, though my conclusion would be "and therefore this tag should
> be avoided,
> using some other scheme that will not be very likely to be problematic
> in future
> should be preferred"
>
>     IMHO not. It would not provide context unless you knew what
>     "sheela-na-gig" was, better put it in the value.
>     If you wanted to use sheela-na-gig as a part of the key, why not
>     sheela-na-gig=yes?
>
> It also works for me.
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20220308/cff506a2/attachment.htm>