[RFC] Adding Page ID as a valid and preferred way to link to Wikimedia Commons

General talk Tagging general discussion
,
1

Please see the proposal here, it is short but significant so I would like a formal proposal process:

https://wiki.openstreetmap.org/wiki/Proposal:Wikimedia_Page_IDs_in_OSM_Tagging

Please discuss here or on the proposal wiki page.

2 Likes
2

Gallery pages at Wikimedia Commons are almost always poorly maintained, poorly selecting images from categories and are just extra barrier to get to a category.

If not abandoned altogether.

I am strongly against linking to them and as I understand this would enable linking gallery pages instead only categories and images.

also, I am strongly against replacing human-readable form with digit gibberish

replacing file name/category name with gibberish like 7448262468 seems a clearly bad idea (took random digits)

also, it would break existing data consumers

9 Likes
3

BTW, please notify known data consumers listed at wikimedia_commons | Keys | OpenStreetMap Taginfo if you would want to proceed with the vote, to give them opportunity to comment.

Probably best wait few days whether you want to continue, but please notify them at least multiple days before vote to give them to chance to comment in RFC.

1 Like
4

I’m an active contributor to both OpenStreetMap and Wikimedia Commons, and I don’t support this proposal.

The current syntax is simple, human-readable, and easy to validate. For example, by checking for values that don’t start with “File:” or “Category:”.
The Everest is not the best example: that case doesn’t even require a wikimedia_commons tag, since relevant media can already be retrieved via Wikidata. If a file is notable, it usually has its own category, if it’s not, it likely doesn’t need multiple files being listed under one tag.

Imho this proposal tries to solve a non-problem, offering limited real benefit. On the other hand, it would complicate things.

5 Likes
5

Also, with current schema it is simple to add tag. With new one you have an extra step.

1 Like
8

it WILL break all existing data consumers of this key as they would need to add this API calls to already existing process

this does not change that some now valid entries would require extra support to handle

it is entirely doable by linking categories and files instead

Wikidata items have no single human-readable unique value (though some communities expect wikipedia tags to be present whenever possible)

Wikimedia Commons have unique human-readable identifiers

2 Likes
9

Absolutely will! Thanks for that!

10

All that would be required is to support both URLs, no API necessary (though easy to do if you’d like):

This is the crux of the issue this proposal aims to solve, if I am a casual mapper, I snap a few photos or find a few photos on commons of what I am surveying, I currently have to pick the best one, or I can go to a completely unrelated site, familiarize myself with how to create a category, create said category, go back to OSM, edit the element to add the category, and hope that I now don’t have to maintain a category on a site I never wanted to maintain.

With this proposal I can go “Oh, these 2 are nice” or if a mobile OSM editor (like Go Map) enables Commons uploading, several IDs can be placed simply without ever leaving OSM.

11

Frankly, I believe even adding a single photo to an OSM element is unusual. We are striving to be a geo database and not a picture book of the planet. Our role is to say, there’s a mountain in this location and this is the name of the mountain and its height is such-and-such. For anything else, if it needs to be recorded, let’s point to Wikipedia/Wikidata and be done with it.

Which image (of, in the case of Mt Everest, potentially thousands) to choose is an editorial process. Ask 10 people and you will get 11 different opinions. Therefore, choosing one or two or three photos of something and elevating them to the status of “photo featured on OSM” is not objective and potentially subject to disagreements.

Let’s not go there. It is bad enough that we feature photos at all; let’s not make this such an important thing that we have to change our tagging to allow for even more photos.

13 Likes
12

Photos of elements can be exceedingly helpful for users of our data and mappers alike. If OSM lacked any visual component, it truly would be a xml file hosted on a server somewhere that no one would contribute to beyond the nerdiest and techy among us (I certainly wouldn’t have joined if I was presented with a pure XML.) We should aim to expand our userbase, usefulness, and attract new contributors and in a multimedia world, that also means supporting multimedia. If you don’t want to add photos to OSM, that’s fine, but that shouldn’t stop others and shouldn’t stop the improvement of such if an issue is found (like in the case this proposal aims to solve.)

Edit to add: This is not meant to be a debate about if photos should be linked in OSM, they are, this is a proposal to make them better.

3 Likes
13

in other words it would require change from data consumers to support new tagging style

that is what I mean by “it WILL break all existing data consumers”

including all editors supporting adding this tag

requiring change from existing data consumers is what I meant “it will break them”. With implicit, “unless they would change their processing of OSM data”.

1 Like
14

I really think this is trivial to add as a developer:

IF value starts with a letter, use https://commons.wikimedia.org/wiki/$1
IF value starts with a number, use https://commons.wikimedia.org/w/index.php?curid=$1 and delimit by semicolon.

I will happily reach out to any and all data consumers of this key if approved to get them this IF statement.

15

I have not argued for removing the map so please don’t make it sound like I had.

This is a non sequitur. Expanding our userbase is fine, but that doesn’t mean that just because we live in a $SOMETHING world we now have to support $SOMETHING.

There’s a lot of things that are going on in OSM; but a lot of what is going on is somewhat orthogonal to our purpose. Every time someone wants to “improve” such a non-geodata use of OSM, it is worth taking a step back and asking, where does this lead - is it where we want to be? Will it give us “mappers” whose only contribution is plastering everything with photos (that they are automatically retrieving by script via an existing wikidata link of course)? Will it give us disputes between these “mappers” because they can’t agree which photos to use? Will it lead to calls to embed such photos in the OSM website (“because we live in a multimedia world”)? Will the photos be followed by films (“because obviously multimedia is already in OSM, we’re just making it better”)?

I remain unconvinced.

5 Likes
16

We already have these tags for images

  • mapillary
  • image
  • wikimedia_commons
  • panoramax
  • kartaview
  • and so on


This really isn’t a debate on if images should exist around OSM, they do already.

1 Like
17

Turning back to the problem statement in your proposal:

This solves the issue of multiple images representing the same OSM element, such as when a large feature (such as a mountain) has many angles that may want to be captured. Currently, this relies on a contributor or data consumer to create and link to a single category in Commons, which may not show the entire picture (such as “[Mountain] from [Nation]” categories where multiple would be valid and useful)

A “Category:Mountains in country” represents a broader concept than a particular mappable feature. The wikimedia_commons=* tag needs to be more specific: “Category:Mountain Name”. If such a category doesn’t exist, you can create it or omit the wikimedia_commons=* tag.

Personally, I very rarely tag wikimedia_commons=* in the first place. Instead, I set the feature’s wikidata=* tag to the QID of a Wikidata item representing the feature, then set that item’s image (P18) property to the name of the file on Commons. Wikidata also has a variety of other properties that link to Commons, such as Commons category (P373) and Commons gallery (P935) for when no one image is unquestionably the feature’s most representative image.

If Wikidata doesn’t have an item about the feature yet, you can add one. Under Wikidata’s very lax notability rules, the item is guaranteed to be notable because it has one of these statements linking to Commons. For many classes of concepts, such as buildings, hotels, hiking trails, monuments, and campsites in Sweden, the Wikidata community has created a tagging schema that enables you to create the item easily by filling out a simple form.

When would I use wikimedia_commons=* alone? When the feature is so obscure that I’d feel really silly for making a dedicated item about it, like an ordinary trash can on the sidewalk or this quirky traffic sign that has a single usable image and nothing more to say about it.

Commons isn’t quite comparable to other image hosting sites or the image=* key, because it’s part of a system of Wikimedia projects that uses the QID as a persistent identifier, as the single entry point to Wikimedia from an external database such as ours. We mappers can easily verify that the QID is correct by viewing the wikidata=* tag on the main OSM website. And for OsmAnd users and probably others, this is just an implementation detail: they just see the photo or photo gallery.

11 Likes
18

Hi @Minh_Nguyen, as always great insight!

Specifically this came from the Wiki talk page, surrounding the same mountain from different sides but that was just one example. “If such a category doesn’t exist, you can create it” - yes, and I think us active contributors would be comfortable with such. I don’t think asking a casual mapper to jump through not only uploading but also categorization on a separate website just to add 2 photos to a OSM element is something they’d have any interest in doing. I think of any of my non-OSM friends, if I asked them to do that they’d simply refrain from adding a photo, which makes something that could’ve been helpful to both projects now helpful to neither.

This still has the new user issue. If I asked a casual mapper to do this, they’d think I’m reading them a foreign language. We understand it and it is technically excellent, but not at all easy or intuitive. What is is saying “hey snap a photo on this OSM app or find a file you like and click ‘Page Information’ to get the ID”.

Granted, I didn’t have a Commons link but Ive tried to add things to Wikidata before like bank branches and Coffee Shops and they got deleted for not being notable. Maybe that just left a sour taste in my mouth but I can’t imagine if I said “this dog excriment bag dispenser should have a wikidata item” that Wikidata would accept that. Panoramax does and it was really easy with Go Map, I would love if that same ease was applied to Commons with the ability to add multiple photos.

Do they? I tried looking for a QID first and found the Page ID as their form of a UUID within Commons.

19

Commons already strongly encourages you to categorize a photo when uploading it to Commons. Categorizing a file helps to protect it against deletion. Third-party tools that integrate with the Upload Wizard can pass in categories and also create them on the user’s behalf using the REST API or Action API.

The concept of a MediaWiki page ID is obscure even to experienced Commons contributors. Even on Wikidata, which loves numbers, there’s been a long-running debate about whether properties referencing other MediaWiki wikis should refer to MediaWiki page IDs or pretend that article titles are good enough as persistent identifiers.

It sounds like you’re only considering a data consumer that links out to a file description page or embeds it in an iframe. But most data consumers actually want the raw image file or a thumbnail of it. If you really need to link to a page ID despite the caveats, you can already technically tag, for example, wikimedia_commons=Special:Redirect/page/111350608. No proposal needed, but don’t expect any software to do much with this tag.

It’s actually fairly annoying to programmatically access the image file given a page ID, and even more annoying to get a thumbnail. The wikimedia_commons=* key namespaces file names with File: in order to distinguish them from galleries and categories, but data consumers have to trim that out in order to look up the actual file. None of the example Sophox queries for Commons files or corresponding QLever queries can conceivably work with page IDs without lots of fragile gymnastics.

That’s a fine use case for wikimedia_commons=*, but I don’t see it as a strong argument for a number versus a file name. If you’re concerned about the potential length of the tag value when using file names, keep in mind that the goal isn’t to list all the available photos depicting the feature, or even all the photos that portray the :poop: box in the best possible light. The key is only meant to provide something that a basic data consumer can present to the user, better than nothing at all.

As far as MediaWiki is concerned, the canonical identifier for a file is its file name. If a file gets renamed without leaving a redirect, every wiki page that includes the file needs to get updated, because the wikitext syntax for inserting an image names the image. Fundamentally, the page ID you’re referring to only pertains to the file description page, not the file itself. A file can have multiple description pages, one per wiki.

For semantic information, Commons is currently undertaking a massive effort to tag files with structured data including depicts (P180) statements that link back to Wikidata, so Wikidata wouldn’t even need to link to Commons. Instead, an application such as OsmAnd would only need to make one API call to the Commons API for depictions of Chicago Union Station based on the wikidata=* tag’s literal value, and they could further fine-tune that query based on a variety of other criteria the developer determines on their own.

Because this structured data system is built around RDF, a file does have an entity ID just like a Wikidata item, for example, Chicago union station hall.jpg (M20159149). You can map an entity ID to its page or its metadata in JSON format. But this ID isn’t exposed publicly outside of an API, because ordinary end users are supposed to use the file name. It’s similar to how OSM canonically identifies its users by UID but only exposes the user name for most purposes.

8 Likes
20

Rather than this proposal, which has the problems already well expressed, I think the (admirable) goal of making it easier for casual mappers to contribute images of features they see would be better addressed at Commons/Wikidata.

For the usecase of a casual contributor with an image of a place that they want to contribute, one very important initial question is: Does the place already have a Wikidata entity? If it does, then the discussion of whether it’s notable enough has already been agreed (at least, so far), and it would be useful to make it as easy as possible for the contributor to upload their photo and associate it with the entity, as well as (assuming the photo is geotagged), make sure the entity (and OSM) have (close enough) matching coordinates for the feature.

However, if the feature doesn’t yet have an entity, before the contributor can provide their photo, they need to make a sufficiently convincing case that the feature does meet the (very low, but still present) notability criteria for Wikidata. While there’s certainly useful work to be done to make that easier, I’m not sure that it’s really something that a particularly casual contributor will want to bother with, no matter how easy it is.

And none of this suggests a need to alter the semantics of the wikimedia_commons tag at OSM. But please do work on making it easier for people to contribute images of existing Wikidata entities (and get them bidirectionally linked to OSM)!

1 Like
21

In case you haven’t noticed yet, OpenStreetMappers will debate if they want to. And they frequently do! Good luck trying to stop them :smile:

7 Likes
22

I am a casual contributor to both Wikimedia and OSM. I am going to sidestep issues related to the mechanics of this proposal. But being able to link individual OSM elements to multiple photographs and other classes of image on Wikimedia would seem useful.