Open main menu

Wikidata:Property proposal/Commons

See alsoEdit

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See steps when creating properties.

  On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2019/09.

Dedicated page for the properties related to Structured Data on Commons, see also Structured Data on Commons properties table

Wikimedia CommonsEdit

image extracted fromEdit

   Done: extracted from (P7009) (Talk and documentation)
Descriptionsource this image was cropped from
Data typeCommons media file
Template parameter1= in c:Template:extracted from
Domaincropped images on Commons
Example 1File:" 13 - Italian sport car - Alfa Romeo 4C rear spoiler carbon fiber.jpgFile:Geneva MotorShow 2013 - Alfa-Romeo 4C red rear.jpg
Example 2File:"Jobs, baby, jobs!" (2959819547) (cropped).jpgFile:"Jobs, baby, jobs!" (2959819547).jpg
Example 3File:"First Man" Premiere at NASM (NHQ201810040122) (cropped).jpgFile:"First Man" Premiere at NASM (NHQ201810040122).jpg
Example 4File:"S.F.P.D. POLICE LINE DO NOT CROSS" fence sign at 2008 Olympic Torch Relay in SF - Embarcadero 22 (cropped).JPGFile:2008 Olympic Torch Relay in SF - Embarcadero 22.JPG
Robot and gadget jobsadd to c:Category:Extracted images (currently 229,701)


Seems to be a popular usecase at Commons (Add your motivation for this property here.) --- Jura 11:42, 17 June 2019 (UTC)


  •   Support - basically a "source" for the file. --DannyS712 (talk) 05:41, 25 June 2019 (UTC)
  •   Oppose unless I misunderstand. Where do you plan to apply this property? To a Wikidata item? If so, which? The listed examples are Files on Commons, where Wikidata properties cannot be applied. If you are proposing this as something for the Structured Data section on Commons, you will need to propose that on Commons. --99of9 (talk) 06:14, 12 July 2019 (UTC)
    • No, properties need to be created on Wikidata. --- Jura 06:17, 12 July 2019 (UTC)
      • Can you point me to either documentation or an example of a property that (only?) works on Commons but has been created here. --99of9 (talk) 06:28, 12 July 2019 (UTC)
      • digital representation of (P6243), Commons quality assessment (P6731). There are no properties that were created only on Commons. --- Jura 06:31, 12 July 2019 (UTC)
        • Ok thanks, those are good comparable examples. I've struck my oppose. So the idea is to make properties here that will one day be built into Structured Data on Commons? It seems a bit strange that the decisions are here - perhaps we should have some kind of echo noticeboard letting them know about proposals that will mainly affect them. --99of9 (talk) 07:05, 12 July 2019 (UTC)
          • Ultimately, it's up to them to decide if and how they actually use it. For now, they seem to want to do most things with a single property ;) --- Jura 08:26, 12 July 2019 (UTC)
  •   Support Yes, this will be needed for Structured Data on Commons. But it may better to make a list of request creation as a batch. There is a discussion on Commons: c:Commons:Structured data/Properties table. Regards, Yann (talk) 09:32, 12 July 2019 (UTC)

Jheald (talk) 06:27, 17 August 2014 (UTC) Micru (talk) 07:20, 17 August 2014 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 17 August 2014 (UTC) Sannita - not just another sysop 12:50, 18 August 2014 (UTC) Susannaanas (talk) 08:05, 19 August 2014 (UTC) Mushroom (talk) 12:02, 21 August 2014 (UTC) I do think Commons is the better place to talk about this. Multichill (talk) 18:50, 21 August 2014 (UTC) Jarekt (talk) 04:38, 3 September 2017 (UTC)  徵國單  (討論 🀄) (方孔錢 💴) 11:23, 14 November 2017 (UTC) Mike Peel (talk) 22:50, 12 May 2018 (UTC) Yann (talk) 23:27, 7 July 2018 (UTC) John Samuel (talk) 10:10, 22 September 2018 (UTC) 99of9 (talk) 06:27, 12 July 2019 (UTC) Christian Ferrer (talk) 18:05, 19 July 2019 (UTC) Jura GPSLeo (talk) 13:30, 29 July 2019 (UTC) Tris T7 TT me
Juandev (talk) 17:35, 7 September 2019 (UTC)

  Notified participants of WikiProject Commons --99of9 (talk) 07:05, 12 July 2019 (UTC)

  •   Support nice one on one mapping with the template. Multichill (talk) 14:41, 12 July 2019 (UTC)
  •   Support --Jarekt (talk) 03:00, 19 July 2019 (UTC)
  •   Support Christian Ferrer (talk) 17:48, 26 July 2019 (UTC)
  •   Comment Now the datatype is commonsMedia. I think that is outdated with the new Wikibase based system. The datatype should be for the M-ID of the file. --GPSLeo (talk) 13:34, 29 July 2019 (UTC) image IDEdit

   Ready Create
Descriptionidentifier for an image from Geograph Britain and Ireland
RepresentsGeograph Britain and Ireland (Q1503119)
Data typeExternal identifier
Domainimages on Commons
Allowed values[1-9]\d*
Example 1File:Flatholm Lighthouse - - 900719.jpg → 900719
Example 2File:Wild Leek in front of Flatholm lighthouse - - 1529372.jpg → 1529372
Example 3File:Flatholm foghorn - - 1529370.jpg → 1529370
External linksUse in sister projects: [ar][de][en][es][fr][he][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][commons][species][wd].
Formatter URL$1
Robot and gadget jobsadd to c:Category:Images from Geograph Britain and Ireland


Allows to store the id on Commons in a structured way. The above proposal is for only. Maybe additional ones are needed. (Add your motivation for this property here.) --- Jura 10:01, 21 June 2019 (UTC)

Jheald (talk) 06:27, 17 August 2014 (UTC) Micru (talk) 07:20, 17 August 2014 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 17 August 2014 (UTC) Sannita - not just another sysop 12:50, 18 August 2014 (UTC) Susannaanas (talk) 08:05, 19 August 2014 (UTC) Mushroom (talk) 12:02, 21 August 2014 (UTC) I do think Commons is the better place to talk about this. Multichill (talk) 18:50, 21 August 2014 (UTC) Jarekt (talk) 04:38, 3 September 2017 (UTC)  徵國單  (討論 🀄) (方孔錢 💴) 11:23, 14 November 2017 (UTC) Mike Peel (talk) 22:50, 12 May 2018 (UTC) Yann (talk) 23:27, 7 July 2018 (UTC) John Samuel (talk) 10:10, 22 September 2018 (UTC) 99of9 (talk) 06:27, 12 July 2019 (UTC) Christian Ferrer (talk) 18:05, 19 July 2019 (UTC) Jura GPSLeo (talk) 13:30, 29 July 2019 (UTC) Tris T7 TT me
Juandev (talk) 17:35, 7 September 2019 (UTC)

  Notified participants of WikiProject Commons as I found a list to ping. Here we go. --- Jura 13:21, 19 July 2019 (UTC)


  •   Comment The links already exist as sources of images, so what is the benefit of adding them again as a property? David (talk) 06:33, 22 June 2019 (UTC)
    • It's currently not included as structured data. A separate property allows to check for distinct values easily. --- Jura 10:06, 22 June 2019 (UTC)
  •   Support in general, however this property might not be useful for a while, at least until Commons allows use of any property. --Jarekt (talk) 15:34, 19 July 2019 (UTC)
  •   Support Christian Ferrer (talk) 18:06, 19 July 2019 (UTC)
  •   Comment BTW, please see c:Commons:Village_pump/Proposals#Geograph_2?. --- Jura 18:46, 19 July 2019 (UTC)
  •   Comment Note that each ID really identifies two pictures (one high-resolution and one low-resolution) along with some metadata. In most cases the pictures are essentially identical, but in some cases they can be substantially different. It may be worth distinguishing the high-res and low-res pictures in cases where they differ significantly (but in other cases they should not be distinguished because the low-res one might be overwritten by the high-res one). --Bjh21 (talk) 17:05, 24 July 2019 (UTC)
    • Do we have a few samples on Commons where this is relevant? --- Jura 17:52, 24 July 2019 (UTC)
    • If there're two images they can be qualified by subject has role (P2868).--GZWDer (talk) 18:16, 25 July 2019 (UTC)
  •   Question What problems are there with a generic approach, based on a pair of properties image source URL + image description URL, that would need this proposal to overcome? If there are difficulties with the generic approach, should we not try and solve them (or get them solved), to then have properties that would work well for all images, not just a limited subset of them? Until we have thought about this my !vote is Wait. Jheald (talk) 17:52, 27 July 2019 (UTC)
  • marking as not ready until Jheald's comment above is answered (@Jheald: could you please use vote templates such as {{Wait}} when voting rather than '''Wait'''? This will help make sure your votes are more visible when assessing the consensus for a property. Thanks!) − Pintoch (talk) 08:52, 5 August 2019 (UTC)
    • I think the point was addressed earlier. Not sure if they read, at least they don't seem to take it in account in their comment. --- Jura 09:03, 5 August 2019 (UTC)
      • @Jura1: Precisely where is my question answered? Diff, please. Oh and please cut out the personal abuse, it's not cool. Jheald (talk) 09:58, 5 August 2019 (UTC)
        • [1]. Sorry if you feel abused by a comment on your comment. So did you not read it or did just not take that in account? --- Jura 10:05, 5 August 2019 (UTC)
          • @Jura1: Ok, I did see that comment. It describes how the property would be an advance over the current wikitext templates. But my question was to ask how this property would be advantageous over a pair of generic structured data properties, image source URL + image description URL, that could be applied to any image. Those would be SDC properties, so would be accessible from queries etc. One could also put a distinct values constraint on the image source URL property (possibly with an exception to allow derived images?) Against that as a baseline, is there an advantage to having specific properties for images sourced from geograph, Flickr, etc? Jheald (talk) 17:45, 5 August 2019 (UTC)
            • We don't have much experience for this to work from Wikidata. This proposal merely for an identifier for a specific source. --- Jura 10:33, 25 August 2019 (UTC)
  •   Support.--Vulphere 14:59, 12 August 2019 (UTC)

copyright exemptionEdit

Descriptioncopyright exemption this file is covered by
Data typeItem
DomainFiles that are covered by a copyright exemption like freedom of panorama.
Example 1File:Atomium1.JPGfreedom of panorama (Q918113) (with qualifiers applies to jurisdiction (P1001)Belgium (Q31) & applies to part (P518)Atomium (Q180901))
Example 2File:ToonderMonument.jpgfreedom of panorama (Q918113) (with qualifiers applies to jurisdiction (P1001)Netherlands (Q55) & applies to part (P518)Hommage to Marten Toonder (Q33197533))
Example 3File:Amsterdam Anne Frank.jpgfreedom of panorama (Q918113) (with qualifiers applies to jurisdiction (P1001)Netherlands (Q55) & applies to part (P518)statue of Anne Frank (Q28873418))
Example 4File:Petronas Panorama II.jpgfreedom of panorama (Q918113) (with qualifiers applies to jurisdiction (P1001)Malaysia (Q833) & applies to part (P518)Petronas Towers (Q83063))
Robot and gadget jobsGo through Commons:Category:FOP by country and add this new property to the files with the right qualifiers.


First proposed at the structured data on Commons talk page: For cases of PD-artwe have digital representation of (P6243). Here we have two works: A photo and the 2D work of art. The 2D work of art is in the public domain so we consider the the photo also to be in the public domain. Freedom of panorama is similar to this, but the other way around. A photo of a in copyright object (in this example Atomium (Q180901). Normally the photo wouldn't be allowed, but because we have freedom of panorama, we can use it. We need a new property to model this. As a qualifier we can use applies to jurisdiction (P1001) (Belgium (Q31) in this case) and applies to part (P518) to indicate to what it applies (Atomium (Q180901)). The same property could probably be used for De minimis cases. Multichill (talk) 17:00, 26 July 2019 (UTC)


external georeferencer URLEdit


It would be useful to move these links to structured data, which would facilitate discovery and analysis. Jheald (talk) 16:41, 27 July 2019 (UTC)


detail of paintingEdit


Somehow these should be linked together. Here is a suggestion for an approach. I think it's preferable over P180 with some convoluted qualifier, digital representation of (P6243) (as it's not the full view), extracted from (P7009) (as it's not necessarily generated from the other file), maybe part of (P361). --- Jura 18:53, 2 August 2019 (UTC)


  •   Oppose Use main subject (P921) David (talk) 06:21, 3 August 2019 (UTC)
  •   Neutral to   Oppose. I would have thought that depicts (P180) = Napoleon III in Genoa (Q66091522), with a qualifier depicted part (P5961) = eg central part (Q27956567) or = an item for "detail", to indicate that only a part of the whole painting was shown, would be the most natural way to do this. This would seem to be exactly the job that qualifier P5691 was made for. A further qualifier analogous to relative position within image (P2677) to state the position within the object image might be useful, however. Jheald (talk) 18:03, 5 August 2019 (UTC)
  • Q22004703 currently labelled "Portrait of Queen Anna Jagiellon as a widow (detail)" reminded me of this .. --- Jura 07:39, 9 September 2019 (UTC)
  •   Support under the condition that it is not restricted to paintings. "depicts part" would be a better name, corresponding to the "depicted part" parameter added by Jarekt to the c:Module:Artwork template family, cf. c:Module talk:Artwork#New |detail= parameter?. --Marsupium (talk) 13:42, 10 September 2019 (UTC)
    • Not sure. As long as it's 2D, I wouldn't mind. For 3D, you always only get a part. --- Jura 13:49, 10 September 2019 (UTC)
  •   Comment I should point out, that I am having difficulties in understanding what such property should handle. From the examples presented, it looks to me that the goal is to describe, its is a case of a derivative work, e. g. a crop. So I think that in such cases we may use derivative work (P4969), which is even more general than this proposal and covers a wide range of file types. If I am wrong in understanding of what did you mean, please explain it the other way. Juandev (talk) 04:50, 11 September 2019 (UTC)

image may representEdit

   Under discussion
Descriptionimage should be using "digital representation of" (P6243), but it's not entirely clear if the value used here is the correct one
Data typeItem
Example 1File:'Quarry, Pontoise' by Camille Pissarro, c. 1874.jpg] → The Quarry, Pontoise (Q21673134) (likely yes)
Example 2File:'Elizabeth Boott Duveneck' by Frank Duveneck, Cincinnati Art Museum.JPGELIZABETH BOOTT DUVENECK (Q46956757), Portrait of a Lady (Elizabeth Boott Duveneck) (Q28788745), ELIZABETH BOOTT DUVENECK (Q46959040) (not clear which one and if there might not be duplicate items)
Example 3File:'Ducks and Turkeys' by Edvard Munch, 1913.JPGDucks and Turkeys in Snow (Q18889772) (possibly part of a series)
Example 4File:L'empereur Napoleon III de Franz-Xaver Winterhalter.jpg → <new item for "L'empereur Napoleon III"> (one of several known copies, original thought to be lost according to c:Category:Emperor Napoleon III in Coronation Robes (Winterhalter))
Example 5File:'Cloud Study', by John Constable, 1822, Tate Britain.JPG → some of Special:Search/Cloud Study painting by John Constable -Yale or Special:Search/Cloud Study painting by John Constable
Planned usefor c:Category:Paintings without Wikidata item: temporary statement
See alsodigital representation of (P6243), Wikidata:Property_proposal/detail_of_painting


To sort through the 88000 files of c:Category:Paintings without Wikidata item, it should be possible to determine that we might already have an item, but it's not sufficiently certain to add a statement. Accordingly, a temporary statement could be helpful. Above a property for that. A specialist might more easily determine the correct statement. Please add more samples above. If the samples are resolved in the meantime, please don't remove them. (Add your motivation for this property here.) --- Jura 10:18, 4 August 2019 (UTC)


  •   Oppose We need a more generic mechanism for items that have been identified (possibly by machine) as "best guesses", but require confirmation or assessment. Rather than to create a bespoke property for the present niche application, it would be good to agree a more general way to indicate this. One approach used on wikidata is to add the statement but with deprecated rank and reason for deprecation (P2241) = unconfirmed (Q28831311). Other ways of signalling a provisional nature of a statement could also be envisioned. Jheald (talk) 18:25, 5 August 2019 (UTC)
    • Interesting thoughts, though I don't quite see the disadvantage of solving the problem now, even if the solution may only be temporary (it's meant to be an temporary statement anyways). Otherwise we might end up like the guys with some other database field: they keep discussing the optimal solution, but x years down the road, their field is still a mess. --- Jura 11:18, 7 August 2019 (UTC)
  •   Oppose Having a bespoke solution for this use-case seems problematic and would invite a lot of other bespoke solutions for similar cases. Using the depricated rank as Jheald suggests seems to be the best with the tools we have currently, but it's still cumbersome. Maybe we need a 4th rank type for this (depricated/uncertain/normal/preferred)? ChristianKl❫ 13:21, 8 August 2019 (UTC)
    • Why would this be problematic? There is no numeric limit on the number of properties we can create. --- Jura 13:30, 8 August 2019 (UTC)
      • While there's no numeric limit on the number of properties, users have to learn about properties to be able to use them appropriately. Increased complexity makes it harder to interact with Wikidata. ChristianKl❫ 16:15, 26 August 2019 (UTC)
        • I don't think many users understand easily how the cumbersome alternative works. Even the ones that get seem to find it cumbersome. Anyways, personally, I recall which images I skipped .. if it isn't stored, others might just need to re-do the same. --- Jura 07:43, 9 September 2019 (UTC)

identified in image byEdit

   Under discussion
Description(qualifier) statement value/object is identified with the following number, letter or sign in the image
Data typeString
Domainfiles on Commons, possibly items for visual works
Allowed valuesnumbers (primarily), letters, signs
Example 1File:Vienna Congress.jpg depicts (P180) Arthur Wellesley, 1st Duke of Wellington (Q131691) → 1
Example 2File:Vienna Congress.jpg depicts (P180) Joaquim Lobo da Silveira, 7th Count of Oriola (Q6206321) → 2
Example 3File:Vienna Congress.jpg depicts (P180) António de Saldanha da Gama, Count of Porto Santo (Q1661560) → 3
Example 4File:Vienna Congress.jpg depicts (P180) Gustaf Löwenhielm (Q3439851) → 4
Example 5File:Elevation_gain.png depicts (P180) cumulative elevation gain (Q5804317) → HB-HA+HD-HC
Example 6File:Elevation_gain.png depicts (P180) <new item for "absolute elevation"> → HA,HB
Example 7File:Elevation_gain.png depicts (P180) <new item for "relative elevation"> → HC,HD
Example 8File:Elevation_gain.png depicts (P180) <new item for "elevation difference"> → HB-HA
Example 9File:Elevation_gain.png depicts (P180) <new item for "elevation difference"> → HD-HC
See also


The sample above are for the file:Vienna Congress.jpg. In comparable cases, we could have an item for this version of The Congress of Vienna (Q66120851) as well, but for this file I think it's sufficient to provide the legend on Commons. Note that the original engraving The Congress of Vienna (Q66120851) doesn't include these numbers. series ordinal (P1545) doesn't seem sufficient as ordering might not necessarily be the one used in the image. (Add your motivation for this property here.) --- Jura 14:37, 5 August 2019 (UTC)


issue (P433) and quantity (P1114) are nonsense, issue (P433) has a type constraint to text (Q234460), quantity (P1114) is for quantities and has datatype quantitiy, has nothing to do with the proposal apart from the use of numbers. --Marsupium (talk) 20:15, 13 August 2019 (UTC)
  Support This proposal seems reasonable to me. ArthurPSmith (talk) 18:12, 14 August 2019 (UTC)
  Comment I would just add, that describing specific part of the image via structured data might be possible in the future if we can connect image notes with structured data and it was already discused somewhere. How the technology will exactly work is unknown to me and thus is unknown, how it could be handled by SD. But on the other hand if the image includes notes in its orriginal layer as an image, why not to describe it structuraly. Maybe same property would be in the future used for the proposal mentioned above. Juandev (talk) 20:15, 21 August 2019 (UTC)
  •   Comment I am still coing the idea, wheatere it is needed, when there is P2677. If I understand this well, labeling parts of image is in fact creating an anchor in the image to link it with text. Today we can use frames, which are also anchors. How you would advocate the need to have a specific property for old way of anchoring? I understand that P2677 might not be sufficient as it allows only square/rectangle like anchor, which may sometime cause problems, because such anchors would overlap - overlap when physically highghted in the image. But on the other side, we my try to wider that property to allow defining complex image area (if it is possible I dont know). I wonder weather such historical anchors have some value rather than anchors. I would image the property indicating typu of anchor, e.g. image has number type anchors. Juandev (talk) 17:15, 7 September 2019 (UTC)
    • I don't think we are allowed to overwrite images to remove numbering and use P2677 instead. --- Jura 17:23, 7 September 2019 (UTC)
      • You dont need to overwrite image. The P2677 creates and invisible anchor, which can be displayed as aditional layer. Once you use such image, you can switch it off and once you print that image its not visile. (So click on the image now commons:File:Vienna Congress.jpg, when I have added that layer and you will see how it works. Juandev (talk) 17:32, 7 September 2019 (UTC)
        • I understand the purpose of P2677 and the way it works, but File:Vienna Congress.jpg (and other images) have visible numbering for some elements and users likely want to know what it refers to. This even when they can access the frame system. BTW, I don't advocate anything, I just structure what's available. --- Jura 17:40, 7 September 2019 (UTC)
          • I see, but thats a good point! Juandev (talk) 17:53, 7 September 2019 (UTC)
  •   Support That looks important. Juandev (talk) 00:37, 10 September 2019 (UTC)

file-making techniqueEdit

   Under discussion
Descriptionthe specific technique that was used to create or generate the file
Data typeItem
DomainFiles that have been created with a specific technique such as long-exposure photography (Q1082855), microscopy (Q1074953) or many others. Note it should be reasonable to set a type constraint "instance or subclass of" technology (Q2695280)
Example 1File:Bombus lapidarius queen - Echium vulgare - Keila.jpgmacro photography (Q272444)
Example 2File:Golden Gate Park San Francisco December 2016 006.jpglong-exposure photography (Q1082855)
Example 3File:Heterocentrotus mamillatus MHNT.jpgfocus stacking (Q1435078)
Example 4File:Müürlooga (Arabidopsis thaliana) lehekarv (trihhoom) 311 0804.JPGmicroscopy (Q1074953)


With the gradual establishment of the Structured Data in Commons, it would be good to have such a property that will allow to make an infinity of interesting queries. Christian Ferrer (talk) 18:10, 11 August 2019 (UTC)


  • It could be labelled image-making technique, since photos are a type of image, and other types of image also have techniques. It would be a sub-property of fabrication method (P2079), or perhaps that property could just be used directly? Ghouston (talk) 21:43, 11 August 2019 (UTC)
OK for the label "image-making technique", I did not think about fabrication method (P2079), though maybe a bit too generic. See what others think. Christian Ferrer (talk) 05:05, 12 August 2019 (UTC)
  •   Weak support, this would also be useful in the GLAM context, specifying which digitization method was used. I would also think, SDOC aside, we could use this in Wikidata as a qualifier on properties such as image (P18). But, while I agree fabrication method (P2079) is too generic, this is a bit too specific, since Commons files can be many multimedia types (video, audio, etc.), not just "image". I think we should broaden this scope to be applicable to any file appropriate to Commons, since it wouldn't make sense to create additional properties for them. Dominic (talk) 15:07, 4 September 2019 (UTC)
Thanks you, it makes sense, I changed the name to "file-making technique". Christian Ferrer (talk) 17:07, 4 September 2019 (UTC)
So this property would apply to the digital file, not to the original physical object (if any)? Ghouston (talk) 03:46, 5 September 2019 (UTC)
I was thinking of proposing an "equipment" property at some point, which would potentially overlap with this usage. The equipment value would be an item like Canon EOS 300D (Q64039) or a scanner model. Ghouston (talk) 03:49, 5 September 2019 (UTC)
I think this property can be used to describe both the digital file and the physical object, with sevaral values possible. Technique and equipment are not the same, e.g. with Canon EOS 300D (Q64039) you can do 3 of the 4 examples I gave at top. Christian Ferrer (talk) 04:34, 5 September 2019 (UTC)
"File-making technique" seems like a strange way to describe e.g., an image capture on photographic film, since no file was involved until a separate digitization process. The techniques and equipment are linked, but whether one should be a qualifier of the other I'm not sure. Ghouston (talk) 04:54, 5 September 2019 (UTC)
So maybe it should be "file and image-making technique"? or more simply "media-making technique"? Christian Ferrer (talk) 11:02, 5 September 2019 (UTC)
Or fabrication method (P2079), which can apply to anything. Would we lose anything by using that? Ghouston (talk) 23:01, 5 September 2019 (UTC)
No, indeed. I guess we can use fabrication method (P2079). Christian Ferrer (talk) 11:14, 6 September 2019 (UTC)

DigitaltMuseum IDEdit

   Under discussion
DescriptionIdentifier at DigitaltMuseum
RepresentsDigitaltMuseum (Q11125708)
Data typeExternal identifier
Template parameterN/A
DomainCommons images (Structured Commons)
Allowed values\d{12}
Example 1c:File:Bark Famlien av Larvik - Larvik museum - LSJ.00055.jpg021025559657
Example 2c:File:Skruedamperen Vulcan - Larvik museum - LSJ.00007.jpg021025559294
Example 3c:File:Flicka i Moradräkt med skinntröja, Mora. Akvarell av P.Södermark - Nordiska museet - NMA.0070044.jpg021015860618
Example 4c:File:Tre bilder på barn i dräkt. Akvarell av P.Södermark - Nordiska museet - NMA.0070066.jpg021015860210 or
Planned useUsed for images uploaded via DigitaltMuseum by Wikimedia Norge and Wikimedia Sverige.
Number of IDs in sourceThousands if not millions
Expected completenessalways incomplete (Q21873886)
Formatter URL$1/
Robot and gadget jobsCurrent script used to upload from DigitaltMuseum to Commons should be amended to also include this property.


DigitaltMuseum is, as the name implies, a digital museum website used by plenty of museums in both Norway and Sweden. This property would be used in Structured Commons to link back to DigitaltMuseum from the images that are uploaded there by especially Wikimedia Sverige and Wikimedia Norge efforts. Jon Harald Søby (WMNO) (talk) 13:51, 14 August 2019 (UTC)


@André Costa (WMSE), Alicia Fagerving (WMSE), Ambrosiani: I think you might be interested in this. Jon Harald Søby (WMNO) (talk) 13:51, 14 August 2019 (UTC)

  •   Support David (talk) 05:11, 15 August 2019 (UTC)
Might be better to use the UUID which I think can be considered stable, while the regular ID could change? We should check with KulturIT. Is it a problem that the relation is one-to-many, since lots of Digitalt museum IDs will be referenced by multiple Commons objects? Also, we can use for both Norwegian and Swedish links if that makes the syntax easier. Ambrosiani (talk) 08:41, 15 August 2019 (UTC)
@Ambrosiani: Are the UUIDs user-visible anywhere (without going through an API)? I wasn't able to find anything more specific than this one. Jon Harald Søby (WMNO) (talk) 15:06, 15 August 2019 (UTC)
yes, they are visible right below the ID. URL works as well, see for example Ambrosiani (talk) 15:19, 15 August 2019 (UTC)
I sent an email to Espen at KulturIT about this, hopefully they will contribute to the discussion as well. Ambrosiani (talk) 15:20, 15 August 2019 (UTC)
@Ambrosiani: Great! I didn't notice the UUID there, I was too focused on the URL of the images. I'm neutral as to which one to choose, so if Espen has some input on which one is more stable that would be great. 😊 Jon Harald Søby (WMNO) (talk) 07:39, 17 August 2019 (UTC)
  •   Support Reply from KulturIT: Both IDs are persistent so we can choose whichever we want. Then I think the ID used in the url is more easy to understand so let's go with that. I.e. I think the proposal should stand as it is (since I noticed that is already used as the domain) Ambrosiani (talk) 13:30, 20 August 2019 (UTC)

georeferencing control point dataEdit

   Under discussion
DescriptionTabular data file in the Commons Data: namespace containing georeferencing control points for all or part of a Commons old map image
Representsgeoreferencing (Q772007)
Data typeTabular data
DomainCommons image
Allowed valuesData:.+\.gcps(\..*)?\.tab
Example 1File:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.jpgData:Pigot_and_Co_(1842)
Example 2MISSING
Example 3MISSING
Sourceuser input via app; also existing data in Commons MapWarper, NYPL MapWarper, British Library Georeferencer, David Rumsey maps, other sites with georeferencing
Planned useMovement of data from Commons MapWarper site to Commons Data namespace; import from external sites
See alsoWikidata:Property proposal/external georeferencer URL

georeferencing pixel mask dataEdit

   Under discussion
DescriptionTabular data file in the Commons Data: namespace containing the pixel coordinates of the boundary of the georeferenced area
Representsgeoreferencing (Q772007)
Data typeTabular data
DomainCommons image
Allowed valuesData:.+\.mask(\..*)?\.tab
Example 1File:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.jpgData:Pigot_and_Co_(1842)
Example 2MISSING
Example 3MISSING
Sourceuser input via app; also existing data in Commons MapWarper, NYPL MapWarper, British Library Georeferencer, David Rumsey maps, other sites with georeferencing
Planned useMovement of data from Commons MapWarper site to Commons Data namespace; import from external sites
See alsoWikidata:Property proposal/external georeferencer URL

georeferencing mask geoshapeEdit

   Under discussion
DescriptionGeoshape containing the georectified latitude and longitude coordinates of the boundary of the georeferenced area
Representsgeoreferencing (Q772007)
Data typeGeographic shape
DomainCommons image
Allowed valuesData:.+\.mask(\..*)?\.)\.map
Example 1File:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.jpgData:Pigot_and_Co_(1842)
Example 2MISSING
Example 3MISSING
Sourcecomputed from pixel mask using georectification based on a particular set of control points
Planned useMovement of data from Commons MapWarper site to Commons Data namespace; import from external sites
See alsoWikidata:Property proposal/external georeferencer URL


Moving Georeferencing data from its present silo in the MapWarper application into the Commons Data: namespace brings it much more naturally into the domain of the Commons community, and will make it much more accessible for use in gadgets or other reuse.

These SDC properties will enable apps to find what has been put where, for the two main types of information used as input for the process; and for queries and apps to access a geoshape showing the real-world position and characteristic boundary of the georectified map.

qualifiers, etcEdit

Note that multiple sets of control-point (gcps) data may exist concurrently for the same image. Different sets of control points may relate to different maps contained in the image (eg multiple sub-maps; or main map/inset map(s) combinations); to sets of control point data obtained independently from different sources (eg Commons MapWarper / external source); or to control point data obtained from different features for different purposes (eg projection estimation [2] is often most effectively achieved based on control points representing a graticule of intersections of lines of latitude and longitude, whereas final map-warping often aims to distort the map to most accurately place depicted land-features and population centres).

Different sets of control points may be associated with the same or with different pixel masks.

The output mask geoshape will in turn relate to a particular pair of control-point and pixel-mask datafiles.

These potentially complicated relationships can be captured by qualifiers on the statements, in particular parallel applies to part (P518) qualifiers on each of the statements to indicate a particular part of the image (eg main map / top-left map / inset map / second inset map etc), object has role (P3831) to distinguish sets of control points relating to different features; and referencing to distinguish sets of control points with different provenances.

The control-point and pixel-mask statements should also be qualified to associate them with a particular revision-id of the file (Wikidata:Property proposal/image revision-id), in case it may subsequently have been cropped/modified.

The georectified mask should be linked to the inputs it is derived from (Wikidata:Property proposal/based on tabular data). It should also have, for convenience, a P518 to indicate the particular map it relates to, where the image contains multiple maps. Jheald (talk) 06:01, 17 August 2019 (UTC) (revised proposal)


  • Proposed. Jheald (talk) 06:01, 17 August 2019 (UTC)

based on tabular dataEdit

   Under discussion
DescriptionCommons tabular data file that a Commons file (or statement) derives from
Representstable (Q496946), based on (Q30171963)
Data typeTabular data
DomainCommons file; also as a qualifier on statements; and perhaps in a reference
Allowed valuesData:.*\.tab
Example 1File:Commons
Example 2georeferencing mask geoshape statement → Data:Pigot_and_Co_(1842)
Example 3MISSING
SourceData: namespace on Commons
Planned useQualify "georeferencing_mask_geoshape" statements
See alsobased on (P144)


Needed to link Commons files to data that was used to generate them, if we hold it.

Also, in georeferencing, needed to identify which gcps file was used to generate a mask file. Jheald (talk) 09:21, 17 August 2019 (UTC)


  • Proposed. Jheald (talk) 09:21, 17 August 2019 (UTC)
  •   Support David (talk) 06:48, 18 August 2019 (UTC)

image revision-idEdit

   Under discussion
DescriptionQualifier to inidicate the particular revision of an image that a statement refers to
Data typeString
Domainstatements with value: media
Allowed values\d+
Example 1File:Pigot and Co (1842) p2.138 - Map of Lancashire.jpg (revision-sensitive statement) → 279847594
Example 2File:Larousse,_Plan_de_Paris,_1900_-_David_Rumsey.jpg (revision-sensitive statement) → 180884966
Example 3File:1768_Jeffreys_Wall_Map_of_India_and_Ceylon_-_Geographicus_-_India-jeffreys-1768.jpg (revision-sensitive statement) → 345654849
Planned useTo indicate which revision of a map image has been georeferenced on Commons MapWarper. But further use-cases are likely to emerge.
See alsoWikimedia import URL (P4656)


Sometimes it is important to be able to indicate which particular revision of a Commons image a Wikidata or SDC statement refers to. For example, georeferencing information will fail to be correct if an image has been cropped. A mechanism is therefore necessary to be able to specify a particular version of a Commons file. Jheald (talk) 13:16, 14 August 2019 (UTC)


  • Proposed. Jheald (talk) 13:16, 14 August 2019 (UTC)

region within imageEdit

   Under discussion
DescriptionQualifier to identify a polygon within an image that the main statement applies to
Data typeString
Example 1Georeferencing statement about File:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.jpg ; Qualifier: region within image → { "type": "poly", "coords": [ [ 111.0, 2017.0 ], [ 913.0, 2012.0 ], [ 1239.0, 1847.0 ], [ 1235.0, 1296.0 ], [ 1219.0, 595.0 ], [ 1007.0, 533.0 ], [ 872.0, 534.0 ], [ 780.0, 467.0 ], [ 740.0, 375.0 ], [ 623.0, 363.0 ], [ 527.0, 185.0 ], [ 117.0, 181.0 ], [ 95.0, 387.0 ], [ 115.0, 881.0 ], [ 207.0, 1021.0 ], [ 123.0, 1665.0 ], [ 111.0, 2017.0 ] ] }
Example 2MISSING
Example 3MISSING
Planned useTo specify the bounding polygon of a mask that the (jagged, irregular) boundary of the part of an image that represents a map that has been georeferenced.
See alsorelative position within image (P2677)


There are a number of use-cases for annotation etc where it would be useful to define a polygonal sub-region of an image. One is to eg indicate the outline boundary of part of the image that is a map that has been georeferenced. This property is to allow this.

The JSON format proposed would allow the various kinds of regions of images (ie polygons, rectangles, circles) that can currently be defined in mw:Extension:ImageMap to be translated into Structured Data qualifiers. Other types of region we might like to consider might include polygons-with-holes and multi-polygons (cf types of regions definable in Well-known text (WKT)).

Unlike relative position within image (P2677), the present property is intended to be used to specify an irregular region rather than a rectangle, in terms of pixel-perfect coordinates on a single actual image rather than a generic item that might correspond to many images. Jheald (talk) 19:00, 14 August 2019 (UTC)


  • Proposed. Jheald (talk) 18:07, 14 August 2019 (UTC)

attribution textEdit

   Under discussion
Descriptionthe attribution string as specified by the licensor, that re-users are obliged to name
Data typeString
Allowed valuestext
Example 1File:Mycalesis 1 by Kadavoor.jpg → "© 2010 Jee & Rani Nature Photography (License: CC BY-SA 4.0)"
Example 2File:London Zoo 01118.jpg → "© Nevit Dilmen"
Example 3File:Summerjam 20150705 Yakoto IMG 0077 by Emha.JPG → "© Emha / Wikimedia Commons / CC-BY-SA-4.0"
SourceLicense template with optional attribution like Template:Cc-by-sa-4.0
Planned useUse in combination with license (P275) for files on Commons
See alsolicense (P275)


On Commons it's possible to specify a customer attribution string for Creative Commons attribution and attribution-shareAlike licenses (and some other ones). This string can be put in the self template and is passed to the license template like Template:Cc-by-sa-4.0. We need to be able to store this as structured data to be able to add licensing data to structured data on Commons. I picked string instead of monolingual text because often the text is quite language independent. I think "attribution text" sounds slightly better than "attribution string" or "credit line", but I'm fine with either naming (and the others as an alias). See also Commons:Credit line. It can also be used for courtesy attribution. Multichill (talk) 14:35, 25 August 2019 (UTC)


  •   Oppose This should be generated out of the other statements like author and license. --GPSLeo (talk) 15:32, 25 August 2019 (UTC)
    • @GPSLeo: That will happen if the user didn't explicitly define this which is probably 95%+ of the files. This new property is to override that as happened in the examples. Do you want to deny the copyright holder the right under a license to provide a custom attribution? Or maybe name the property "custom attribution text" to make this clearer? Multichill (talk) 16:33, 25 August 2019 (UTC)
      • These "custom attributions" are just recommendations. Only the attribution required by the license is correct. Especially your second example is against the attribution required by the license, because it dose not include the license as required for CC-BY-SA. This could provide problems in some cases. --GPSLeo (talk) 19:38, 25 August 2019 (UTC)
        • These "custom attributions" are just recommendations. Only the attribution required by the license is correct.
          This seems unrelated to the proposal at hand. You are right that having a property for attribution text (which is already Commons template parameters) requested by a creator doesn't invalidate the license, and the reuser is still obligated to fulfill its terms. But there is no reason to prevent customized attribution text for those who want to request it. Even CC0 or PD materials can still have credit lines for users willing wanting to give credit (by the same logic that you should still cite a publisher of a public domain book in a bibliography).
        • Especially your second example is against the attribution required by the license, because it dose not include the license as required for CC-BY-SA.
          Attribution and licensing are different concepts. The "Sharealike" requirements for licenses does not mean those licenses have to be part of some kind of "attribution" string. That is a different property, and the licensing requirements should be fulfilled according to the terms of the license, regardless of the value of the attribution text. Dominic (talk) 20:22, 3 September 2019 (UTC)
  •   Comment I believe we currently have some credit-lines with hyperlinks (not only URLs, but linked ones). Not saying that we should support this, but just wanted this to be made explicit :-) Jean-Fred (talk) 17:23, 25 August 2019 (UTC)
  •   Support Christian Ferrer (talk) 03:30, 27 August 2019 (UTC)
  •   Support Dominic (talk) 20:22, 3 September 2019 (UTC)