Commons talk:Structured data

Structured Commons

About

Get involved

GLAM and culture

SPARQL

Modeling

Discussion

Welcome to the general talk page of Structured Data on Wikimedia Commons. See also specialized talk pages about data modeling and about Lua.

	SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 7 days.

Archives *Structured data/Archive 2014-16 Structured data/Archive 2016 Structured data/Archive 2017 Structured data/Archive 2018 Structured data/Archive 2019 Structured data/Archive 2020 Structured data/Archive 2021 Structured data/Archive 2022 Structured data/Archive 2023 Structured data/Archive 2024 Structured data/Archive 2025

Can't use P12346?

I wanted to add based on media (P12346) to link from File:Anker A8370 card reader HS04 (cropped).jpg to the uncropped version, but when I try to search for P12346 in the web interface for SDC, it doesn't come up as an option. Anyone know why? –IagoQnsi (talk) 21:33, 24 August 2025 (UTC)

@IagoQnsi: it's not in Commons:Structured data/Properties table. We do have based on (P144). - Jmabel ! talk 23:28, 24 August 2025 (UTC)

I believe SDC doesn’t support the commonsMedia data type in general, i.e. it’s not possible to have statements that have a Commons file as the value. (See also: Special:Search/haswbstatement:P18 showing no results for files with image (P18) statements.) On Commons:Structured data/Modeling/Source, {{Derived from}} is listed as a case “still under discussion”. Lucas Werkmeister (talk) 17:23, 25 August 2025 (UTC)

Compatibility of P1344 and P585

In this file, a bot added participant in (P1344) "Wiki Loves Monuments 2025", and I added point in time (P585) "2 Jun 2019". (Normally, P585 is added by bot, but I am using {{DTZ}} which the bot does not understand, and this is why I added the date manually to SDC.) Now, I got the warning in the P1344 sector, which says that for 2025 WLM participants eligible range of P585 is September 2025. However, I took the picture in 2019, and this is perfectly fine to use P585 to indicate this. This photo is eligible for WLM2025 since I uploaded it a few days ago. I have a similar issue in at least one more file. Maybe some constraints need to be cleaned up, or possibly I am using a wrong property for the day I took the photograph. Ymblanter (talk) 15:45, 22 September 2025 (UTC)

I would expect inception (P571) for the date the photo was taken. - Jmabel ! talk 19:58, 22 September 2025 (UTC)

Thank you. I know that when I add photos to Wikidata items (which I do quite a lot), I use P31 (Image), and then the first suggestion I get for the qualifier is P585. Ymblanter (talk) 09:00, 23 September 2025 (UTC)

(I’m pretty sure inception (P571) would still result in the same constraint violation as point in time (P585), for what it’s worth.) Lucas Werkmeister (talk) 12:16, 23 September 2025 (UTC)

Bounding Box as SDC for Maps and DOP (Digital Orthophotos)?

What about new a SDC / Wikidata property to describe a geographical bounding box? I think it would be useful for maps as well as for Digital Orthophotos (DOP) – maybe even allowing a query for media displaying a certain geographical area? Currently, as far as I see, only the {{Map}} template allows to describe the bounding box of the file exactly, using the coordinates of the four rectangle corners as values for the latitude / longitude parameters. For a DOP with Bounding Box data, see, for example, DOP40 - Stadt Erlangen 32645 5496 (Bayerische Vermessungsverwaltung).tif. There, I've used both {{Information}} and {{Map}} as file description, while using only the latitude / longitude and warp_status parameters of {{Map}}. At least, it seems to be possible to set and show the coords of the four corners exactly. But sadly, it seems that the Wikimap Warper can't handle TIFF files – thus, setting warp_status to skip is required, and there's currently no way to show the DOP as map "layer", or to make use of the bounding box otherwise. Fl.schmitt (talk) 19:41, 23 September 2025 (UTC)

@Fl.schmitt: I don’t think a single “bounding box” property would work well (there’s no good data type for it), but coordinates of northernmost point (P1332) + coordinates of southernmost point (P1333) + coordinates of easternmost point (P1334) + coordinates of westernmost point (P1335) could be used – the property proposal explicitly supports defin[ing] the limits of a map, the constraints allow usage on MediaInfo entities, and there are a handful of existing files using the properties this way, such as File:Geographic map of Balkan Peninsula.svg. Lucas Werkmeister (talk) 20:39, 23 September 2025 (UTC)

@Lucas Werkmeister - I agree that those four properties can be used to describe a map's bounding box. But doing so has a major disadvantage: the semantics isn't clear. For a map or a DOP, you usually can't determine a single "southernmost point", instead you have to choose between hundreds of them. And there's no common practice or guideline how to choose (contrary to the {{Map}} template guidelines for the latitude and longitude parameters). Thus, choosing a "single" southernmost point is arbitrary. This might be ok for humans, but it's a problem for structured data and applications using those data. The Balkan Peninsula Map is a nice example: It uses only three "points" - the coordinates of southernmost point (P1333) is missing, the coordinates of easternmost point (P1334) seems to denote the coordinates of southernmost point (P1333) as well. A human being is able to cope with this, but i think it's hard to handle such data in a SPARQL query. Additionally, in the case of the Balkan Peninsula Map, it seems that coordinates of westernmost point (P1335) and coordinates of northernmost point (P1332) are both set to the same location. If there's no rule to choose the corners as reference for those properties, using a single point is meaningless - no semantics. For rectangular Maps or DOP, even two corners would be sufficient to describe the bounding box. But doing so will trigger the "item-requires-statement constraint" for the two other corners. So, the concept of combining coordinates of northernmost point (P1332) / coordinates of southernmost point (P1333) / coordinates of easternmost point (P1334) / coordinates of westernmost point (P1335) won't work well to describe a geographical bounding box. Fl.schmitt (talk) 20:29, 24 September 2025 (UTC)