Commons talk:Structured data/Archive 2025
| This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Modeling video / audio / pdf / djvu files
language of the work, etc. what properties should i be using? also, a bot should take care of some of these. RoyZuo (talk) 14:27, 19 November 2024 (UTC)
- @RoyZuo: I just want to make sure before I give any longer answer: are you familiar with Commons:Structured data/Properties table? Seems to me that most (though not all) of what is relevant to a photograph would also be relevant to a video. And the answers for video are going to be different for a PDF (and for a PDF of a written document are going to be different from a PDF that is just a collection of images), so you are really asking several separate questions here. - Jmabel ! talk 22:16, 19 November 2024 (UTC)
- How to record the time/date when a video is made, if it spans over multiple days? starting a recording at 23:59:00 31 dec 2022 and ending at 00:00:10 02 jan 2023, how would that be recorded in sdc?
- How to display/record that in the date parameter of {{Information}}? RoyZuo (talk) 11:15, 1 January 2025 (UTC)
- @RoyZuo: I take it from the wording there that you really wouldn't want me to help you, so I won't.
- I will make one suggestion, which you can take or leave: if you have several questions, and want answers, it helps to state them clearly as separate questions. - Jmabel ! talk 20:44, 1 January 2025 (UTC)
Who's developing models?
Who should be contacted when a model is needed? Seems to me there're 3 groups of users invovled which do not necessarily overlap: commons users (who're developing models by themselves?), wikidata users who decide which properties and items are created and deleted and how they are used, and mediawiki developers who develop the software. RoyZuo (talk) 11:24, 1 January 2025 (UTC)
Two new property proposals
Since these proposals are relevant to SDC, input from Commons users would be appreciated.
- d:Wikidata:Property_proposal/AI-generated_media_prompt
- d:Wikidata:Property_proposal/Text-to-image_software_used_for_creation
--Lewis Hulbert (talk) 07:14, 3 February 2025 (UTC)
- Created software used for creation (P13308), other proposal still under discussion. --Lewis Hulbert (talk) 16:31, 17 February 2025 (UTC)
- Thanks ; took a stab at documenting this at Commons:Structured data/Modeling/Image captured with. Jean-Fred (talk) 20:29, 17 February 2025 (UTC)
- Created software used for creation (P13308), other proposal still under discussion. --Lewis Hulbert (talk) 16:31, 17 February 2025 (UTC)
Support - Jmabel ! talk 18:13, 3 February 2025 (UTC)
Hide SD edits
Is there any way to hide SD edits on my watchlist? They don't interest me, and just seem to be filling my watchlist, particularly from bots. I don't want to disable all bot edits. Voice of Clam 17:41, 3 March 2025 (UTC)
- See m:Community Wishlist/Wishes/Watchlist - hide structured data edits. See its talk page for what I think solves this. Despite of having many files on my watchlist, I only rarely see any SD changes because only very few people set these so I usually just skip them. Prototyperspective (talk) 20:17, 3 March 2025 (UTC)
- I have this link to my watchlist bookmarked, it hides them using the tag filters. Thanks. Mike Peel (talk) 23:45, 3 March 2025 (UTC)
- @Voice of Clam, you can hide all bot edits from watchilist from settings. If you want hide only SDC edits by bot but keep categoryedits then it is more tricky, but you can do it by adding line :
li.mw-tag-BotSDC { display:none; }to your user:Voice of Clam/common.css page. (example: user:Zache/common.css) -- Zache (talk) 09:21, 4 March 2025 (UTC)
- @Zache: - sorry for the delay in replying as I've been offline for a few days, but that's just what I wanted. Thanks! Voice of Clam 18:23, 11 March 2025 (UTC)
Photograph vs drawing
How do you distinguish between photograph (Q125191) and drawing (Q93184)? It looks like these items aren't heavily used on WC. These are all files where person is depicted, but without caricatures: haswbstatement:P180=Q40787 -haswbstatement:P136=Q482919
How do you exclude all drawings from there? Or all photographs? Is there a better set of files where difference between photograph and drawing already modelled? How to model a difference between a normal photograph of a person and something like that: File:Свята-Мікалаеўская царква (Крайск).jpg ?
Help pages which could have been useful: Commons:Structured data/Modeling/Depiction, Commons:Structured data/Modeling/Works and files, Commons:Structured data/Modeling, Commons:Depicts, Commons:Structured data/Modeling/Works without Wikidata item Podbrushkin (talk) 12:43, 5 March 2025 (UTC)
- Ok, photograph (Q125191) item is actually used pretty often in instance of (P31) (40M results): haswbstatement:P31=Q125191.
- Probably any "faithful digital representation" of analog photograph can use instance of (P31)=photograph (Q125191) as well. When it's a digital copy made with a camera, a fabrication method (P2079) prop can be used.
- Other common instanceOf values: https://w.wiki/DJZH
- This way haswbstatement:P31=Q125191 can be used to exclude all drawings and -haswbstatement:P31=Q125191 to exclude all photographs. Podbrushkin (talk) 13:29, 5 March 2025 (UTC)
- Some in the BHL-Wiki working group are using instance of (P31) illustration (Q178659) qualified by applies to part (P518) analog work (Q112134971) as we want to be able to distinguish between and search for photographs of species and illustrations of species sourced from BHL content. We're also adding other instance of (P31) statements see this document for more information. Ambrosia10 (talk) 22:11, 3 May 2025 (UTC)
Adding 'captured with' statement by bot
Hello everyone.
As part of requests to operate my bot, I would like to reach a consensus on the possibility of bots adding the captured with (P4082) statement on a sufficiently large scale. It seems that I have to justify why these statements can be added and how they are useful? Well, here are my arguments. Currently, there are already bots that add captured with (P4082) statements among other things. The main reason why I decided to create a bot is that the presence of such statements already allows you to search for images by specific models of gadgets (particularly useful for comparing photos of different models of phones, cameras, etc.). Additionally, I believe it may be possible to train an AI model using metadata from Commons images. This model could generate photos in the style of a specific model or, conversely, determine probable EXIF data, including the camera model, even if that information is not available.
Please share your pros and cons regarding this proposal. Thank you! Borealex (talk) 22:37, 24 May 2025 (UTC)
Map cant be zoomed or dragged
just go to any file, e.g. File:Shaw Foundation Symphony Stage (133040).jpg, coordinates of the point of view (P1259) has a coord and shows a map, but the map cant be zoomed in or out, or dragged, and the coord doesnt link to something else.
that's totally different from wikidata, where maps are interactive and the coord links to https://geohack.toolforge.org . RoyZuo (talk) 11:44, 25 May 2025 (UTC)
SDC query result to PetScan
Is it possible to insert the results of an SDC SPARQL query (like https://w.wiki/EHNw) into PetScan? I intuitively tried several options, but none of them worked at all. Jklamo (talk) 14:24, 25 May 2025 (UTC)
- @Jklamo I believe Commons SPARQL requires authentication. I'm not so sure if you can integrate it into PetScan without emulating a browser or sending the request with Cookies -- DaxServer (talk) 18:38, 25 May 2025 (UTC)
How do we list the following things
- Vocal music audio files
- Instrumental music audio files
- National anthems
- Theme songs
- Trailers of works
Source claim for coordinated derived from file properties (file name)?
I'm working on adding SDC coordinates (coordinates of the point of view (P1259)) to Orthophotos. The coordinates are derived from the file names which contain the UTM coordinates in a peculiar format: e.g., for DOP40 - Landkreis Hof 32689 5573 (Bayerische Vermessungsverwaltung).tif, the UTM values are 32 / 689 / 5573, which reads 32U 689000 5573000 as UTM coordinates for the lower left corner of the orthophoto (for the coordinates of the center of the DOP, just add 500 to both the northing/easting values, yielding 32U 689500 5573500 as UTM coordinates = 50°16′59″N 11°39′36″E / 50.283167°N 11.660001°E).
Now my question: is there a way to describe the source of the (calculated) decimal coordinates (coordinates of the point of view (P1259)) as derived from the file names? Or should i refrain from adding a source claim in such a case? Which property would describe that kind of source relation? Fl.schmitt (talk) 16:27, 13 July 2025 (UTC)
- Found a temporary solution: since the calculation of coordinates relies on data derived from "BayernAtlas" and provided as open data there, using stated in (P248) and BayernAtlas (Q812473) should be sufficient. I would be glad for any other ideas how to improve this. Fl.schmitt (talk) 05:36, 14 July 2025 (UTC)
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
latitudeandlongitudeparameters). 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)
- @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
located in the administrative territorial entity (P131)
Can someone tell me why we are not allowed to use this as a qualifier to location of creation (P1071)--Trade (talk) 12:09, 28 November 2025 (UTC)
- @Trade: That sounds like a case of XY problem to me :) where do you want to use that qualifier, and with which P131 and P1071 values? (My general answer would be that the P131 belongs on Wikidata on the P1071 value, but maybe your context is different.) Lucas Werkmeister (talk) 12:57, 28 November 2025 (UTC)
- I was using the qualifier to show which county and state a photo was taken in. I was just wondering why that is considered inappropriate--Trade (talk) 12:59, 28 November 2025 (UTC)
- P1071 should describe the location of creation. If you start using the qualifiers then probably the value you added to P1071 is incomplete / imprecise. If you added a city / administrative division to P1071, the Wikidata item for the city already knows what P131 for it is, and there is no ambiguity here. Ymblanter (talk) 13:09, 28 November 2025 (UTC)
- What Ymblanter said. It’s not necessary to repeat on hundreds and hundreds of files that, for example, the Oval Office (Q338067) lies in the West Wing (Q1932621) of the White House (Q35525) which is located in Washington, D.C. (Q61); all that information is readily available on Wikidata, and it’s quite sufficient to store it there, just once. Lucas Werkmeister (talk) 18:42, 28 November 2025 (UTC)
- And likely if there is a desire for things like this to be shown on commons, that should be some form of UI / software change to expose that to commons viewers / editors. ·addshore· talk to me! 12:04, 2 December 2025 (UTC)
- Relevant to what Werkmeister said above is iiuc this request: Template talk:Geogroup#Also include files geolocated to countries/places via subcategories but not coordinates. Currently, the coordinates used in the superordinate category Wikidata item is not used/shown by the map. Prototyperspective (talk) 19:32, 2 December 2025 (UTC)
- What Ymblanter said. It’s not necessary to repeat on hundreds and hundreds of files that, for example, the Oval Office (Q338067) lies in the West Wing (Q1932621) of the White House (Q35525) which is located in Washington, D.C. (Q61); all that information is readily available on Wikidata, and it’s quite sufficient to store it there, just once. Lucas Werkmeister (talk) 18:42, 28 November 2025 (UTC)
- P1071 should describe the location of creation. If you start using the qualifiers then probably the value you added to P1071 is incomplete / imprecise. If you added a city / administrative division to P1071, the Wikidata item for the city already knows what P131 for it is, and there is no ambiguity here. Ymblanter (talk) 13:09, 28 November 2025 (UTC)
- I was using the qualifier to show which county and state a photo was taken in. I was just wondering why that is considered inappropriate--Trade (talk) 12:59, 28 November 2025 (UTC)