Don’t know yet. What’s important to me, and that’s why I am asking here, is that I would be filling a gap and not create the 10th iteration of a problem already solved / something which exists already.
Agree on the presets, maybe add them one by one as requests come in.
The simplest approach would be a version just for this park with map position hard coded and artworks preloaded.
More questions related to my sculpture park, I am afraid. 
Material=*
All sculptures are made of stone, but one group is of a specific stone which is of some relevance.
Should I hence use the specific type of stone, “Gauinger Travertin”, or stick with “stone” like for those where the actual type of stone is unknown?
I realize that if one wants to e.g. count all stone sculptures the “Gauinger Travertin” ones wouldn’t be found even though they are of stone. On the other hand, not being specific would miss an interesting detail.
Wheelchair
I noticed that other cluptures sometimes show a Wheelchair tag, I understand what it’s for and view it highly relevant for public art. Some of the pieces in “my” park are in the middle of a field, others right next to a road. Anything one needs to know when it comes to this tag?
Image Providers
My app idea above is coming along, I noticed that pictures are not only captured via a Wikimedia link but also with a service called panoramax, are there more like these I need to be aware and support?
By the way, to publish on GooglePlay Store I seem to need 20 testers with a gmail account, if anyone here is interested in helping along, please send me your email via a personal message.
According to the Wikipedia article you linked all of these sculptures are made of Gauinger Travertin, see
An dem vom Mitte September bis Mitte Oktober 2000 ausgerichteten Bildhauersymposionnahmen nahmen zehn Bildhauer teil, die alle den gleichen Naturstein bearbeiteten, den Gauinger Travertin.
I would tag this as material=stone + stone=Gauinger Travertin
wheelchair=* describes, if an object is accessible for a wheelchair user without external help, as described on the wiki page.
I am not familar whith Panoramax but it has been discussed in the forum earlier. There are also other image hosts like Imgur etc. which are linked occasionally.
As with metal, there are more specific tags than stone and it’s perfectly fine to use them, even if it means you won’t be able to find everything made of stone with as simple a query. material=travertine is tagged on 440 elements. There are a couple material=roman_travertine as well, but maybe something like material:origin=Gauingen would properly acknowledge the stone’s provenance without potentially fragmenting into very niche tags.
Thank you both! Very helpful comments.
The problem with different stone types is that there are tenthousands of it. Of course there is no limitation in using any type as value for material. The disadvantage is clearly that in many cases people without certain expertise will not know that one or the other value represents a stone type. That is why I favour the use of material=stone + stone=* which gives a clear indication which kind of material is specified. There are 268 uses of stone=* so far. Nevertheless I am aware that there are different opinions regarding issues like this one.
Not to be confused with stone_type=*. 
To be sure, fragmentation is a major downside to refining material=* inline. It places extra burden on data consumers and query developers to know about many obscure values, not just the most common ones. Besides material=*, a variety of keys have values that can be refined in place, such as denomination=*, cuisine=*, operator:type=*, sport=*, and surface=*.
What we really need is a reliable, interoperable mechanism for data consumers to learn that, for instance, granite (16,843 occurrences), sandstone (10,141) and marble (6,745) are each a kind of stone. It is possible to query Wikidata for this information, although a data consumer would need to avoid interpreting the results too literally, because Wikidata’s ontology isn’t always a perfect match for OSM tag definitions. In theory, a more reliable approach would be to query data items and Wikidata simultaneously using Sophox. Unfortunately, Sophox has a bug that prevents it from indexing data items. Also, many data items on the OSM Wiki lack an appropriate Wikidata concept (P12) statement, especially after the push to remove Wikidata from inboxes somewhat obscured this mechanism from users.
Regardless, the important thing is to tag the detail, not lose that detail just because of a disagreement about where to put it.
Looks like one of these simple things which get more complicated to more you dive into it.
And sometimes an origin name loses the origin and becomes a type, like an Emmentaler cheese which doesn’t need to come from Emmental
Sounds like tags should be hierarchical? Material->Stone->marble->red marble
But I guess there is a reason why they are not and not a decision for us to make anyway
Stone_type came up as the recommended tag, so I went with it:
stone_type=* is normally used to specify what a stone monument or memorial is representing (a cross, a code of arms, a bollard etc.) whereas stone=* is used to specify the stone material. Anyhow there is no fixed rule as usual in OSM tagging … 
The tags are hierarchical to some extent. The question is how specific to make them before relegating detail to some additional key. stone=* is relatively unpopular compared to a more specific material=* value, but that’s partly because few mappers have gone through the trouble of identifying the specific form of stone beyond some well-known generalities.
The reason I said “not to be confused with” is that stone_type=* is completely unrelated to what you’re trying to map. It apparently clarifies the purpose or form factor of a historic=stone, not its composition. Whoever coined this key was at a loss for words, so they went with “type”.
I see, well, in that case I’ll follow your suggestion 
And got two more questions if I may?
Fully understandable, I wouldn’t either, but in this particular case the stone is documented and it’s got some relevance as all artists had to work with the same material. So “stone=*” it is
I agree with you that the use of subtags is making queries more complex and I would not favour that in any case. To me it makes sense when a generic value like “stone” already contains all the information needed, without further specification, for instance when differentiating stone from metal, plastic or wood.
In cases where the generic value does not contain any useful information without further details I would not favour the use of subtags. Anyhow I think this is an issue for a separate topic (ending in one of those endless discussions probably).
… combined with a clearly structured and mandatory tagging system which of course would collide with the “open” approach of OSM.
I think this is mostly answered by the OSM wiki page about the wikipedia tag - see in particular the section about Secondary Languages.
Note that copyright status of these images linked to random hosts may vary, and only few will be freely licensed (and even there you may have trouble with getting license info)
so displaying all images linked in image tag is likely not a good idea (and image tag itself is also a quite poor idea)
as extra annoyance this may have extra legal barrier as Wikidata ignores databases rights (they can do, as project domiciled in USA). This can be a problem if you are in jurisdiction where database rights are a thing.
(unless I missed something and they decided to follow them to increase Wikidata reusability?)
you can query Wikimedia API (you can easily get list of matching pages in various languages if you query by given wikipedia article or wikidata id)
Fortunately, this is only about Wikidata’s links to key and tag description pages on the OSM Wiki. To my knowledge, all of these statements have been contributed manually to Wikidata under a CC0 license (particularly the ones returned by that query, which I personally added).
Regarding database right, I’d point out that the Wikimedia Foundation doesn’t assert database right over Wikidata and probably doesn’t qualify for it. Further, Wikidata linking to OSM Wiki articles in this manner is quite analogous to the OSM database linking to Wikipedia, which historically has not been perceived as a legal risk. But if anyone is concerned about this issue, they should of course consult their lawyer rather than listening to a random American.
the problem applies for Wikidata entries imported (in part or full) from databases covered by database rights
disclaimer: I am not a lawyer
The Wikimedia Foundation’s legal department has been advising contributors to respect other data sources’ collective works copyright (which is similar in the U.S.) as well as any applicable EU/EEA/UK database right since at least 2013. If you have concrete, actionable evidence of copyright or database right violations, you should contact the Wikidata administrators or nominate the items in question for deletion.
To be clear and come slightly back to topic, an example of the kind of item I was querying for is granite (Q3115353). Looking through the item’s history, the only things imported from other compiled works are interwiki links from other Wikimedia projects and a link to the Google Knowledge Graph. None of these links are relevant to the query, and the Knowledge Graph data was included by permission.
