Linking OSM objects to Structured Data on Commons (MediaInfo entities)

General talk
1

Update: My question is simple maybe a simple answer :smiley: yes or no
Question: Is there interest in supporting a dedicated tag for Commons MediaInfo entities?

Original post that gets to many odd answers from people eating :popcorn: … :smiley:

Today wikimedia_commons=* can reference either a Commons category or a file.

However, Commons has evolved since this tag was introduced. Every file now has a Structured Data on Commons (SDC) MediaInfo entity (Mxxxxxx).

Example

Question: Is there interest in supporting a dedicated tag for Commons MediaInfo entities?

A dedicated tag would make it possible to reference the MediaInfo entity directly, while keeping wikimedia_commons=* for its current purpose of linking to Commons pages (files or categories).

image
image1614×1356 197 KB

image
image1940×1720 395 KB

image
image1866×1614 239 KB

While the MediaInfo entity can be derived from a Commons file, storing the M... identifier explicitly allows consumers to access the structured metadata directly, without first resolving the file page, and provides a direct identifier for SDC-based workflows.

image
image1536×1024 346 KB

image
image1619×972 400 KB

cc: @pangoSE @belak

5 Likes
Proposal to add :robot: as a reaction to AI content
2

then link wikidata=Q136449748 and find SDC by that reference

any reason why that would not work?

3 Likes
3

About a year ago, there was a proposal to extend wikimedia_commons=* to accept the numeric MediaWiki page ID of the Commons page. The discussion also veered into using structured data on Commons, though without tagging it explicitly:

One challenge with relying on MIDs is that they’re fairly difficult to obtain. You have to know to look for it at the bottom of the file description page’s page information page (say that 20 times fast). But this is becoming the canonical representation of an individual file in some systems. For example, QLever can join OSM and Commons entities just like it can join with Wikidata. (The sdc: prefix corresponds to MIDs.)

3 Likes
4

any reason why that would not work?

Wikidata describes the thing; Commons SDC describes each media file. One Wikidata item can therefore have many Commons MediaInfo entities that depict (P180) it. An OSM object linked via wikidata=Q... can find all of those images through the shared Wikidata identifier.

image
image1536×1024 463 KB

One Wikidata item → many Commons images. Each image has its own MediaInfo (M…) entity with depicts (P180) pointing to the same Wikidata item.

1 Like
5

I agree that MIDs could be much easier to discover but I feel that is a UI issue why not when you in OSM click in Wikicommons picture get an UI with pictures to select from around the coordinates the object has … :smiley:

Today I normally use the “Concept URI” menu option, which links directly to the MediaInfo entity, for example:

“Concept URI” https://commons.wikimedia.org/entity/M11581906 → M11581906.json

image
image2144×1500 410 KB

The important point for me is that MIDs give access to Structured Data on Commons (SDC) and a queryable data model . That opens up possibilities that are difficult or impossible with plain file URLs, for example:

  • Easy machine readable the license type of the picture used in OSM by accessing the json file
  • Which freely licensed images depict this building?
  • Which images depicting this building were taken during the last year?
  • Which images depicting this building are aerial photographs?

Using the MediaInfo entity also avoids a long-standing ambiguity in OSM: should an image tag contain the Commons file page…

Using the MediaInfo entity also avoids a long-standing ambiguity in OSM: should an image tag contain the Commons file page…

File:Eiffel Tower from north Avenue de New York, Aug 2010.jpg - Wikimedia Commons’‘’

…or the direct image URL…

https://upload.wikimedia.org/wikipedia/commons/thumb/7/78/Eiffel_Tower_from_north_Avenue_de_New_York%2C_Aug_2010.jpg/960px-Eiffel_Tower_from_north_Avenue_de_New_York%2C_Aug_2010.jpg?_=20101229185435

960px-Eiffel_Tower_from_north_Avenue_de_New_York,_Aug_2010
960px-Eiffel_Tower_from_north_Avenue_de_New_York,_Aug_2010960×1847 393 KB

From my experience, the upload.wikimedia.org URL is not a stable identifier—it’s essentially a delivery URL that can change due to caching, thumbnail generation, or other implementation details. The MediaInfo entity (M... ) is the persistent identifier, making it a much better reference for interoperability between OSM, Commons, and other linked data systems.

1 Like
6

all of that seem doable with wikimedia_commons - especially the first one

and actually also when someone uses horrible image

or wikidata / wikipedia

you just have one more step to automatically resolve

7

A user script could be made to make it easy to copy the MID in the top of each page in Commons.

1 Like
8

Please explain and why is todays way better than using commons structured data directly its like we should stop using the wikidata tag as you can also get the same thing done with Wikipedia article names? I guess everyone understands the benefits of Wikidata…

9

I was responding to

claim that was straightforwardly false. There may be benefits to using those MediaInfo entities rather than wikimedia_commons or linking object with wikidata=

but say “Easy machine readable the license type of the picture used in OSM” can be also done when file is linked via URL to Wikimedia Commons page. Getting Wikimedia Commons file name from URL is not so hard. And definitely not impossible in general.

10

OK, then what this new way brings what wikimedia_commons= and wikidata= / wikipedia= do not offer already?

Luckily Wikimedia Commons editors do not change file pages as a hobby, unlike what happens with article pages where stability can be quite poor. So this benefit is quite tiny and readability and new duplicative tagging schema headache are still present.

11

See the problems above we see with what is the correct linking where the upload url is nit stable and the linking to the Category page is not a straight forward way of access just the picture.,..

As Wikicommons moves in direction structured data I feel OSM should be in synch and follow…

12

how that is a problem for wikimedia_commons= and how this new way of linking makes things better over wikimedia_commons= and wikidata= / wikipedia= ?

(except better handling of very rare page moves affecting wikimedia_commons= where redirect was mistakenly not preserved)

13

wikimedia_commons=*, wikidata=*, and wikipedia=* already solve many important use cases. I don’t see SDC MediaInfo entities as replacing them, but rather as adding another layer of structured interoperability.

Looking at the history of Wikidata, we’ve seen how a structured data model enabled growth from a small project to over 100 million entities connected by more than 6,000 external identifier properties. That ecosystem has made it much easier to link data across projects and organizations. I think Structured Data on Commons (SDC) has the potential to follow a similar path for media.

The difference is that wikimedia_commons=* points to a Commons page, while an SDC MediaInfo entity identifies the media item itself as structured data.

Some of the benefits are:

  • Stable identifiers for individual media items.

  • Machine-readable metadata (JSON/RDF) instead of parsing wikitext.

  • Structured information about what the image depicts, creator, licence, location, etc.

  • Multilingual metadata that applications can consume directly see video

    image
    image2386×1462 505 KB

  • Structured licensing information for reuse and attribution.

  • Better interoperability with external datasets.

  • Easier round-tripping of metadata between Commons and other systems.

From an OpenStreetMap perspective, I think the most interesting use case is that photographs become structured mapping evidence.

Today a Commons file is mostly just “a photo”. With SDC it becomes possible to describe what part of the mapped object the photo documents:

  • aerial view
  • main entrance
  • accessible entrance
  • house number
  • information board
  • trail marker
  • playground
  • etc.

This makes it much easier for both humans and software to find the evidence relevant to a specific mapping task. For example, an editor could ask:

  • Show me photos of the main entrance.
  • Show me photos where the house number is visible.
  • Show me photos documenting wheelchair accessibility.
  • Show me aerial photos of this feature.

That is much more powerful than simply linking to a Commons page.

In my experience, a good photograph is often the best evidence when mapping. One image rarely documents everything, so having a structured collection of photographs showing different aspects of the same object is much more valuable than having a single “representative” picture.

Personally, I also think we need to move towards using more 360° imagery for mapping. Commons is currently relatively weak in that area compared with dedicated street-level imagery platforms, but SDC provides a foundation for making even those media much more discoverable and reusable.

14

How that is relevant to wikimedia_commons=* linking and potential new one? Neither involves parsing wikitext

is it really impossible to get those if you have Wikimedia Commons file name?

why that would be impossible if relevant object is linked with wikidata= from OSM ?

and how that is relevant for this topic?

15

If you consume OSM from an appkication and get an image from Wikicommons than you can easily read the metadata about the picture and understand the license the picture has and much more if you use SDC…

It isn’t impossible. wikidata=* works well when the goal is to identify the mapped real-world object. My point is that it serves a different purpose than linking to a specific media object.

High-quality images are becoming increasingly important for mapping. A lesson I’ve learned is that taking comprehensive photos—especially 360° images—often proves valuable later. You may revisit the imagery to answer questions you didn’t think of on site, for example checking exactly where an AED is mounted or verifying other small details.

My view is that richer imagery combined with richer structured metadata is the direction we should be moving toward.

As an example, while documenting the Stockholm Archipelago Trail Key:ref:stockholmarchipelagotrail , I uploaded more than 7000 pictures / latest pictures. That collection continues to be useful for verifying mapping details long after the field survey was completed.

We still miss pictures ;-)

Below a ChatGPT picture trying to explain my point

image
image1536×1024 482 KB

Proposal to add :robot: as a reaction to AI content
16

yes, and that makes Structured Data on Commons useful

but how that is relevant to

given that we can access Structured Data without new tagging schema, by getting this data for specific file?

all your remaining post also fails to explain why we would need to change anything at all in OSM tagging

we do not need to link from OSM data using Structured Data identifiers to benefit from Structured Data being a thing - it is also accessible if we know file name

2 Likes
17

yes, and that makes Structured Data on Commons useful but how that is relevant to

Yes, and that’s exactly why I’m suggesting using the MediaInfo entity as the link target in OSM.

The MediaInfo entity is the canonical identifier for the structured metadata of a specific Commons file. Unlike a file title, it provides a stable entry point to the file’s structured data. Simply appending .json to the MediaInfo URL gives direct access to machine-readable metadata about that image, including depicts statements, creator, license, coordinates, and other structured properties.

The new entry point introduced by the Structured Data on Commons (SDC) project is therefore not just another identifier—it is the native identifier for the structured data layer itself.

we do not need to link from OSM data using Structured Data identifiers to benefit from Structured Data being a thing - it is also accessible if we know file name

That is the same logic that we should delete the OSM Wikidata tag and use the Wikipedia article names.. maybe not 100% stable but it often works… KISS Keep it simple :smiley:

A Commons file has only one filename, even though it may be used by people speaking hundreds of different languages. If the filename happens to be in Chinese, Arabic, Swedish, or any other language unfamiliar to the user or developer, it becomes difficult to understand or work with directly.

A MediaInfo entity (Mxxxxxx) is language-neutral. Human-readable labels, descriptions, and other multilingual metadata are stored separately and can be retrieved in the user’s preferred language. This follows the same principle as Wikidata, where a language-independent identifier is combined with multilingual labels see example in the movie above

  • en apple
  • sv äpple
  • fa سیب
  • zh 苹果
  • ar تفاح

A MediaInfo entity (Mxxxxxx) avoids the confusion that can arise when a Commons filename is in a language or script unfamiliar to the user or developer. A language-independent identifier remains the same regardless of the filename, while applications can retrieve labels and descriptions in the user’s preferred language.

Wikidata has demonstrated how well this approach scales internationally. Language-neutral identifiers combined with multilingual labels have proven to be an effective way to support users and developers across many languages.

18

I should have realized earlier what is going on and to what entity I am “talking”. Silly me.

If that is the first use of LLM by you in this thread: this is also quite insulting, no idea why you thought this is appropriate.

Wikimedia Commons file names are also fairly stable.

As I mentioned earlier… Luckily Wikimedia Commons editors do not change file pages as a hobby, unlike what happens with article pages where stability can be quite poor. So this benefit is quite tiny and readability and new duplicative tagging schema headaches are still present.

And other benefits are entirely usable without changing anything in OSM tagging.

4 Likes
19
20

redirects left after move can be easily resolved automatically, so only rare broken moves not leaving redirect and that ignore that file is used in OSM will cause problems

screen-2026-07-24-12-13-57
screen-2026-07-24-12-13-571744×914 470 KB

of those only non-file was moved without leaving redirect

And Commons:Files used on OpenStreetMap/48 - Wikimedia Commons et all are setup to prevent such damage.

1 Like