Wikidata:Property proposal/Commons


Property proposal: Generic Authority control Person Organization
Creative work Place Sports Sister projects
Transportation Natural science Lexeme Wikimedia 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 2021/05.

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

Wikimedia CommonsEdit

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)_p2.138_-_Map_of_Lancashire.gcps.tab
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
  •   Support I think this is an excellent idea. However we should have more examples. Are there any plans to use this data in some way?

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)_p2.138_-_Map_of_Lancashire.mask.tab
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
  •   Support --Jarekt (talk) 03:01, 1 July 2020 (UTC)

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)_p2.138_-_Map_of_Lancashire.mask.map
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

MotivationEdit

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 [1] 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)

DiscussionEdit

  • Proposed. Jheald (talk) 06:01, 17 August 2019 (UTC)
  •   Support I've just watched the summary of what is possible at min 22.30 of this presentation at Wikimania. The potential for this looks amazing. - Ambrosia10 (talk) 20:58, 18 August 2019 (UTC)
  •   Support I also saw this demoed at the Wikimania hackathon showcase and think it makes a lot of sense. --Daniel Mietchen (talk) 00:31, 19 August 2019 (UTC)
  •   Support Thisismattmiller (talk) 13:20, 19 August 2019 (UTC)
  •   Support --Sabas88 (talk) 16:12, 19 August 2019 (UTC)
  •   Support Buccalon (talk) 17:54, 19 August 2019 (UTC)
  •   Support link Wikimania 2019: Hackathon Showcase 22:05 --Salgo60 (talk) 06:33, 22 August 2019 (UTC)
  •   Support Never heard about this, but it looks like it could be covered by Wikidata. --Juandev (talk) 20:15, 29 September 2019 (UTC)
  •   Conditional support @Jheald: Hello, Could you include other examples so that future properties don't start production with "warnings"? This will also verify if the RegEx are compliant. —Eihel (talk) 06:45, 20 January 2020 (UTC)
  •   Support Susanna Ånäs (Susannaanas) (talk) 10:12, 17 May 2020 (UTC)

I agree that we need to get the data out of the silo, but this proposal seems to make things more complex than needed. I've been poking around a bit today based on https://github.com/bertspaan/wikimania-hackathon-2019 . This is what we want to store and how it's done in the example:

I would like to have just one (geojson) file to contain all this data. To test this I'm using Commons:Data:Georectification.example.geojson.map which is a json file with a geojson part in the data field (see also mw:Help:Map Data). Above I read the motivation for multiple pieces. Just create a new map data file if you have another source or another view. Mixing everything makes it extremely complicated. As for the specific revision. These maps shouldn't be overwritten at all per overwrite policy. So one file per warping. Containing the points mentioned above. I had a look at the RFC and Geojson allows foreign members. In the example I made use of that to have several parts in the file:

  • A feature of type "mask" contain the polygon for the mask. You can see the shape on the map
  • A feature of type "gcp" for every geo control point containing the pixel x and y and a point with the lat and long. I would like to group these and maybe add numbering to them. Not sure what is possible here and I have to poke a bit more (maybe GeometryCollection)
  • A feature of type "pixelmask" containing the file name, the entity id and all the pixels (x and y) for the pixel mask

The exact format is open for improvements. This way we can have everything in just one data file making it much easier to work with. Note that the data file contains what file it applies to so it doesn't even have to be linked for the file to work. I would prefer to go down this path and only have one property to link the image file with the geojson file. Multichill (talk) 11:05, 17 May 2020 (UTC)

  • I   Support this new proposal. I cannot see any obstacles in putting the different parts together.
    • It makes great sense in putting the two different parts of the mask in the same file.
    • Bundling all parts of one warping reduces complexity, and makes versioning easier. – Susanna Ånäs (Susannaanas) (talk) 15:29, 17 May 2020 (UTC)
  • Looks reasonable to me. I'd may have suggestions for small tweaks, I'll have to think some things through. But it is a good start. I'd suggest adding a 'sha1' or 'sha256' field to pixelmask, to identify and track the exact version of an image that the mapping was made from, should be easy for mapwarper to add that. TheDJ (talk) 11:09, 18 May 2020 (UTC)
    • @TheDJ: thanks for you input. My main point is to use one Geojson file with everything in it. I made an example to show it's possible. The format is in no way final and we should probably think it through properly before mass deploying it. I like the hash suggestion. Let's just do the sha1 of the file because that's already exposed in the api anyway and saves the hassle of calculating it ourselves. Multichill (talk) 20:37, 18 May 2020 (UTC)
  •   Support   Don't ping me NMaia (talk) 01:29, 11 November 2020 (UTC)
  • Looks like this (like the other Commons property proposals) fell thru the cracks; there is clear support for the three proposals on this page, so I've marked them ready. JesseW (talk) 21:56, 30 March 2021 (UTC)
    • Actually, looking further, it looks like they are superseded (maybe) by @Multichill:'s proposal. @Jheald:, what are your thoughts? JesseW (talk) 21:59, 30 March 2021 (UTC)
      • @JesseW: Thanks for going through these proposals. Having talked about it with User:Multichill since first proposing this, I agree that it does make sense to keep all the data together in one file, as sketched out at c:User_talk:Multichill/Map_warping_format, so I think that probably is the best way forward. The separate files have a certain amount to be said for them in terms of transparency, but I agree that is outwieghed by the convenience of just having to deal with one file, and not having to worry about any versioning issues. So there would then be one property "georeferencing data" pointing to a 'geographic shape' object, ie a .map file in the Data: namespace on Commons.
I am not sure whether one could go ahead and create such a property based on the support already shown on this page, or whether it would need a new proposal. But we are probably quite close to wanting to deploy at least some test examples of this, and IMO it would be useful for development to have statements on SDC pointing to which the relevant georeferencing data file was. Jheald (talk) 11:31, 31 March 2021 (UTC)
I think the given support for Multichill's proposal is sufficient, but it'd be nice to have the proper template set up to make it clear what exactly is being proposed. Once you do that, I think it's fine to mark it as ready. JesseW (talk) 14:20, 31 March 2021 (UTC)
@Jheald, JesseW: I realize this has had a long wait for various reasons, but I think it could be dealt with quickly (i.e. in about a week) as a new proposal, assuming nobody objects. I think that would be cleaner than trying to rewrite the proposals on this page for the new approach. ArthurPSmith (talk) 17:36, 31 March 2021 (UTC)

image revision-idEdit

   On hold
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)

MotivationEdit

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)

DiscussionEdit

  • Proposed. Jheald (talk) 13:16, 14 August 2019 (UTC)
  •   Comment This is not going to work properly, because, when someone will upload a new version, the file will change its version number, but the value in the property may stay the old one. Moreover, there was a discussion with WMF team, that it's not possible to track different versions so they cannot be stored in Wikidata. --Juandev (talk) 20:21, 29 September 2019 (UTC)
    • @Juandev: The whole point is that we want the property to point to the old version of the image, because that is the one that the georeferencing was done against, not any later reupload that may potentially have been cropped. Jheald (talk) 22:15, 13 October 2019 (UTC)
  • I think the (current) samples give the revision of the file description page, not the image version. --- Jura 09:35, 13 October 2019 (UTC)
  • Slight   Support. I understand the argumentation, but during my 15 year old presence I havent encountered such situation.--Juandev (talk) 12:47, 15 November 2019 (UTC)
  • Slight   Oppose. I do not see the need, and it might not be technically freezable. I am open to change my vote if there is a clear need. --Jarekt (talk) 01:54, 15 May 2020 (UTC)

I marked this proposal as on hold. Currently we have two solutions:

  • Wait phab:T28741 to be fixed so file versions have unique identifiers
  • Create a property "image timestamp", but 1. we still does not have the datatype unless we store timestamp as string and 2. timestamp may still be not unique.

--GZWDer (talk) 23:20, 28 May 2020 (UTC)

Commons postcards categoryEdit

   Under discussion
Descriptionname of the Wikimedia Commons category specifically for postcards or of this item (without the prefix "Category:")
Data typeItem
Allowed valuesOnly existing Commons categories are allowed. The name is without the "Category:" prefix
Example 1Dresden (Q1731)Category:Postcards of Dresden (Q82326598)
Example 2Asinus (Q2305786)Category:Postcards of donkeys (Q82326609)
Example 3Naumburg Cathedral (Q5938)Category:Naumburg Cathedral Postcards (Q82326616)
Example 4Finland (Q33)Category:Postcards of Finland (Q82326618)
Planned useIn items and Commons infoboxes
See alsoCommons category (P373), P3722 (P3722), category for the interior of the item (P7561)

MotivationEdit

I want use this for automation/bots. If a postcard has only the "Category:Postcard" and "Category:Dresden" then we can move it in this category, which we found in this property. sk (talk) 05:28, 15 January 2020 (UTC)

DiscussionEdit

  Support as an ID für external usage. Conny (talk) 05:44, 15 January 2020 (UTC).
  •   Support after the change of datatype. Mike Peel (talk) 20:56, 15 January 2020 (UTC)   Oppose with the current datatype, I would support if it is using the 'item' datatype to link to a category item per category for people born here (P1464), category for the interior of the item (P7561), category for ship name (P7782) and others - then it will auto-update when Commons categories are moved, rather than requiring manual updates. Thanks. Mike Peel (talk) 06:32, 15 January 2020 (UTC)
    @Mike Peel: Please change it. I don't know the right value for this datatype. "Item"? Thanks. -- sk (talk) 08:49, 15 January 2020 (UTC)
    @Stefan Kühn: It looks like @Conny: changed the type, I've updated the examples and a bit of the description, does that look OK to you? If so then I'll switch my !vote to support. Thanks. Mike Peel (talk) 20:10, 15 January 2020 (UTC)
    @Mike Peel: That's fine. Thanks! -- sk (talk) 20:52, 15 January 2020 (UTC)
  •   Oppose use related category (P7084). --- Jura 10:25, 20 January 2020 (UTC)
  •   Oppose already there are too many "Commons xxxx category" properties. How many more? Proposing endless more properties is not a good or sustainable mechanism. We need another, more scalable way to do this. Jheald (talk) 16:52, 20 January 2020 (UTC)
  •   Comment whats the point of structuring Commons categories. There was some general agreement, that categories wont be structured and tags are an alternative system to file sorting on Commons. --Juandev (talk) 15:32, 9 February 2020 (UTC)
  •   Oppose per Jheald. Multichill (talk) 19:34, 3 June 2020 (UTC)
  •   Oppose I think we should avoid creating more logic based on categories and instead find a combination of SDC statements to represent this, e.g. location (P276)Dresden (Q1731) and genre (P136)postcard (Q192425). Belteshassar (talk) 20:34, 14 June 2020 (UTC)
  •   Comment The tagging system on Commons (the “depicts” property) is unsuitable for use at this time. It needs better documentation and user training before it can be considered as a replacement for categories. Senator2029 15:17, 24 July 2020 (UTC)
  •   Oppose per Jheald nad Belteshassar. --Daniel Baránek (talk) 07:40, 6 May 2021 (UTC)

language level of locutorEdit

   Under discussion
Representslanguage level (Q12775443)
Data typeItem
DomainLingua Libre (Q60024037)
Allowed valuesto be defined/items have to be created if this proposal is accepted (native speaker / good level / average level / beginner)
Example 1File:LL-Q150 (fra)-Nattes à chat-banane.wav language of work or name (P407) French (Q150) → language level = native speaker
Example 2File:LL-Q188 (deu)-Nattes à chat-Baum.wav language of work or name (P407) German (Q188) → language level = average level
Example 3MISSING
Sourcehttps://lingualibre.org

MotivationEdit

Lingua Libre uploads audio file on Wikimedia Commons and saves the information related to this file in a template. These information could be stored using Structured data. This proposal aims to be used for prononciation redording from Lingua Libre (and others). See T239272 for more informations. Pamputt (talk) 15:49, 9 April 2020 (UTC)

DiscussionEdit

  •   Comment It seems that this doesn't match any of ll's current template fields (see c:Template:Lingua_Libre_record#Template_parameters). --- Jura 08:33, 10 April 2020 (UTC)
    @Jura1: In fact it is a data that is collected for each speaker on Lingua Libre, even if it's not yet in the template on Commons. — 0x010C ~talk~ 09:42, 10 April 2020 (UTC)
  • @Pamputt:, I think that is a speaker property and not a file property, as all the files from a given speaker should have the same level. Also do we have a lot of pronaunciation files dome by non-native speakers? --Jarekt (talk) 02:41, 15 May 2020 (UTC)
    We have already some, see for example (File:LL-Q188 (deu)-teste (Pamputt)-Vater.wav) For a precise quantifying, maybe 0x010C can provide a number. And yes, this property applies to the speaker on the LinguaLibre website. Yet, once it is uploaded to Wikimedia Commons, only the file exists. That is why we propose the creation of this property, to keep this information "attached" to the Commons file. Maybe, we have to think a better property name to disambiguate that point. Pamputt (talk) 05:51, 15 May 2020 (UTC)
  •   Comment I am not sure whether we can use generic label for specific thing.--Juandev (talk) 08:32, 26 June 2020 (UTC)
  •   Comment @Pamputt, Juandev, Jarekt, Jura1, WikiLucas00, Poslovitch: The European Union −which has the unique challenge to manage 50~ languages within its own institutions− has set in place the w:en:Common European Framework of Reference for Languages (CEFR, Q221385) with levels :
    • Beginner : A1, A2
    • Intermediate: B1,B2
    • Advanced: C1, C2
    • Native
This Framework is leading the way internationally for language assessment. All major European languages teaching now follow this framework. Most European national languages too, by now. There is also copycat studies and frameworks by other major languages : Chinese, Japanese, etc, so this framework and its levels are expanding internationally. There are formal assessment tests you may pass to evaluate your language level, but the levels are human-friendly enough so that anyone could do a good guess on someone's level on this scale. It could be something to explore for us. AND the property may actually already exist on wikidata. Yug (talk) 00:06, 17 February 2021 (UTC)

intended background colorEdit

   Ready Create
DescriptionThis transparent image is intended to be used in front of a backgroundcolor
Representsbackground (Q13217555)
Data typeItem
DomainCommons image
Allowed valuesInstances and subclasses of color (Q1075)
Example 1File:Youtube Music Full Logo.svgdark grey (Q71392381)
Example 2File:Logo of YouTube (2005-2011).svgwhite (Q23444)
Example 3File:YouTube social media logo.svgno value

MotivationEdit

In an application I am working on, logos like File:Youtube Music Full Logo.svg appear invisible in front ob a white background. I'd like to display those on an appropreate background color. no value would mean, It should work on most colors. If you have a better idea, how to do that, please comment 🤷‍♂️--Loominade (talk) 11:52, 18 June 2020 (UTC)

DiscussionEdit

  •   Comment I don't understand your proposal. Both images have kind of transparentish (a mixture of gray and white patter after hover) background. --Juandev (talk) 08:46, 26 June 2020 (UTC)
no, they don't. The pattern you see on hover is added by the website the counter that very same problem.--Loominade (talk) 12:59, 26 June 2020 (UTC)

Unless @Juandev: wants to oppose, I think (and have marked) this as ready. JesseW (talk) 13:50, 23 April 2021 (UTC)

mediumEdit

   Under discussion
DescriptionType of medium depicted by the image, eg. photograph, painting, sculpture, etc. (not genre!)
Data typeItem
Example 1File:Bangor,_Suspension_Bridge,_From_Anglesey_(254)_LACMA_M.2008.40.202.10.jpg -> photograph (Q125191)
Example 2File:Portrait LACMA M.77.25.jpg -> painting (Q3305213)
Example 3File:Andromeda and the Sea Monster, and Leda and the Swan, 11364501.jpg -> sculpture (Q860861)
Planned useWikimedia Commons structured data


MotivationEdit

Using this we can distinguish between photographs, paintings, drawings, etc. --Adam Harangozó (talk) 19:03, 23 August 2020 (UTC)

DiscussionEdit

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 it.wiki 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) Jean-Fred (talk) 15:21, 26 September 2019 (UTC) Premeditated Vahurzpu Dr Isaac Andy (talk) 05:21, 29 January 2020 (UTC)
  Notified participants of WikiProject Commons Ruthbrarian (talk) 16:50, 6 May 2020 (UTC) Erussey (talk) 17:12, 6 May 2020 (UTC) Pobocks (talk) 17:36, 6 May 2020 (UTC) Codewitch (talk) 17:57, 6 May 2020 (UTC) Lottebelice (talk) 11:34, 12 July 2020 (UTC) Librarian lena (talk) 19:03, 14 August 2020 (UTC) Jneubert (talk) 07:03, 24 September 2020 (UTC) Sp!ros (talk) 12:39, 6 October 2020 (UTC) Sradovsk (talk) 16:13, 9 December 2020 (UTC)  Notified participants of WikiProject Archives Linked Data Interest Group Weadock313 (talk) 01:27, 20 April 2020 (UTC) 2le2im-bdc (talk) 19:36, 30 May 2018 (UTC) Beat Estermann (talk) 23:29, 1 June 2018 (UTC) Flor WMCH Gilliane Kern (talk) 05:47, 5 June 2018 (UTC) Mauricio V. Genta (talk) 23:42, 1 September 2018 (UTC) Laureano Macedo (talk) 09:49, 13 September 2018 (UTC) Daniel Mietchen VIGNERON scottythered Patafisik anarchivist KelliBee123 (talk) 16:29, 6 August 2019 (UTC) Anne Chardonnens (talk) Yooylee 30 (talk) 23:15, 11 August 2019 (UTC) Mlemusrojas (talk) 19:40, 19 February 2019 (UTC) erussey Kcohenp (talk) 16:28, 03 June 2019 (UTC) Mrtngrsbch Amandine (talk) 19:58, 12 August 2019 (UTC) René La contemporaine (talk) 11:17, 13 February 2020 (UTC) Sp!ros (talk) 09:00, 27 April 2020 (UTC) Ccooneycuny (talk) 16:49, 19 May 2020 (UTC) Librarian lena (talk) 19:57, 11 August 2020 (UTC) Valeriummaximum (talk) 16:42, 23 August 2020 (UTC) Jneubert (talk) 07:11, 24 September 2020 (UTC) MaryCDominique (talk) 10:06, 25 October 2020 (UTC) --Epìdosis 17:16, 16 February 2021 (UTC) P feliciati (talk) 17:18, 16 February 2021 (UTC) JnyBn (talk) 07:27, 22 April 2021 (UTC)   Notified participants of WikiProject Archival Description Tubezlob VIGNERON Jane023 Pigsonthewing Ambrosiani Spinster Wittylama Fuzheado Emijrp Daniel Mietchen Marsupium Martingggg Anne-LaureM Beat Estermann Manu1400 Mauricio V. Genta Patafisik MartinPoulter Tris T7 BeatrixBelibaste Clifflandis Mrtngrsbch Reciproque Weadock313 (talk) 21:56, 27 November 2019 (UTC) Nomen ad hoc Crowjane7 Scarey1 (talk) 11:55, 9 February 2021 (UTC)   Notified participants of WikiProject Museums Multichill (talk) 11:28, 8 August 2014 (UTC), focus on the Netherlands Husky (talk) 11:38, 8 August 2014 (UTC) - Cool, i'd like to focus on building tools to visualise progress. Spinster (talk) 07:00, 9 August 2014 (UTC) Happy to help with manual finetuning that can't be done by bots, and anything else on the 'soft/wet' side of this project. I'm dreaming of complete artists' oeuvres on Wikidata! Rich Farmbrough (talk) Time to learn2Wikidata Jheald (talk) 12:33, 17 August 2014 (UTC) Kippelboy (talk) 07:01, 21 August 2014 (UTC) (Focus on Catalan paintings (subdivision of Spain) Mushroom (talk) 12:27, 21 August 2014 (UTC) Jane023 (talk) 09:11, 3 October 2014 (UTC) work on Dutch 17th-century paintings and landscapes of Haarlem; Most recently, the sum of all "attributed" paintings by Frans Hals, which is nearly done Missvain (talk) 18:51, 18 October 2014 (UTC) (talk) 13:27, 15 November 2014 (UTC) Zolo (talk) 14:57, 23 November 2014 (UTC) Beat Estermann (talk) 10:33, 3 December 2014 (UTC) (Focus on Swiss heritage institutions) Vladimir Alexiev (talk) 15:07, 23 January 2015 (UTC) KRLS (talk) 11:26, 11 February 2015 (UTC) (Focus on Catalan area museums) DivadH (talk) 11:35, 1 March 2015 (UTC) ,happy to help out with any questions in regards to the Europeana API, how to best query it, and/or our metadata Xcia0069 (talk) 11:49, 8 March 2015 (UTC), Work on data related to Gianlorenzo Bernini and Artemisia Gentileschi. Work at Europeana too ! Susannaanas (talk) 07:29, 9 March 2015 (UTC) Wittylama (talk) 17:29, 20 March 2015 (UTC) Fabrice Florin (talk) 02:35, 26 June 2015 (UTC) I can help in California later this year. Vaughn88 (talk) 15:58, 15 July 2015 (UTC) I can help! Raymond Ellis (talk) 19:31, 17 August 2015 (UTC) Hsarrazin (talk) 14:11, 29 August 2015 (UTC) - will give a hand with Creators and AC :) louis-garden (talk) 14:21, 31 August 2015 (UTC) for italian paintings (XIIe-XVIIe) Olivier (talk) 21:46, 8 September 2015 (UTC) Kopiersperre (talk) 11:33, 20 November 2015 (UTC) ProtoplasmaKid (talk) 03:49, 23 February 2016 (UTC) Micru (talk) 11:19, 29 February 2016 (UTC) Stuart Prior (WMUK) (talk) 11:04, 28 April 2016 (UTC) Hannolans (talk) 23:14, 22 October 2016 (UTC) Geraki (talk) 09:52, 24 October 2016 (UTC) (Focus on Greece) PatHadley (talk) 12:16, 3 January 2017 (UTC) MartinPoulter (talk) 14:54, 11 January 2017 (UTC) Working to get data from the University of Oxford (Q34433) and its component institutions shared on Wikidata. Pablísima (talk) 18:07, 8 February 2017 (UTC) Carl Ha (talk) 22:10, 9 February 2017 (UTC) Marsupium (talk) 19:44, 22 May 2017 (UTC) Mauricio V. Genta (talk) 16:15, 26 June 2017 (UTC) Shani Evenstein (talk) 10:26, 26 July 2017 (UTC) Nasty nas (talk) 07:45, 24 August 2017 (UTC) Bodhisattwa (talk) 14:28, 28 October 2017 (UTC) Joalpe (talk) 18:39, 9 November 2017 (UTC) Fuzheado (talk) 18:33, 30 November 2017 (UTC) Sarasays (talk) 20:00, 1 December 2017 (UTC) Thierry Caro (talk) 07:30, 9 December 2017 (UTC) John Samuel 18:29, 21 December 2017 (UTC) Jklamo (talk) 12:06, 31 December 2017 (UTC) Reosarevok (talk) 10:28, 15 February 2018 (UTC), focus on Estonia Ambrosia10 (talk) 19:48, 19 February 2018 (UTC) Subsublibrary (talk) 03:17, 22 February 2018 (UTC) Martingggg (talk) 07:00, 22 February 2018 (UTC), focus on Argentine and Hispanic America Kruusamägi (talk) 16:42, 13 March 2018 (UTC), focus on Estonia SIryn (talk) 10:36, 9 June 2018 (UTC) Jarekt (talk) 13:49, 7 September 2018 (UTC), focus on moving metadata from Commons to Wikidata Walkuraxx (talk) 10:00, 30 November 2018 (UTC) Omotecho (talk) 22:11, 21 January 2019 (UTC), focus on Japan GualdimG (talk) 16:19, 19 February 2019 (UTC) Léna (talk) 08:57, 4 April 2019 (UTC) Yann (talk) 09:53, 9 June 2019 (UTC) Paul Cézanne (Q35548) for a start... Abbe98 (talk) 19:25, 18 June 2019 (UTC) Daniel Mietchen (talk) 15:36, 23 July 2019 (UTC) Have been doing small things here and there — especially improving items around what is depicted on paintings — so might as well sign up. Jbandrews (talk) 02:14, 16 October 2019 (UTC) Product Manager at the Art Institute of Chicago. Amadalvarez (talk) 06:19, 19 October 2019 (UTC) Meresquared (talk) 14:51, 22 October 2019 (UTC) I'm interested in adding depiction descriptions to paintings, and improving data around women and POC. Clifford Anderson (talk) 01:47, 25 November 2019 (UTC) --Villy Fink Isaksen (talk) 21:14, 17 March 2020 (UTC) focus on danish paintings. TemboUngwe (talk) 15:27, 13 July 2020 (UTC) Joan E Beaudoin (talk) 16:36, 31 July 2020 (UTC) Frolicking in metadata about art = heaven on Earth! Currently working on the Uffizi artworks ID file in the Mix'n'Match tool. Subodh (talk) 10:26, 6 October 2020 (UTC) Marajozkee (talk) 12:16, 11 October 2020 (UTC) Bhuvana Meenakshi (talk) 11:06, 13 October 2020 (UTC) Ham II (talk) 06:03, 17 October 2020 (UTC) Unapeça (talk) 10:47, 15 January 2021 (UTC) Focus on catalan paintings Edelseider (talk) 12:55, 17 January 2021 (UTC) Wuselig (talk) 10:39, 19 January 2021 (UTC) active in German GLAM-activities  Notified participants of WikiProject sum of all paintings

  Question Why not instance of (P31)? NMaia (talk) 09:49, 24 August 2020 (UTC)

  Question Is there any relation to P7937 - format of creative work or is this something completely different? Moebeus (talk) 16:42, 24 August 2020 (UTC)

  Question aren't all of the samples above photographs? For this to work, it's probabaly better to call it "Wikimedia Commons basic type" with a clear set of values to use and explicit rules when they apply. @Adam Harangozó: --- Jura 21:51, 28 August 2020 (UTC)

e.g. if more than 80% of the image reproduces a painting, use painting (Q3305213); if a drawing, use drawing. If the main subject is a sculpture, statue or installation, use sculpture (Q860861). Otherwise, if it's a photograph, use photograph (Q125191). --- Jura 14:06, 29 August 2020 (UTC)
If the photo shows at 100% an artwork, it is still a photo. --XRay (talk) 19:53, 24 October 2020 (UTC)

  Comment @NMaia, Moebeus, Jura1: Sorry for my very slow reply.

  • instance of (P31) could work but I feel it's a bit conflicting with digital representation of (P6243) - so it an instance of a painting or a digital representation? I know this sounds nitpicking, I'm just trying to advocate for a unified way of handling this issue.
  • form of creative work (P7937) I feel is a bit confusing as I feel it rather refers to size or some specific type but not a medium as a whole. At the same time the many of the examples on the property page are genres (novel) so it doesn't seem to work consistently.
  • What is problematic with the "Wikimedia Commons basic type" is that I feel there is a difference between a photo depicting a sculpture - even if it's the main subject, that is a photo, not a sculpture, it's depicted only, and it could be a historical photo where it's "photoness" is important - and a drawing which might have been photographed or digitalised but the whole image represents that drawing, is a drawing. --Adam Harangozó (talk) 17:26, 15 September 2020 (UTC)
    • Isn't that the same problem as your proposal has? The main difference is that the label explicitly refers to Commons' view of that problem and provides clear guidance how to determine it. --- Jura 08:23, 22 September 2020 (UTC)
  • @Adam Harangozó: Term "medium" is already used for other things on Commons: Artwork template has a field medium and it might have values like "Oil on Paint". And we need to be clear that the file is likely a photograph or a scan of an object and that object is... Can we call it "digitized object is a" and allow values like: painting, music recording, movie, sculpture, book, page of a book, etc. ? --Jarekt (talk) 02:34, 28 September 2020 (UTC)
    • One thing that would be important to consider with naming this property is that it might be a very popular search keyword/option in future Commons (for example if I only want to search for drawings). Because of this I think it should have a name which is friendly to those not using Wikidata, and "digitised object" is a bit too "tech". I would wait for more opinions but maybe something like the mentioned Commons basic type or Commons artwork type could work. Commons artwork medium? Adam Harangozó (talk) 22:57, 20 October 2020 (UTC)
  • IMO a photograph of a sculpture or something similar is still a photograph. We should not reduce a photograph to a digitised Object. This would demean the work of the photographer. The sculpture is part of depicts (P180), not more. --XRay (talk) 19:32, 24 October 2020 (UTC)
  •   Support, an important property for images.--Arbnos (talk) 16:38, 19 February 2021 (UTC)
  •   Oppose no, this is not the solution how to deal with multiple works. Multichill (talk) 19:07, 3 March 2021 (UTC)

Commons infobox based onEdit

   Under discussion
DescriptionID of an object, which was depicted or digitized to create this file and which will be used to create infobox (like Book or Artwork template) describing it
Data typeItem
Template parameterwikidata parameter in c:template:Artwork, c:template:Book, c:template:Photograph, c:template:Art photo,
Domainobject (Q488383): mostly object (Q488383), but also some abstract object (Q7184903)
Allowed valuesspecific artworks, artifacts and other museum holdings, as well as movies, or music compositions
Example 1Structured Data for  The Starry Night (Q45585) (for artworks opposite of image (P18))
Example 2Structured Data for  Mona Lisa (Q12418) (opposite of image with frame (P7420))
Example 3Structured Data for  David (Q179900)
Example 4Structured Data for File:Julien Bryan - Siege.ogvSiege (Q1351398) (opposite of video (P10))
Example 5Structured Data for File:"The Star-Spangled Banner" performed at the White House in 1994.ogaThe Star-Spangled Banner (Q44696) (opposite of audio (P51))
Example 6Structured Data for  Mona Lisa (Q12418) (opposite of 3D model (P4896))
Example 7Structured Data for File:EiffelTower fixed.stlEiffel Tower (Q243) (opposite of 3D model (P4896))
Example 8Structured Data for  March Constitution of Poland (Q2535435) (opposite of document file on Wikimedia Commons (P996))
Example 9Structured Data for  Nałęcz coat-of-arms (Q1785126) (opposite of coat of arms image (P94))
Planned useThis SDC property will be used by file infoboxes on Commons to indicate which item should be used as basis for the infobox. It will have single-value constraint (Q19474404)
Robot and gadget jobsUser:JarektBot or others will populate this property based on current digital representation of (P6243): copying the values for 2D artworks and moving them for other objects.
See alsodigital representation of (P6243), based on (P144), image (P18), main subject (P921)

MotivationEdit

Property digital representation of (P6243) was originally proposed to be used with c:template:Artwork and be equivalent to {{Artwork|wikidata=...}}. It is being used that way right now by couple hundred thousand files and several templates. However other users had plans to use this property for 2D artworks only to indicate that the file is a faithful reproductions of two-dimensional works of art that meets requirements of c:template:PD-Art or to tag files where wikidata relative position within image (P2677) properties are valid. As a result Wikidata:Property proposal/Digital representation of proposal when finally approved was ambiguous about its purpose. Ever since, most of the discussions at Property_talk:P6243 revolve around multiple visions different users have for this property. Based on Property_talk:P6243#2D_vs._3D discussion it seems like the best solution is to split digital representation of (P6243) into at least 2 properties: one to be used by Commons infobox templates and one for digitizations of 2D artworks. --Jarekt (talk) 04:36, 28 September 2020 (UTC)

How is it different from other properties:

In general, getting a new single-purpose property with name linking it to its purpose is important, since adding this property would affect the displayed metadata, and should be independent of any other task.--Jarekt (talk) 12:53, 28 September 2020 (UTC)

DiscussionEdit

Mike, Can you provide details on your proposal? How would it work? Depict statements seem particularly badly suited for this task:
If depicts (P180) is used correctly (i.e., for the specific things depicted, not random things), then it works well. E.g., see commons:File:Jodrell Bank Mark II 5.jpg, which uses commons:Template:Structured Data to pull out information about multiple telescopes in the image. The same should work fine in the cases here. Thanks. Mike Peel (talk) 18:28, 5 October 2020 (UTC)
However depicts (P180) is usually not used correctly and yes you can handcraft an image where it works but for great many images it does not. c:template:Artwork uses depicts (P180) to find and list depicted people. That code was crashing on some pages due too many depict statements and taking too long. I had to limit it to only first 50 depicts for which I was looking up instance of (P31). That is why "Infobox based on" only allows a single value. The purpose of depict is to list depicted people, places, objects, etc. and purpose of "Infobox based on" is to choose a single item to base the infobox on. Those 2 purposes are very different. We already tried to use a single property for 3 different tasks: digital representation of (P6243) and as a result it does not work well for any of them. --Jarekt (talk) 00:56, 7 October 2020 (UTC)
  •   Comment unless we have samples of uses elsewhere, could you add "Commons" to the property label? --- Jura 07:12, 7 October 2020 (UTC)
Sure --Jarekt (talk) 02:09, 1 November 2020 (UTC)
  •   Support Christian Ferrer (talk) 22:18, 20 February 2021 (UTC)
  •   Support I'm not fully convinced about not using main subject (P921), but right now we're in a deadlock and I want to get digital representation of (P6243) cleaned up so we can go to the next step with that property. Let's create this new property. Clean up digital representation of (P6243) and maybe later decide to merge the new property into main subject (P921) (or not). That way we can do incremental improvements. Multichill (talk) 12:18, 7 March 2021 (UTC)
  • Weak   Support. I'm not a big fan of creating and using properties that are solely designed for the purpose of displaying (or not displaying) certain data on our wikis. (Said differently: I think our properties should be Wikimedia-independent and purely semantic, and the way we display content on our wikis should smartly work with those semantics.) I also think it would be most future-proof if we would rethink the way we do infoboxes for files on Commons, not try to stuff structured data in the old flawed ways we used to do things with the limits of Wikitext. That said, the way we've ended up misusing digital representation of (P6243) for photos of three-dimensional works is also not great at all. So I'm with Multichill on being pragmatic and using this property temporarily as hopefully a step forward towards hopefully a more and more correct and clear way of displaying semantically correct data about creative works, files showing these creative works, and the creators of the works and the files. Spinster 💬 12:37, 7 March 2021 (UTC)
  •   Question At Property talk:P6243, User:Jarekt has floated the idea of using depicts (P180) or main subject (P921) with a qualifier object has role (P3831) = "appropriate subject for infobox" (or similar), that the template could pick up. Is that a model that could work? Would it cover all the use-cases? Jheald (talk) 10:47, 12 April 2021 (UTC)
It would not work well with depicts (P180) as you might have large number of those and it might be a mess to find the depict with the qualifier. main subject (P921) might work because there should be only one of those. Tools like c:User:Magnus Manske/sdc tool.js which I currently use to add digital representation of (P6243) to files, do not support qualifiers. Is main subject (P921) appropriate for files which show image details or for PDF files which we would link to items? --Jarekt (talk) 01:28, 20 April 2021 (UTC)

inscription imageEdit

   Under discussion
Descriptionimage of an inscription on the subject
Representsinscription (Q1640824)
Data typeCommons media file
DomainItem
Allowed values(?i).+\.(jpg|jpeg|jpe|png|svg|tif|tiff|gif|xcf|pdf|djvu|webp)
Example 1war memorial Vösendorf (Q96319335)File:War memorial for World War I in Vösendorf, Lower Austria, Austria-name plate PNr°0739.jpg
Example 2Biedermann-Huth-Raschke-barracks (Q55185320)File:Biedermann-Huth-Raschke barracks in Vienna, Austria-inscription PNr°0751.jpg
Example 3war grave Vösendorf (Q90730716)File:War grave for World war II on the cemetery Vösendorf, Lower Austria, Austria-inscription PNr°0657.jpg
Example 4war grave Mauer (Q89814150)File:2016-01-16 GuentherZ (19) Wien23 Friedhof Mauer Sachsengrab.JPG, File:2016-01-16 GuentherZ (20) Wien23 Friedhof Mauer Sachsengrab.JPG, File:2016-01-16 GuentherZ (21) Wien23 Friedhof Mauer Sachsengrab.JPG, File:2016-01-16 GuentherZ (24) Wien23 Friedhof Mauer Sachsengrab.JPG (=> multiple entries can be used if necessary)
Example 5wayside cross Perchtoldsdorfer Heide (Q89024686)File:Wayside cross on the Perchtoldsdorfer Heide near Perchtoldsdorf, Lower Austria, Austria-inscription PNr°0606.jpg
Example 6Schönkirchner Tor (Q91347430)File:Schönkirchner Tor north east of Gänserndorf, Lower Austria, Austria-inscription PNr°0681.jpg
Example 7wayside shrine (Eisenstadt, Gölbeszeile) (Q88759838)File:Wayside shrine in Eisenstadt, Burgenland, Austria-inscription PNr°0594.jpg
Example 8Franz Heindl and Viktor Mrnustik memorial (Q87779813)File:2016-01-09 (05) GuentherZ Wien23 Siebenhirtenstrasse16 Widerstandsdenkmal fuer Heindl und Mrnustik.JPG
Example 9Wilhelm Kress monument (Q38006937)File:Wilhelm Kress monument-part3 PNr°0395.jpg, File:Wilhelm Kress monument-part4 PNr°0396.jpg, File:Wilhelm Kress monument-part5 PNr°0397.jpg
Planned useon items that have available images of their inscriptions
Expected completenesseventually complete (Q21873974)
Formatter URLhttps://commons.wikimedia.org/wiki/File:$1
Robot and gadget jobsmaybe (convert P18+img with P180+Q1640824 to using property)
See also

MotivationEdit

An earlier property proposal was shut down because we can use existing properties with qualifiers. Well OK. There is already a property for images so I used image (P18)+img with depicts (P180)+inscription (Q1640824). Then somebody said image (P18) is only meant to be used with a single image and removed the inscription image.
Well, what now? I really don't care about how it is included. Since there is an ass full of other image properties we might as well create one for inscriptions as well.
As explained on Property_talk:P18#How_many_images? I think images can be added to P18 as long as:

I really don't care if this proposal turns into a property or not. I want to use Wikidata and not fizzle around with details like wether an image is added in property A or B. So I see two possible results:

  • proposal is approved > images will be added using the new property
  • proposal is declined > images will be added using P18+img with P180+Q1640824

--D-Kuru (talk) 11:54, 14 November 2020 (UTC)

Note that all listed examples were taken from items I worked on. The potential use is for all pages on Special:WhatLinksHere/Property:P1684. --D-Kuru (talk) 13:58, 14 November 2020 (UTC)

DiscussionEdit

Yeah, probably. I updated the list with a few more examples --D-Kuru (talk) 13:58, 14 November 2020 (UTC)
  •   Neutral In general, I'm not neutral as a maintainer and someone who does a lot of identification and categorization work on commons, which touches also wikidata. Multiple uses of multiple images increases maintenance work and danger of inconsistencies. We have:
  1. Wikipedia articles overloaded with images
  2. Commons categories (often violating Commons:COM:OVERCAT)
  3. Commons galleries (created, but rarely maintained)
  4. Influencing the sorting order in categories by using a sortkey at the beginning of the collation sequence or quite naturally and clever, using filenames with iso-dates at the beginning (e.g. a File '20200101_xxx', which will stay at the first page of a category till we reach the year 10000, or get images from the last century).
  5. Files (miss)using in the Information template, parameter 'other_versions', a gallery of images of the same event, photo excursion etc. (but not another version of the same image (rotated, cropped, deframed, b&w, etc.). Interestingly enough, I've seen a lot of such galleries in individual files, but always without photos from other photographers.
  6. and there is a lot of various image types for WD-items besides image (P18)
  7. and there is this multiple use of image (P18). Some WD-items have been filled by bots adding all images from a wikipedia article to image (P18) without selection.
  8. and, if there is no place to add the image, WD-items for that image are created on purpose, not creating a full description, but only what is rudimentary necessary.
Photographers want to promote their photos in as many places as possible, this increases the chance that someone else will find it and reuse it. QI is just another way to promote images. Promotion of images is quite often combined with weird / explicit / TLDR non-standard licences. The whole image part of the wikiverse is more about promotion than about contribution.
The purpose of the first image in image (P18) is to show it in many places (infoboxes, small languages) automatically. What is the purpose of the second, third, etc. image for the wikiverse? For external users of WD? What is the purpose of having a dedicated image for inscriptions in the very example ([2]), if this is not done in the same way (=enforced by rules and recommendations) for all (most) war memorials we have images of plaques of the fallen soldiers. Again, one image for a such a plaque is not enough, most war memorials I remember have more than one such plaque. --Herzi Pinki (talk) 15:24, 14 November 2020 (UTC)
@ 1) Not related to Wikidata and P18. If a certain Wikipedia feels overloaded, they reduce images.
@ 2) Not related to Wikidata and P18. The people who categorise their images/resort categories are the ones who have to care about this.
@ 3) Not related to Wikidata and P18. The users who create the galleries have to care about this. In my opinion galleries have shown to be quite useless as they are right now.
@ 4) Not related to Wikidata and P18. The users who upload images are responsible for the names. If you want to change it, you have to force a general name scheme onto Commons.
@ 5) Not related to Wikidata and P18. The users who add images to this section are responsible this.
@ 6) I don't see your point here. Either there is a special property for specific usecase or there is not.
@ 7) So the problem is the bots doing nonesense and not the property beeing bad. As said above a second image for P18 should "be described with a Qualifier and an Item". If bots add a multiple images to one item, they are just poorly written.
@ 8) Created by bots or by humans? Bots: Per 7). Humans: Either the item is legit and can stay or it is not and can be deleted.
Taking good images and trying to get the best out of them takes a lot of time. So I see it as natural that photographers usually take images to use or show them. Some push their images more than others. To me QI is not really about promotion, but about having some kind of approval for all the time and effort you put into images. Literally noone cares about you, your work, your time, your effort or the money you spend on your equipment, personal education or that image in particular. In the end people end up not even caring about the licence at all and use them as they like. So the little QI stamp is one of the few approval stamps we have on the Wikimedia system. The altruistic people who did not force their will (or images) onto others got chased away by smartpants who do exactly that. But again this is not something that is the point of the discussion of this property.
What is the use of all the other other image properties on Wikidata:List of properties/Wikidata property linking to a representative image if one image is enough for the entire item? If there are not qualifiers that tell in a standard way what the images seperate, then yes, they are probably not needed most of the time. Just because it's not done right now does not mean it can not/should not be done in the future. A dedicated property would certainly help here.
In general WP overloads you with help pages and things you should do. WD has some pages, but you have to know them. I have never seen a (semi) official list that shows what should be included for an item about X (so a new item about eg. a person, an artist album, a building, plants, etc.). So WD is incredibly bad about guiding people around what things are done. And then we discuss at the wrong end of the stick about if property X should be handled in way A or B
--D-Kuru (talk) 14:03, 15 November 2020 (UTC)
  •   Support Seems generally useful for monuments and buildings. Avoids overloading P18. In some cases may help support a factual statement (e.g. building opened on date / (qualifier) stated in inscription; inscription <text>; inscription image <pic>). Pelagic (talk) 17:11, 15 December 2020 (UTC)
  •   Support, an important property for images.--Arbnos (talk) 16:54, 19 February 2021 (UTC)

WMF hosted image that could be added to CommonsEdit

   Under discussion
Descriptionurl of an image that could be added or moved to Wikimedia Commons from another WMF wiki
RepresentsProject:Moving files to Commons (Q104205600)
Data typeURL
Domainany
Allowed valuesURL to images at Wikipedia and other WMF wikis:
https://.+(mediawiki|wik(i(books|(m|p)edia|news|quote|source|versity|voyage)|tionary))\.org/wiki/File:.+
Example 1Jacob Bunn (Q104008565)https://en.wikipedia.org/wiki/File:JacobBunn.jpg
Example 22014 Mount Everest avalanche (Q16448748)https://en.wikipedia.org/wiki/File:Everest3d_qbd_2014116.jpg
Example 3MISSING
See also
  • Commons compatible image available at URL (P4765): image with Commons compatible copyright status is available at the following URL. It could be uploaded to Commons to illustrate the item
  • Wikimedia import URL (P4656): URL of source to indicate the page or revision of an import source from another Wikimedia project (except actual references, such as Wikisource source texts). Use instead of "reference URL" (P854). Permalinks are preferred.

MotivationEdit

Following the discussion at Wikidata:Property proposal/Commons compatible image available at URL (non-artwork) about the existing Commons compatible image available at URL (P4765), the above seems a more suitable set of images that could be handled with the same tools. (Add your motivation for this property here.) --- Jura 12:07, 14 December 2020 (UTC)

DiscussionEdit

alt textEdit

   Under discussion
Descriptionalternative text used when an image can't be rendered or when accessed from assistive technology such as a screen reader
Representsalt text (Q60844786)
Data typeMonolingual text
DomainCommons image
Example 1File:Ansel_Adams_and_camera.jpg » "Black and white photograph of a man with a tripod-camera and a pine tree in the background."
Example 2File:Apollo_11_Crew.jpg » "Three men in white spacesuits without helmets in front of an image of the moon."
Example 3File:Panthera_tigris_altaica_13_-_Buffalo_Zoo.jpg » "Tiger cub in from of a mature tiger in snow."
Planned useUsage in various tools as well as on Wikimedia Commons and Wikipedia.
See alsoformer proposal for Wikidata

MotivationEdit

This will allow editor to specify an alt-text(alternative text which describes the visual features of an image) for images on Wikimedia Commons which can then be reused by various projects and tools to set an alt-attribute. See the tickets below and the previous proposal.

See Phab:T166094 and Phab:T213585 Abbe98 (talk) 20:09, 20 February 2021 (UTC)

DiscussionEdit

  •   Support Good idea! Thanks for explaining the process. Jane023 (talk) 20:16, 20 February 2021 (UTC)
  •   Support --Lectrician1 (talk) 01:29, 21 February 2021 (UTC)
  •   Support   Don't ping me NMaia (talk) 10:36, 21 February 2021 (UTC)
  • Strongly oppose per discussion in the previous proposal, and Phab. tickets, since when nothing of significance has changed. As I said in the first Phab. ticket - and as I advised the proposer, in the second - "Please do not progress this proposal without first consulting with screen reader users and/or accessibility professionals." It appears this had not been done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:16, 21 February 2021 (UTC).
    Please provide some constructive feedback rather than repeating a statement that questions others expertise. I have worked professionally with web accessibility. Also note that this is not about implementation of alt-text but about a way to store generic alt-texts. Abbe98 (talk) 15:04, 2 March 2021 (UTC)
    Oh FFS. I have provided plenty of constructive feedback on past iterations of this benighted proposal. I am sick of people trying to wear down sensible and reasoned opposition including that by colleagues who are blind and use assistive technologies like this. I too have "worked professionally with web accessibility" - that doesn't make me an "accessibility professional" and nor does it make you one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:57, 2 March 2021 (UTC)
  •   Comment From the domain in the proposal, I note this is limited to Commons (not for use on Wikidata itself). So from Wikidata's POV, there isn't really any reason not to create this. It seems that Monolingual text properties are now possible on Commons [3], so technically, this could be implemented. Maybe the property description could recommend reading some help text that explains how to write alt texts. --- Jura 11:31, 21 February 2021 (UTC)
  •   Support This really is common sense but in any case I asked some people with relevant expertise to comment. (Andy you might want to explain or link to your objection to make it easier for them to assess it.) I'll also note that there are various places where we cannot add alt text currently (category pages, image description pages, generated reuse snippet etc) and this proposal would help with that; the benefits would not be limited to fallback alt text in articles. Also, having a large corpus of well-described images might have value of its own for developers of assistive technology. --Tgr (talk) 15:19, 21 February 2021 (UTC)
    • The links are in the proposal. this is now the fourth discussion in which I have had to state them, in this context. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:14, 21 February 2021 (UTC)
  •   Comment I imagine the eventual data type of this property would be multilingual text, but for the time being it should be created as monolingual, as done for other properties. --Tgr (talk) 15:26, 21 February 2021 (UTC)
    • Please keep in mind, that screenreaders would read out monolingual content not marked via appropriate `lang` attribute in the respective language wiki wrongly. --Volker E. (WMF) (talk) 21:38, 22 February 2021 (UTC)
  • "planned use = Usage in various tools as well as on Wikimedia Commons and Wikipedia." (my emphasis) Wikipedia is an encyclopedia and only includes an image for the information that the image provides to the reader that is relevant to the article . It's not there to make the page look pretty. On Wikipedia, images are almost invariably accompanied by a caption that supplies additional information not apparent from the image. It is the combination of alt text and caption that makes up the alternative text for the image. That means that the alt text is context dependant and cannot be prescribed from a central location. If you place File:Washington and Lafayette at Valley Forge.jpg in an article about en:Valley Forge, it doesn't matter that there are two officers with red capes and five soldiers, but it's important to say that it's winter. If you put it into an article about en:George Washington, it doesn't matter what colour the horses are, but it probably does if it's in the article about en:Nelson (horse) (he's the one on the left). If you want to annoy screen reader users, put File:Ansel Adams and camera.jpg into the en:Ansel Adams article with the alt text suggested as an example. Try explaining to them what relevance "a pine tree in the background" has to his article. Was he notable for standing in front of pine trees? By the way, the suggestion here would still be an improvement over the abomination actually used in his article ("the open shirt collar is spread over the lapel of his jacket" - suitable for a fashion magazine, not for an encyclopedia). --RexxS (talk) 02:05, 23 February 2021 (UTC)
This is all very true and I believe it important to note that this proposal is only a proposal to have a way of storing generic alt-texts. Wikipedia might choose to somehow use this and it might also choose not to. In my opinion Wikipedia editors and should always be in control of the alt-texts in articles. Abbe98 (talk) 15:00, 2 March 2021 (UTC)
  • Oppose as a screen reader user – nothing's changed since last time. Graham87 (talk) 06:16, 23 February 2021 (UTC)
  •   Oppose on philosophic grounds, and per views of previous opposers. I don't like Wikidata increasingly building itself as "the one true God" of all that is Wikimedia. Context matters in alt text as well as captions (as described at en:Wikipedia:Manual of Style/Accessibility/Alternative text for images). What happens on Wikidata (or Commons) need not necessarily be reflected in every source that uses Wikidata data (or Commons media). Poorly curated infoboxes will accept whatever is pumped into them from Wikidata, regardless of relevance. The existing media legend (P2096) for example often results in a redundant, unhelpful and/or arbitrary foreign language caption in Wikidata Infobox (at least when implemented on Commons), unless one adds an arbitrary legend in their preferred language. No matter how well the intentions are, the more centralized and prescribed data presentation becomes, the harder it becomes to maintain local control on individual articles, infoboxes, and whatever third-party sources draw from Wikidata. Someone will probably eventually make a bot that registers all incongruences between local and Wikidata values as "errors", giving some other bot operators incentive to wrongly "fix" them. -Animalparty (talk) 01:41, 24 February 2021 (UTC)
    • Too bad you didn't bother reading the proposal .. contrary to previous ones, it's not for Wikidata, but Commons. --- Jura 10:38, 24 February 2021 (UTC)
      • Why then is it being proposed and discussed on Wikidata instead of Commons? -Animalparty (talk) 16:53, 24 February 2021 (UTC)
        • Because Commons has no property namespace. --- Jura 17:01, 24 February 2021 (UTC)
  •   Support Very good! This will facilitate translations, make pictures better searchable and provide material for the developers of image description AI. Most of all it will make it more effective to provide images with alt texts. Regarding the context issue: In my opinion, the image related text form that should deliver the context is the CAPTION. Context is necessary for ALL users. So it should be readable for everybody, but alt text is only readable for screenreaders or when image display is disabled by the browser. Alt text should only replace the VISUAL CONTENT of the image. It should tell those who cannot see the image what people who can SEE. In Wikipedia every image has FIVE image related text forms: Name, caption, alt text, image description, article. The caption changes from article to article so it should give the context. The longer image description does not change but since its longer it can be sensitive to different possible contexts. The alt text should change as little as the image's file name. It's not necessary and would be even redundant if the alt text would repeat the caption. KH32 (talk)16:39, 25 February 2021 (UTC)
    • @KH32: A user who is blind and who uses assistive technology and relies on alt text attributes commented against the previous proposal, explicitly on the basis of context; and reiterates their opposition here. Can you explain the basis on which you have a better understanding of this matter than they do? And can you explain how this will make images "better searchable" than the proper use of "depicts" statements will? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:57, 2 March 2021 (UTC)
    • @Pigsonthewing:I am speaking for the group of blind and sighted people of our Photo Studio for Blind Photographers in Berlin. We are working with picture descriptions since 2011. But that doesn't mean that we have automatically the better understanding in this particular question. The reasons why we disagree in the question of context in alt texts are just as I tried to state them briefly. Regarding your second question what do you mean by "depicts" statement? KH32 (talk)18:59, 02 March 2021 (UTC)
    • @Pigsonthewing: Ah that alt texts = alt tags make pictures better searchable is because "Google uses alt text along with computer vision algorithms and the contents of the page to understand the subject matter of the image."(Google) KH32 (talk)19:17, 02 March 2021 (UTC)
  •   Oppose if this should be implemented, it shouldn't be implemented as a property, but using the empty "descriptions" array, see phab:T166094.  – The preceding unsigned comment was added by Multichill (talk • contribs) at 18:56, 3 March 2021 (UTC) (UTC).
    • @Multichill: care to argue (here or on the task) why? --Tgr (talk) 10:35, 5 March 2021 (UTC)
  •   Support to provide a default, and as alt-text for the Commons information page; and for when the image appears without context, for example on a wikidata page. Where the image appears elsewhere, make sure there is provision to override the alt-text locally. Jheald (talk) 22:51, 3 March 2021 (UTC)
  •   Comment On the Phabricator task, User:FRomeo (WMF) says: We're thinking of organizing a workshop on this topic, with accessibility consultants, people with lived experience, the WikiBlind user group, and anyone else who is interested. - which sounds to me like the best way forward for this proposal. --Tgr (talk) 10:35, 5 March 2021 (UTC)

named place on mapEdit

MotivationEdit

 
1576 Saxton map of Essex. It names a large number of places.

In March 2021 WikiProject EMEW's partners, the Viae Regiae (Q105547906) project, will start a major drive to transcribe and identify all the places and placenames on several series of 16th and 17th century maps, like the 1576 Saxton map of Essex to the right. (They will actually be using a higher-resolution copy, which we will be uploading).

As can be seen from the map, the number of places on it is very large; the process may generate of the order of 1000 located places per map, which we will be recording as Structured Data statements on Commons.

It would be good to have a property other than depicts (P180) to record this information. In the map to the right, the appropriate value of depicts (P180) = Essex (Q23240). The settlements of West Ham, Leyton, and Wanstead only appear as 3 small places out of a thousand, close to the border with Middlesex. For user convenience, efficiency of querying, and clarity, it is useful not to overload the main depicts (P180) statement with this information, and still less use main subject (P921) but to keep it segregated and record it separately with a different property -- the relationships are of a different nature. We shall also be exploring whether it is possible to emit the information again in a IIIF manifest, a test of the ability of Structured Data on Commons to support annotation at scale.

The statements will be accompanied by the qualifiers stated as (P1932), to record the name as given on the map, and relative position within image (P2677) to record where on the map the image locates the place.

A question still to be evaluated is whether SDC and the SDC user interface will be able to cope well with such a large number of statements, all of the same kind. The technical view on the phabricator ticket raised by the WikiProject on this point (phab:T275286) seems to be "try it and see". But it may be that when there are a very large number of statements of a particular kind, it would be advantageous to put them in a collapse-box. This would be another reason to keep the principal depicts (P180) statements separate from the statements for named places, so they would remain visible.

However the main purpose of this property proposal is simply to have a property other than depicts (P180) to start trying to record this information.

DiscussionEdit

  • Proposed. Jheald (talk) 22:27, 1 March 2021 (UTC)
  •   Support I support using a property separate to depicts for this, as a mark on a map seems to me a very different thing to what would normally be implied by a depicts statement. The benefit of this proposal would cut both ways, so it would keep these map markings out of the way of the main depicts statements, but also make it easy for people who want to find all the maps with a particular place on. DrThneed (talk) 22:45, 1 March 2021 (UTC)
  •   Don't ping me   Support NMaia (talk) 03:13, 2 March 2021 (UTC)
  •   Support - PKM (talk) 04:23, 2 March 2021 (UTC)
Wikimaps facebook group notified of property proposal: link
  •   Comment Interesting use of Wikidata. Personally, I'd try to do it on Wikidata (not SDC), but even here the number of statements might eventually become problematic through the GUI.
    What happens when the place name cane be deciphered, but not matched (exactly or at all) to an item? Should the value be the name and the qualifier the mapping to a Wikidata about the place? --- Jura 16:42, 2 March 2021 (UTC)
Another alternative could be to record it directly as a Lexeme form. This has the advantage that place can be determined in a clearly separate step. --- Jura 16:52, 2 March 2021 (UTC)
@Jura1: Useful Qs. If the place cannot be identified, or has no wikidata item, we can use ?map "named place on map" <somevalue> / "stated as" ?name_on_map in the usual way.
Putting the identified place on the main statement, rather than on a qualifier, seemed the right way to go, to make it a couple of lines easier to write queries like "which of these maps include this place" (even though they may name it differently -- spelling was very variable in this period).
The reason to go for Commons and SDC, in the first instance, was to be able to hang the position qualifier off the statement, which may be specific to a particular digitisation of the map. But you'll notice that the property proposal specifies for use on files or items, and we're thinking about how high up the individual copy -> edition -> work hierarchy it might be useful also to record this information. Jheald (talk) 18:53, 2 March 2021 (UTC)
@Jura1: re-pinging, because I think I didn't get it right before (forgot the '1' on your username). Jheald (talk) 21:47, 2 March 2021 (UTC)
  • Instead of "try it and see" with SDC, you could just check any image with a large number of statements and see how it loads (or doesn't). I vaguely recall that already 20 was slow. In either place, you probably need to edit it with some other tool.
About the comparison qualifier vs. main statement: a point to consider is also that place names that can refer to several places (maybe less a problem for maps than place names in works in general).
@Susannaanas: might be interested. --- Jura 13:52, 5 March 2021 (UTC)
@Jura1: On the ticket (phab:T275286) Lucas looks at c:File:Nature Timespiral.png, which currently has the largest number of SDC statements of any file on Commons, and finds it all seems to work. Jheald (talk) 16:22, 5 March 2021 (UTC)
Good for him. Might just be my browser. --- Jura 17:24, 5 March 2021 (UTC)
  •   Comment Sorry for taking the time to follow up. I think this is an interesting approach. I wonder if there are properties for annotations that could be put together with this, or whether it is a good idea to keep the place candidates separated from the start. I am not well enough up-to-date on annotation-related properties, but I am sure if you and the team have thought about this and ended up in this solution, it should be good enough. Could you sketch out a sample annotation with stated as (P1932) and relative position within image (P2677)? I also think that maps could be stored in Wikidata, and the annotations would refer to a map original rather than an image copy. But it seems you have both options. – Susanna Ånäs (Susannaanas) (talk) 14:20, 5 March 2021 (UTC)
  • I am confused however, that they should be recorded as items. In that case I would also suggest using lexemes instead. – Susanna Ånäs (Susannaanas) (talk) 14:27, 5 March 2021 (UTC)
@Jura1, Susannaanas: so a couple of examples for this map, with qualifiers:
File:Essexiae... "named place on map" West Ham (Q939617) / relative position within image (P2677) = "pct:15.2,85.0,0.5,1.0" / stated as (P1932) = "W Ham"
File:Essexiae... "named place on map" Barking (Q377720) / relative position within image (P2677) = "pct:20.5,84.7,1.4,1.3" / stated as (P1932) = "BARKINGE"
For me the lexeme idea doesn't work at all. The names on the map are strings, not forms of dictionary words. Creating Lexeme items for these particular spellings would have no particular value. It is useful to be able to retrieve the strings as strings in a query, and that can be done.
Secondly, use of {{P|2677}. For this image P2677 makes sense, as places are recorded using glyphs of different sizes. (See here for the project's current rough typology, which is likely to evolve.) Specifying the bounding box allows a crop just of the glyph to be retrieved easily. If the information were available, one might additionally specify region within image (P8276) to specify a polygon around the glyph. That information is not currently planned to be retrieved, but might be extracted at a future stage by machine learning methods.
For other maps it might make sense to record the position of just a point on the map rather than a box or a polygon. Unfortunately there appears to be no property to do that at present.
The design is essentially identical to how annotations are expected to be stored on Commons. (At least it seems so, depending whether anybody has done thought on this). cf eg the use of relative position within image (P2677) on File:ISSSpaceFoodOnATray.jpg
As to why target the files on Commons first, (i) if it breaks things, we don't want to break wikidata. Breaking presentation of Commons SDC is expendable, because nobody uses it for anything. Breaking wikidata is not; and (ii) as already stated, the glyphs are small objects. If the image (P18) value is changed to a new improved different digitisation, that is cropped even slightly differently, none of the boxes will fit found the glyphs any more. Therefore it makes more sense, at least to start with, to put the information on the SDC of the image. But we are thinking about what also to store on wikidata -- User:PKM in particular, who is developing the data model for the wikidata items for the maps (see Wikidata:WP EMEW/Sources).
Hope this helps to clarift our thinking a little bit. Jheald (talk) 16:16, 5 March 2021 (UTC)
  Support I think I must have misunderstood a little, and this looks much more straightforward than what I first thought. So the values are geographic places, not place names or candidates for places or place names. I can see value in it being a separate property. – Susanna Ånäs (Susannaanas) (talk) 16:55, 5 March 2021 (UTC)
  •   Support, an important property for maps.--Arbnos (talk) 21:11, 27 April 2021 (UTC)