Wikidata:Property proposal/position

position within image edit

Originally proposed at Wikidata:Property proposal/Commons

Not done

Description	Position of a person or an object on a photo where there are multiple persons or objects
Data type	Item
Domain	qualifier
Allowed values	positions: e.g. left, right, top, bottom, top left: down (Q15332388), lower part (Q17525439), bottom (Q16421635), up (Q15332375), upper part (Q17525438), center (Q23595), left (Q13196750), left part (Q17525441), right (Q14565199), right part (Q17525442), upper left part (Q27956549), upper right part (Q27956533), lower left part (Q27956553), and lower right part (Q27956561)
Example 1	File:Myrthe Morrees, Lynn Wilms en Joelle Smits - 1578063654.JPG depicts (P180) Myrthe Moorrees (Q2145911) -> left (Q13196750)
Example 2	File:Myrthe Morrees, Lynn Wilms en Joelle Smits - 1578063654.JPG depicts (P180) Lynn Wilms (Q56676525) -> middle
Example 3	File:Myrthe Morrees, Lynn Wilms en Joelle Smits - 1578063654.JPG depicts (P180) Joëlle Smits (Q56676398) -> right (Q14565199)
Example 4	Lynn Wilms (Q56676525) image (P18) File:Myrthe Morrees, Lynn Wilms en Joelle Smits - 1578063654.JPG -> middle
Format and edit filter validation	only as a qualifier
Planned use	Usage as qualifier for SDOC
See also	identified in image by (P7380): qualifier for the identification of a value/object with a number, letter or sign inscribed in the image applies to part (P518): part, aspect, or form of the item to which the claim applies relative position within image (P2677): position of a motif within a larger image, defined by x-offset (from left), y-offset (down from top), width w, and height h of the crop region (as a percentage of the whole image) values region within image (P8276): qualifier to identify a polygon within an image that the main statement applies to

Motivatie edit

There is currently no good way to describe which person is where on a photo with multiple persons. Eg. File:Myrthe Morrees, Lynn Wilms en Joelle Smits - 1578063654.JPG, how to say in Structured data that Myrthe is on the left, Lynn in the middle and Joëlle on the right? series ordinal (P1545) isn't suited, because why should we start counting on the left? Mbch331 (talk) 19:04, 7 January 2020 (UTC)[reply]

Discussion edit

Comment - We already have shown with features (P1354) and depicted part (P5961). Both are not completely identical to what you're proposing, but could be used as such. Also, for identifying on a more specific basis relative position within image (P2677) is also available. Husky (talk) 20:30, 8 January 2020 (UTC)[reply]
Comment I am not sure weather this is a clear way to do so as many images depicts 3D space. If you say something is on the right, one may ask on the right from where? --Juandev (talk) 15:30, 9 February 2020 (UTC)[reply]
Support, an important property for photography.--Arbnos (talk) 18:17, 21 February 2020 (UTC)[reply]
Oppose I agree that it is an important property, but we already have relative position within image (P2677) for that. See File:A._Nevsky_Cathedral_in_Warsaw_(Aerial).jpg and for how to use it on SDC or see examples on Wikidata. --Jarekt (talk) 02:21, 15 May 2020 (UTC)[reply]
Oppose per Jarek. Multichill (talk) 19:34, 3 June 2020 (UTC)[reply]
Comment I think a qualifier like this is needed to simply add "left" or "right" or "middle" in the sample given, similar to identified in image by (P7380). relative position within image (P2677) requires to decode and can't be converted to a mere text legend. "applies to part" seems suboptimal (I added all three as "see also" above). The label should probably be more specific. --- Jura 13:38, 4 June 2020 (UTC)[reply]
@Mbch331, Husky, Arbnos, Juandev: how about "position within image" ? --- Jura 12:13, 5 June 2020 (UTC)[reply]
- That is fine by me. Must say that the tool Jarekt mentioned works fine too. Mbch331 (talk) 12:26, 5 June 2020 (UTC)[reply]
- @Mbch331: I think the tool has its uses (and advantages), but for the infobox at Lynn_Wilms, it's not ideal. --- Jura 12:31, 5 June 2020 (UTC)[reply]
Comment This property is of item data type, so it would be storing items like down (Q15332388), lower part (Q17525439), bottom (Q16421635), up (Q15332375), upper part (Q17525438), center (Q23595), left (Q13196750), left part (Q17525441), right (Q14565199), right part (Q17525442), upper left part (Q27956549), upper right part (Q27956533), lower left part (Q27956553), and lower right part (Q27956561). It could replace applies to part (P518) qualifier already used in thousands of inscription (P1684) statements, but you can not express "third from the left in the second row" with it. Property relative position within image (P2677) stores precise coordinates of the bounding box and might be more useful in more complicated image. Name of applies to part (P518) is not very intuitive for this purpose, but "Position" seems too generic. "Position within image" seems fine but it is very similar to relative position within image (P2677). --Jarekt (talk) 23:19, 5 June 2020 (UTC)[reply]
- While "inscription" can work with "applies to part", the same doesn't seem suitable for "depicts". Personally, I wouldn't mind "relative position within image (item)" as label.
  I still think P2677 would be too complicated for the infobox at Lynn_Wilms, while it works fine for complex cases like File:A._Nevsky_Cathedral_in_Warsaw_(Aerial).jpg mentioned above. --- Jura 09:09, 6 June 2020 (UTC)[reply]
@Mbch331, Husky, Arbnos, Juandev, Jarekt: In the meantime, there is also region within image (P8276) for even more complex identification. I updated the label as suggested. --- Jura 05:32, 8 June 2020 (UTC)[reply]
Support per above. Added a WD sample as well. --- Jura 10:21, 8 June 2020 (UTC)[reply]
Oppose This doesn't make sense to me for reasons already been covered by some others here. To summarise though: it's too ambiguous and superseded by precise position coordinates other properties provide. --SilentSpike (talk) 10:48, 20 June 2020 (UTC)[reply]
- @SilentSpike: I think we addressed the amibiguity by changing the proposed label. In what aspect do you think this still needs improvement? I don't really see an advantage of using region within image (P8276) if one could just add "left". --- Jura 10:58, 20 June 2020 (UTC)[reply]
  - @Jura1: I think "left" is meaningless without a point of reference. Left of the image centroid? Does that mean the subject occupies the whole left or is just somewhere in the left region? Why not just give the precise information? --SilentSpike (talk) 11:09, 20 June 2020 (UTC)[reply]
    - @SilentSpike: looking at the first sample above, how would you describe the position of the person using words? --- Jura 11:11, 20 June 2020 (UTC)[reply]
      - @Jura1: In words, they're on the left of the image. However, there's an implicit point of reference in that statement (the centroid). Wikidata doesn't deal in spoken language and this doesn't scale well to complex images. Why not specify exactly where they are in the image? --SilentSpike (talk) 11:27, 20 June 2020 (UTC)[reply]
      - For example, where would you specify that Marianne (Q325956) is in File:Eugène_Delacroix_-_La_liberté_guidant_le_peuple.jpg using this property? --SilentSpike (talk) 11:30, 20 June 2020 (UTC)[reply]
        I wouldn't use the property proposed here for that image. Is there anything that needs to be added to the label or description to ensure that "left" would be an appropriate way to describe the use in sample #1? --- Jura 11:33, 20 June 2020 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

Perhaps the label "descriptive position within image", to indicate that the property doesn't intend to actually give the subject's location, but just a vague description. My understanding is that this proposal is purely intended for human readable description and is applicable only to limited images with distinct and few subjects. The specific position coordinates can already be compared to generate such descriptions. --SilentSpike (talk) 11:52, 20 June 2020 (UTC)[reply]
- Well, Wikipedia infoboxes generally have such descriptions, so the number isn't that limited. Oddly, the feature you describe doesn't seem to exist or be used there. Can we see it somewhere in action or is it just an abstract possibility, unlikely to be implemented? --- Jura 12:08, 20 June 2020 (UTC)[reply]
  - By limited I just meant a limited subset comparatively to the set of all images, a good example of why implicit points of reference are easy to misinterpret (especially for a machine). As for how that would be implemented, I'm not experienced with editing wikipedia, but my understanding is that they can access Wikidata via a Lua Scribunto interface. Looking at the docs, it seems they could access the statements with mw.wikibase.entity:getBestStatements and compare the x/y coordinates as needed to categorise them corresponding to a lua table of descriptive position strings (or even the above Wikidata items). I'm familiar with lua and it seems like a basic operation, but perhaps (likely) there's some wiki specific implementation complexities I wouldn't know about. --SilentSpike (talk) 16:52, 20 June 2020 (UTC)[reply]

Oppose per Jarekt. NMaia (talk) 06:36, 18 August 2020 (UTC)[reply]

@SilentSpike, Jura1, SilentSpike, Juandev, Multichill, Mbch331:@Husky, Jarekt: Not done due to strong opposition. ChristianKl ❪✉❫ 02:11, 31 December 2020 (UTC)[reply]