Property talk:P6243

Documentation

digital representation of
faithful digitized representation of the indicated object or work. For use on Commons MediaInfo entities.

Represents

digital representation (Q42396623), analog work (Q112134971)

Data type

Item

Commons example

→ Mona Lisa (Q12418)
→ The Starry Night (Q45585)
→ The Starry Night (Q45585)
→ The First Men in the Moon (Q30474306)

Old deletion discussion

Wikidata:Requests_for_deletions/Archive/2019/Properties/1#digital_representation_of_(P6243) March 2019 -- withdrawn

Artwork only?

Latest comment: 2 years ago9 comments8 people in discussion

The current description implies that only artworks are in scope for this property, but I see no reason why it couldn't be used for any type of object or work in a collection. Any objections to me changing the description to reflect that? Dominic (talk) 12:57, 6 September 2019 (UTC)Reply

Can you provide a few samples before doing so? I think the important part of the description is "2D". --- Jura 12:59, 6 September 2019 (UTC)Reply
- I can imagine for example non-artwork documents (books, laws etc.). There are many scans in Commons, and it can be very useful to connect them to the Wikidata items so that if one wants to process them in Wikisource (using the ProofreadPage extension), they’re easier to be found. —Tacsipacsi (talk) 13:33, 6 September 2019 (UTC)Reply
  - I totally think this property should be applicable to faithful representations (digital surrogates) of all kinds of two-dimensional documents in the broadest sense: maps, prints, drawings, pages of books, manuscripts, archival documents, etc. Spinster 💬 17:01, 19 September 2019 (UTC)Reply
    I definitely agree that this should be applicable to the types of 2D objects Spinster lists above. I would however also suggest that it could apply in the case of faithful 3D scans of objects (at least in the long run when 3D files on Commons support textures). [Yes copyrights differ in this situation but I'm also suggesting that that isn't what the property is trying to communicate, but lets keep that discussion in the section below] /Lokal _Profil 20:24, 19 September 2019 (UTC)Reply
    - This item is not, or should not be related to copyright. 3D, audio and movies (actualle without sounds those are 2D works) should also be in scope. Regarding prints, it should to my believe link to the qid of that individual copy of that print as available in that archive. --Hannolans (talk) 12:32, 21 September 2019 (UTC)Reply

I have updated the description per this discussion, since it seemed no one had an objection. Dominic (talk) 16:34, 8 October 2019 (UTC)Reply

Would someone please put in an example for the use of editions of books. I have added hundreds of books at Wikisource, and never utilised this, and it almost seems to replicate "edition of" and other connections that take place when an edition of a work is replicated at a Wikisource. Thanks. — billinghurst sDrewth 03:45, 4 April 2021 (UTC)Reply

It's an inverse of document file on Wikimedia Commons (P996), to be used on that file. c:File:Wells - The First Men in the Moon, 1901.djvudigital representation of (P6243)The First Men in the Moon (Q30474306), The First Men in the Moon (Q30474306)edition or translation of (P629)The First Men in the Moon (Q1218232) AntiCompositeNumber (talk) 21:21, 23 January 2022 (UTC)Reply

Only for copyright

Latest comment: 5 years ago10 comments6 people in discussion

@Jura1: Following [1], [2], [3], can I point you to Wikidata:Requests_for_deletions/Archive/2019/Properties/1#digital_representation_of_(P6243), which I withdrew when @Multichill: pointed out that this properly was for copyright status. If it's not just for copyright status, it duplicates depicts (P180) - and in that case I'm happy to restart the deletion discussion if you want. Thanks. Mike Peel (talk) 18:45, 6 September 2019 (UTC)Reply

Thanks, but if it's just meant for the copyright status, it should be called accordingly. I don't think this is the scope planned at Wikidata:Property proposal/Digital representation of. As you closed the discussion early, I'm not really convinced people subscribed to that point of view either. --- Jura 19:59, 6 September 2019 (UTC)Reply
@Mike Peel: As we explained at the time, this is a more specific sub-class of that property. It's the same reason we have both P31 and P527. I appreciate that you withdrew it on mistaken grounds, but that doesn't mean your assertion that started the discussion was correct. If you really feel this strongly, you should re-open the discussion (and we'll hopefully convince you that you're wrong, or at least out-mass you). James F. (talk) 21:13, 6 September 2019 (UTC)Reply
Maybe c:Template:Artwork is the better comparison. Obviously, it can include copyright info. Is there some related discussion on Commons that would require the addition to the description? --- Jura 07:15, 9 September 2019 (UTC)Reply
@Jura1: c:Template:Artwork would naturally use depicts (P180), this property isn't needed for that template. c:Template:PD-Art is the example I was pointed to, which is entirely copyright-based. Thanks. Mike Peel (talk) 20:05, 19 September 2019 (UTC)Reply
- c:Template:Artwork already uses P6243 to get values for author, references, name, .. I'm currently working on creating items for such artworks --- Jura 20:55, 19 September 2019 (UTC)Reply
I'd definitely suggest that limiting the scope of this Property to "only for copyright" would be unfortunate. It blurs the line of WHAT we are trying to say with the Property with WHY we are saying it. If the motivation is to have a Property that says "no new copyright in jurisdictions that require creativity" then that would probably be better served by something like copyright status (P6216)public domain (Q19652)applies to part (P518)digital reproduction (Q5276149)determination method or standard (P459)no copyright because faithful reproduction without creativity (not necessarily those properties but that general idea). But that was not what either the original proposal nor the deletion request discussion suggested was the purpose of the Property. /Lokal _Profil 20:21, 19 September 2019 (UTC)Reply
OK, I've posted Wikidata:Properties_for_deletion#digital_representation_of_(P6243). Thanks. Mike Peel (talk) 19:36, 20 September 2019 (UTC)Reply
On Commons we have many templates that have wikidata field indicating an item for depicted object, be it a painting, drawing, book, sculpture, archaeological artifact, famous photograph, building, ship, etc. This is very different than depicts. A painting can depict several people and dozen objects, but should be linked to a single item for specific painting. Since some paintings might have very large number of depict statements it is often not possible to load entities for all of them to maybe find one for the painting item. The copyright issue is definitely important, but it is not the only purpose. My main issue with P6243 is that the description seems to exclude sculptures, books, artifact and other 3D objects. I do not think we need another property for storing the link the depicted 3D object. --Jarekt (talk) 05:09, 30 November 2019 (UTC)Reply

If I read the discussion Wikidata:Requests_for_deletions/Archive/2019/Properties/1#Property:P6243 the general outcome was that we should split United States-copyright situation of the photo and digital representation of a work. I will alter the desription. --Hannolans (talk) 12:36, 3 December 2019 (UTC)Reply

Frames

Latest comment: 5 years ago3 comments3 people in discussion

Starry Night Painting

Currently there is a painting with a picture frame (The Starry Night (Q45585)) in the examples a digital representation. That is not a good example. The frame does have it's own copyright status and has his own author. It is a collage of two art objects and it also makes the work 3D. --Hannolans (talk) 19:07, 19 September 2019 (UTC)Reply

You're quire right. I've been bold, and removed it as an example.

digital representation of (P6243) should only be used if an image shows the whole of an 2D art object, all of it, faithfully, directly square-on, and nothing but the 2D art object (ie no frame, no adjacent wall, no surrounding gallery, no other work, etc). Jheald (talk) 15:58, 21 September 2019 (UTC)Reply

I think it's something to discuss on Commons. Here you might just get some people saying one thing and doing another thing. From a Wikidata perspective, some stuff around shouldn't be a problem, but partial reproduction would seem odd. --- Jura 16:41, 21 September 2019 (UTC)Reply

2D vs. 3D

Latest comment: 2 years ago25 comments6 people in discussion

When I first proposed this property at Wikidata:Property proposal/Digital representation of it was meant for Wikidata field of the c:template:Artwork (with single-value constraint) with following examples:

Structured Data for → Mona Lisa (Q12418)
Structured Data for → The Starry Night (Q45585)
Structured Data for → David (Q179900)
Structured Data for File:Julien Bryan - Siege.ogv → Siege (Q1351398)
Structured Data for File:"The Star-Spangled Banner" performed at the White House in 1994.oga → The Star-Spangled Banner (Q44696)

Latter per suggestion of user:Multichill, User:ArthurPSmith narrow the scope to only include 2D artworks. So now the problem is what should we do with Digital representation of other artworks and objects, like sculptures, movies, sound recordings, books, 2D printouts of maps, and documents which are not works of art, etc. Originally this property was suppose to cover them all, but now in the narrow form I do not know what to do with all the rest? As I understand the "2D art" restriction was added so one can verify that the image fulfills the requirements of c:template:PD-Art. Can we model that with:

copyright status

public domain

edit

determination method or standard

faithful reproduction of two-dimensional public domain work of art

applies to jurisdiction

(countries listed in c:Commons:Reuse of PD-Art photographs)

digital representation of

Mona Lisa

0 references

add reference

add value

and expand the scope of this property to cover all "digital representations of"? --Jarekt (talk) 06:07, 25 December 2019 (UTC)Reply

Sounds like a good plan Jarek. I lost track a bit around the time with the deletion discussion. For the copyright model on Commons I would use applies to jurisdiction (P1001) -> United States of America (Q30) because it's based on Bridgeman Art Library v. Corel Corp. (Q1400715) and most in line with Commons:When to use the PD-Art tag, which contains a section about other countries and we have a reuse of PD-Art photographs page. We should probably move the copyright part over to Commons:Commons talk:Structured data/Modeling/Copyright. Multichill (talk) 13:01, 25 December 2019 (UTC)Reply

Multichill, applies to jurisdiction is mainly US but there seem to be bunch of other countries which have laws with similar effect, like Poland, Monaco, Japan, Slovakia, Romania, Switzerland, and possibly others. I was thinking about grouping them into a single item with a list of countries, like countries with 70 years pma or shorter (Q59542795). The only issue would be creating a shortish name, hopefully without using "PD-Art" which is commons only lingo. Perhaps US and other countries where faithful reproductions of a 2D works of art do not have additional copyrights, or some shorter version. --Jarekt (talk) 15:43, 25 December 2019 (UTC)Reply

Looks good to me. --Marsupium (talk) 18:17, 4 July 2020 (UTC)Reply

@Jarekt, Multichill, Marsupium, ArthurPSmith: I am not at all happy about this, and not just because at present there is only one single image with the mechanism proposed above, with determination method or standard (P459) = faithful reproduction of two-dimensional public domain work of art (Q79719208) or applies to jurisdiction (P1001) = countries where faithful reproduction of a 2D work of art do not have additional copyrights (Q80258411). (viz: File:Maerten van Heemskerck - Self-portrait, with the Colosseum (Fitzwilliam Museum).jpg)

This property was intended to represent a fundamental fact about the image, namely that all images with the same value of the property should be very very similar (with perhaps possible differences because of e.g. different lighting or different colour balances), but essentially identical.

That's a fairly fundamental feature of the image to be identified, not some footnote detail in its copyright assessment. Yet that intended meaning, the purpose for which this property was approved, has been utterly lost by the broadening of this property.

Instead, the property seems to have morphed into "depicts artwork" -- which I thought we were using depicts (P180) for; and it seems to have been used regardless of whether the whole work is presented, or merely a small part (such as use on eg a single page of a manuscript, or a detail from a larger picture), and regardless of whatever else might have been in the image.

We should also think quite closely about why this use has been co-opted, what that tells us about depicts (P180), and whether there are other circumstances as well that depicts (P180) may not be sufficient for, to which a uniform approach should be taken.

What has been done is such a radical change that it should not have been made without pinging all who were involved in the property proposal process and subsequent discussions of its use. At the very least, the property should now be renamed to reflect its actual current use, and a new property be proposed to take up what was this property's original intended function. Jheald (talk) 16:17, 24 July 2020 (UTC)Reply

The proposal was to create a property for digitized representations of objects, equivalent to the way we use "wikidata" field in c:template:Artwork and c:template:Book, or to connect digital recording of a song or a movie to the item for that song or a movie. It is different than depict statements since any file can be "digitized representations of" a single object, but can depict multiple objects: person, wearing a hat, on horse, with sunset in the background, etc. If we need a property to mark some objects as 2D or 3D I would vote to add it, or we can use instance of (P31) for it. --Jarekt (talk) 16:48, 24 July 2020 (UTC)Reply

@Jheald: I don't have any strong opinion here, but do we have some statistics on how the property is currently being used? Or at least what are some common examples of proper and improper usage according to your view? ArthurPSmith (talk) 17:09, 24 July 2020 (UTC)Reply

@ArthurPSmith: There are now some queries relating to the property, on the new c:Commons:SPARQL_query_service/queries/examples page:

Digital depictions of "David" by Michelangelo, tinyurl.com/y4nrxxk6
Objects with the largest number of Digital Representations (P6243), tinyurl.com/y4myl8z6
Count of number of Digital Representations (P6243) by type of object represented, tinyurl.com/y2hq4kdu

It is currently being used on over 225,000 files (tinyurl.com/y2oplu73)

My first shock was the first query, given that I was expecting multiple subjects of digital representation of (P6243) to be almost identically similar images of a single 2D object -- not lots of different 2d views of the statue (and showing not just the statue, either). Conceivably a 3d printer file for the statue might be a "digital representation of" the statue. But these?

The second row from the second query seems to be multiple images from a single book, each showing a different page. This I think is also wrong, because these are not digital surrogates for the whole work, which at minimum seems to me to be what this property appears to be promising. IMO items such as atlases, illuminated manuscripts, books of hours, encyclopedias, series of paintings are not suitable object-values for this property.

Where multiple images are being returned for a work that is a painting, eg tinyurl.com/y6yjnasp for The Night Watch (Q219831), we find the returns include crops, such as this or this, a video of restoration work on the picture, (here), a picture primarily of a sea of people in the room of the painting (this), or with a crowd of people obscuring the picture (this), or where the focus seems to be on the people obscuring the picture (this, this. None of these are what the name of the property promises -- namely, a digital representation of the object.

Returning to statues etc, if we allow these, then what meaning does "digital representation of" have, other than just "photograph of" ? If someone takes a tourist snapshot of Mount Fuji, is that then a "digital representation of" Mount Fuji ? Or the Parthenon? Or Brighton? Or anything? And if not, then why not?

Trying to come up with a way forward, perhaps some of what I am looking for could be fixed by adding a subject has role (P2868) with one of some suitable set of values, to describe in just what manner the file is a representation of the object. But some of the above shouldn't be using digital representation of (P6243) at all, it seems to me. And when the usage is so wide, it seems difficult to identify just what is or is not acceptable kind of object-value for this property. Jheald (talk) 20:30, 24 July 2020 (UTC)Reply

Is there some issue with its labels or aliases in some languages? I agree that I would have expected depicts (P180) to be used for most of the cases you mention. For a 3D object I would have expected (if this applied at all) this to correspond to some sort of 3-dimensional model of the object, not a 2-D photograph. ArthurPSmith (talk) 23:10, 24 July 2020 (UTC) (edited) - following up - on the cases where a book, atlas, series etc. is the target value, I think it is reasonable to use this property for these cases but with a qualifier like applies to part (P518) if possible - otherwise you would need a Wikidata item for every page which doesn't seem reasonable. ArthurPSmith (talk) 23:18, 24 July 2020 (UTC)Reply

I had a look at this and this doesn't make me very happy either although I probably feel a bit less strong about it.

We should probably drop the whole 3D object part and move those to depicts (P180). So basically the target of digital representation of (P6243) should be a 2D object. Things like sculptures should be moved. Can we get agreement on that part? So all usage for David (Q179900) would be moved to depicts (P180).

Parking the 2D part of crops etc. for now. Let's focus on the 3D part first. Multichill (talk) 20:50, 26 July 2020 (UTC)Reply

For me if a photo shows a group of distinct objects, like paintings or sculptures, than it should use depicts (P180) but if it shows a single object with wikidata item than it should use digital representation of (P6243). For example if someone takes a photograph of a sculpture and uses c:template:Art Photo template in the file description than in that template they mostly provide information about the photograph, photographer and photographer copyrights, and information about the sculpture (including sculpture copyrights) should come from wikidata item. In such a file we should use digital representation of (P6243) to indicate that this is a photograph of that single sculpture. In case of paintings or other 2D objects I think it would be nice to also model information that that is a faithful reproduction of 2D object, (so no frames and no strange perspective) meeting requirements of US law Bridgeman Art Library v. Corel Corp. (Q1400715) that allows us to ignore photographers copyrights, if we choose to. Perhaps this slightly different relationship between file and the wikidata item could be modeled by adding a qualifier which more narrowly defines this relationship, maybe instance of (P31) = "faithful reproduction of a two-dimensional object" qualifier. While we are at it we should also model a relationship where a photograph shows a detail or crop or larger artwork, maybe instance of (P31) = part (Q15989253) or a new item created for this purpose. I do not think it is good to use depicts (P180) for linking digital representations to the original objects, because with depicts (P180) do not have single value constraint and the item linked to can be anything, like person, hat, flower, etc. I understand that if we have photograph of a painting than SDC's depicts (P180) shoild link to a painting item and that painting's depicts should list items depicted in the painting, but I do not trust that casual Commons user will make this distinction so I expect such files to have a lot of items depicted in the painting. It is even more confusing if we have different files for different digitization of the same photograph with Wikidata item, I would no want to try to separate original photograph depicts from photograph of photograph depicts (which should be the original photograph item). --Jarekt (talk) 14:36, 29 July 2020 (UTC)Reply

@Jarekt: I'll just put these two photos next to each other:

I think we're better off not using digital representation of (P6243) for this. You can take photos from 3D objects from all sorts of angles. But how to deal with the fact that we actually want to see information about the main subject on Commons?

First we need to store the item David (Q179900) / Brandaris (Q897813) somewhere and make clear it's not some random inclusion. My preference would be to use main subject (P921) for this. Other option is to use depicts (P180) with rank preferred. In the code that generates the template we should check if the target is a specific instance and not a general concept. We can do that by checking that the target item has instance of (P31) and not subclass of (P279). This approach would scale to a lot of other domains too. Multichill (talk) 14:07, 8 August 2020 (UTC)Reply

@Multichill: the Commons templates Artwork, Art_photo, Book, and Photograph are all implemented using c:Module:Artwork and all have "wikidata" parameter, to tell the code which item to pull all the metadata from. This property was meant to serve the same purpose and in my proposal I indented to extend it also to movies, sound recordings, maps, etc. and any other object that might get digitized. The property was meant to be have single value constraint so it is not used in case a photo shows 2 sculptures for example. I am OK in using separate properties for different types of objects, but I think those properties still need to have single value constrain and not be useful for storing other types of information for files which do not have wikidata items. Property main subject (P921) sounded like a very good match, except that it does not have single value constraint and it is already used 11M times for totally different purpose, see for example Q1055332. Currently teenager (Q1492760) is the most used value of main subject (P921) statements. If someone starts adding P921 statements to files on Commons following the way the property is currently used on Wikidata, I do not think we can tell them that they are doing something wrong. Below I added a table with different cases to consider, most of which were in the original scope of this property. If we want to stick to the narrow scope than we would need to find other ways to model the relationships. There are a lot of potential types of relationship there and we will probably narrow them down with qualifiers. My preference would be to model them with P6243, but we could restrict P6243 to orthophotos and scans of 2D works, and create some other property for other digital representations. --Jarekt (talk) 18:47, 10 August 2020 (UTC)Reply

type	example file	example item	inverse of a property	comment
orthophoto (Q922585) of a painting		Mona Lisa (Q12418)	image (P18)	in original and narrow scope
orthophoto (Q922585) of a painting with frame		Mona Lisa (Q12418)	image with frame (P7420)	in original and narrow scope
Distorted photo of a painting, example perspective distortion (Q15889487)		Mona Lisa (Q12418)		model with depicts (P180)
Detail of a painting		Mona Lisa (Q12418)		Files on Commons use Artwork template with wikidata parameter
Photo of a sculpture		Mona Lisa (Q12418)	image (P18)	in original scope
Photo of a building		Brandaris (Q897813)	image (P18)	in original scope
3D model of an object		Eiffel Tower (Q243)	3D model (P4896)	in original scope
Digitization of a whole book		Mona Lisa (Q12418)	document file on Wikimedia Commons (P996)	in original scope
Digitization of a single page of a book		Oroonoko (Q2453934)		model with depicts (P180)
Digitization of a whole movie		Siege (Q1351398)	video (P10)	in original scope
Recording of a song or melody	File:"The Star-Spangled Banner" performed at the White House in 1994.oga	The Star-Spangled Banner (Q44696)	audio (P51)	in original scope
inverse of coat of arms image (P94), traffic sign (P14), flag image (P41), image of grave (P1442), sheet music (P3030)

@Jarekt: sorry for the late reply. Thanks for creating the overview. As you probably noticed I've been working on licenses. I want to circle back to (PD-)art again now. I would like to work on solving this by at least breaking out some parts. Currently main subject (P921) is barely used on Commons (253 files) so I think the risk is limited to start using it. Let's update the template(s) so that if main subject (P921), the data about that subject is retrieved and shown. So basically on Commons main subject (P921) becomes: The subject I want to show more about in the interface like the Object part in Template:Art Photo. Next step is that we move the obvious 3D cases like David and the Brandaris to main subject (P921). In think this way we can at least cover most of the artwork template cases. We park the other cases for now and get back to them later. Agree? Can you update the artwork template so that it uses main subject (P921) too? Multichill (talk) 17:58, 25 September 2020 (UTC)Reply

Multichill we need to be able to control the use of the property we need for linking commons infobox templates with Wikidata. Yes main subject (P921) is a fine name and is not used much on Commons but if someone adds to a file like File:Capitole Toulouse - Grand escalier - Buste de Jean Jaurès par Paul Ducuing.jpg main subject (P921) = Jean Jaurès (Q12688) than I would like to remove it because I do not want Artwork template to link to that item. That use is perfectly in line with the current use on Wikidata (and seems to be the same as depicts (P180) with the "prominent flag") which has to be widespread as 12M items use it. The main subject (P921) also does not have uniqueness constraint so you can add bunch of them to a file. The main subject (P921) of Harry Potter (Q8337) is death (Q4) and adolescence (Q131774), so if someone want to say that the main subject of their abstract photo is death (Q4) and adolescence (Q131774), I do not want to be the one telling them that they can not use it because Artwork template uses it for something else. The purpose of this property when I proposed it was to use it with c:template:Artwork and other infoboxes on Commons. However I see now that from the beginning you were thinking about c:template:PD-Art use which is also very needed. I would like to settle this, and the way I see it if that we have one property which is needed to model 2 different things which overlap but not 100%. We can resolve this 2 different ways:

with qualifiers: for example We could add a qualifier asserting that this is digitization of 2D object which meets criteria of PD-Art
with creation of new property for digitization of 2D object which meets criteria of PD-Art or creation of new property for general "digitization of" purposes

I am leaning more towards the qualifier solution, which can also be used to deal with photos of object details, distorted views of 2D paintings, etc. But if you think that is a bad idea than lets talk about now property proposal.--Jarekt (talk) 21:30, 25 September 2020 (UTC)Reply

Hi folks, Multichill alerted me to this discussion - thanks for all the very good thinking and suggestions already. Summarizing my own thoughts:

I have always considered digital representation of (P6243) to be a property for all those cases where the file on Commons is such a faithful 'digital surrogate' of the creative work that (for many legislations) no new copyright can be applied to the surrogate. This indeed applies to faithful reproductions of two-dimensional artworks, but I would (not 100% legally certain of this...) also extend it to faithful 3D scans (see e.g. this post by Creative Commons), and probably also complete digitizations of books and other documents, films and music/audio. (I'd appreciate a legal expert's input on this.) I would use digital representation of (P6243) in addition to depicts (P180). So in Jarekt's table with examples above, I'd use depicts (P180) AND digital representation of (P6243) (the creative work) for
- both orthophotos (although the one with frame is an edge case.....)
- (?) the 3D model of the object
- (?) the digitization of the book
- (?) the digitization of the entire movie
- (?) the digital recording of the entire song
I think a different property may indeed be useful to indicate the other cases, where there's a creative (copyrightable) act involved in making a photo (or video?) of a work. I follow Multichill's idea to try with main subject (P921). While I see Jarek's point above, of possible confusion with 'other' uses of main subject (P921), I wonder whether this potential confusion will actually produce many actual problems or whether it will just be a few edge cases (I think it's the latter). If, after testing, it turns out problematic we can still propose a property of its own (something like 'file shows a perspective on creative work' - better phrased). I would also use main subject (P921) in addition to depicts (P180). So in Jarekt's table with examples above, I'd use depicts (P180) AND main subject (P921) (the creative work) for
- the distorted painting photo
- the photo of the sculpture
- the photo of the building
I don't have strong ideas on how to deal with details / excerpts yet. We have various situations there - you can have a file that is an actual crop from another file, but also intentionally separate photographs of details of a work, e.g of the plaque on a sculpture's pedestal. I'm currently leaning towards using qualifiers together with main subject (P921) in especially the second case.
As Jheald pointed out with the various queries, quite a bit of this is probably not extremely intuitive to Commonists who are not acquainted with art, and people may do it 'wrong' which will need to be actively corrected on an ongoing basis. So good documentation will be key, in addition to maintenance scripts, bots and tools. If we have decent non-coder-friendly tools to help with maintenance, I'd be happy to contribute to upkeep.
This point is not mentioned in the discussion above and it's a bit out of scope but I want to say it anyway: I think a redesign of the Artwork template may be useful, in fact redesigning all Artwork infoboxes to look like the current Art photo template - with a clear distinction everywhere between the metadata (incl. copyright) of the work and the metadata of the file. This will IMO be very educational to our audiences, including GLAMs.

I hope this helps and does not add more complexity. Thanks for all the good work everyone's doing. Cheers, Spinster 💬 11:25, 26 September 2020 (UTC)Reply

One further consideration, given that there now seems to be real movement towards a fully-fledged IIIF service from Commons (cf mw page and talk page; WMSE's phab:T261621, Etherpad from this Monday and Tuesday, C:VPT backgrounder, and c:COM:IIIF), is that we need to have a way to distinguish images for which relative position within image (P2677) will accurately identify the locations of those details within the image (and therefore information about those details from Wikidata are safe to be included as annotations within the images' IIIF manifests), from images where that is not true. For my part, that is what I understood the original approved purpose of digital representation of (P6243) as indicating; and it is what the description of the property still seems to promise. If there is another thing we need a mechanism for, namely to mark an image for which it may be appropriate to use a {{Artwork}}, and indicate the relevant Q-number for that template, then we should develop a different property or mechanism for that purpose. Jheald (talk) 13:18, 26 September 2020 (UTC)Reply

Ok, so we have need for modeling 3 different things:

use with c:template:Artwork. Equivalent to {{Artwork|wikidata=...}}
use with c:template:PD-Art marking items that are digitization of 2D object which meet criteria of PD-Art
use with relative position within image (P2677) to distinguish images for which that property in the wikidata will accurately identify the locations of those details within the image

Those are 3 different needs with the first is the most broad and than each next will apply to fewer and fewer files. And I agree that we should model all 3. As I mentioned yesterday we could model them with qualifiers or with new properties. It sounds like Jheald is thinking new properties. When I proposed creation of digital representation of (P6243) it was for the purposes of use #1, but by the time it was approved it was morphed to #2. It is hard to tell which votes are for which use. I still think we can model all 3 uses, and how to apply it to different types of photos (see table above) with qualifiers. Maybe

digital representation of

Mona Lisa

edit

of	two-dimensional public domain work of art

0 references

add reference

add value

for use #2? Or perhaps there is a better qualifier to use. instance of (P31) seems fine but it is not supposed to be used as qualifier. --Jarekt (talk) 16:09, 26 September 2020 (UTC)Reply

I would prefer that digital representation of (P6243) were only used for #3. That's what was approved, and that's what was confirmed in subsequent discussion as the relationship that should qualify to be represented by P6243 -- not photos with frames or other additions, just an image of the original painting, all of it, square on, undistorted, nothing more, nothing less. To me that 1:1 correspondence is the contract that the wording "digital representation of" implies. For other applications, use other properties -- eg some appropriate ranking or qualifier on depicts (P180). Jheald (talk) 18:17, 26 September 2020 (UTC)Reply

When I proposed this property the "digital representation of" meant that the subject object was digitized by scanning or photographing of 2D or 3D objects or digitizing of audio or video. The examples showed the range of items it was meant for. (In retrospect, I guess a photograph is not a great "digital representation of" of 3D object, the way STL files are.) I will propose a new property. However there will still be connflict between purpose #2 and purpose #3 as the first one would cover painting details, like

and the second one would not. --Jarekt (talk) 04:43, 28 September 2020 (UTC)Reply

@Multichill, Jheald, Spinster, ArthurPSmith: It seems like consensus is to split this property, so I created Wikidata:Property_proposal/Commons#infobox_based_on. --Jarekt (talk) 04:54, 28 September 2020 (UTC)Reply

@Jarekt, Jheald, Spinster, ArthurPSmith: I waited out Wikidata:Property_proposal/Infobox_based_on to see what other opinions would come up and added my support and motivation. Let's do this so we an start moving again. Multichill (talk) 12:20, 7 March 2021 (UTC)Reply

Multichill, I just had an novel idea about Wikidata:Property_proposal/Infobox_based_on. Maybe instead of new property, a better solution would be main subject (P921) with object of statement has role (P3831) qualifier set to "Use this item for linking from {{artwork}} template" item. I could try to enforce restriction that only one main subject (P921) can have that flag. Whould that be a better model in you opinion? I hope that would be in scope of what object of statement has role (P3831) is meant to be. --Jarekt (talk) 19:02, 11 March 2021 (UTC)Reply

@Jarekt: I think what you suggest makes a lot of sense. It also has the advantage that it could be done straight away, without needing any new properties, just one new Q-item so you could write object of statement has role (P3831) = "appropriate subject for infobox" (which might be a more detached name for it).

I presume the fallback chain would be to look first for a main subject (P921) with the object of statement has role (P3831) qualifier, then a digital representation of (P6243) statement -- so that digital representation of (P6243) statements would continue to work until main subject (P921) / object of statement has role (P3831) statements were made? And indeed that if a digital representation of (P6243) statement continues to be appropriate (because the image is a digital surrogate), then that would be enough; so that it would only be for images of statues, 3d works, etc, that there would be a need for the new P921 + P3831 combination, as other works would keep their P6243s, which would be sufficient?

One other question: what would be the preferred approach for an image that is a crop of a painting or other artwork, showing a particular detail? main subject (P921) might not be appropriate. Jheald (talk) 10:41, 12 April 2021 (UTC)Reply

See Commons:Commons talk:Structured data/Modeling/Depiction#Unstucking digital representation of (P6243). Multichill (talk) 15:46, 28 December 2021 (UTC)Reply

Constraints

Latest comment: 2 years ago8 comments6 people in discussion

Hi @Multichill, Spinster, Pintoch, Swpb, Dominic, Jarekt:,

I'm a bit confused, why is there constraints item-requires-statement constraint (Q21503247) = depicts (P180) and main subject (P921)? I'm a bit confused, especially by the first one, I would say the opposite : if there is a P6243 then there shouldn't be P180 since P180 should already be on the Wikidata item, no? Or maybe it's on purpose and we should duplicate Wikidata data in the Commons wikibase? (I really don't like redundancy but since federation may be complex it could make sense as a trade-off) or maybe I'm missing something else?

Cheers, VIGNERON en résidence (talk) 14:38, 3 August 2022 (UTC)Reply

Hi @VIGNERON en résidence, some of this is explained at COM:SDC/Modeling/Depiction#Works of art. As I understand it, the combination of the three statements (depicts (P180), digital representation of (P6243), main subject (P921), all pointing to the artwork) will trigger the {{Artwork}} template of the Commons file to display the artwork's metadata via Lua. We shouldn't skip depicts (P180) (pointing to the artwork shown in the file) because the Wikimedia Commons search index prioritizes that statement. That said, I am including this in draft OpenRefine documentation and I notice that it's really difficult to explain this to people, it is perceived as illogical and confusing. Simplification, if possible, may be good. Spinster 💬 17:16, 3 August 2022 (UTC)Reply

@Spinster: I only filled the digital representation of (P6243) and it was enough for the "Artwork" template to retrieve Wikidata data (which is kind of logical, otherwise would be suboptimal). Cheers, VIGNERON en résidence (talk) 07:02, 4 August 2022 (UTC)Reply

"if there is a P6243 then there shouldn't be P180 since P180 should already be on the Wikidata item, no?" This is true semantically, but maybe not for the software? If I recall, I think the "depicts of depicts" problem means that putting something only in the Wikidata depicts makes it invisible in Commons search, right? Though I do think what Spinster says about P180 being given highest priority in search relevancy is probably not the best logic. If I am searching for "Mona Lisa", I probably want to see the Mona Lisa higher in results than just images in which the Mona Lisa is depicted, so it actually makes sense to give P6243 specifically higher weight even than P180. Might be worth filing a Phab ticket. In any case, if the suggestion here is that for every P6243, there ought to at least be a P180 of the same value, I agree that this isn't very clearly stated—and actually, this specific task could be enforced by bot, it seems. Dominic (talk) 00:35, 4 August 2022 (UTC)Reply

@Dominic: excellent question, this is exactly what I'm fearing "software issues". I'm not sure about the implication but what you suggest sounds sound. I think I saw bot doing the copy of P6243 in P180 and was already wondering why back then. Cheers, VIGNERON en résidence (talk) 07:02, 4 August 2022 (UTC)Reply

@VIGNERON en résidence, Spinster, Dominic: as a user you just need to add digital representation of (P6243). Some robot runs every night to add the missing other statements.

Why all three? To create a scale with overlap. I don't want to have a hard break between depicts (P180)/main subject (P921)/digital representation of (P6243). On top of this, it prevents people adding depicts (P180) (or main subject (P921)) that should be on the Wikidata item.

The software support from the SDC team sucks and the current search support for SDC is even worse. I don't understand and I don't agree with their choices and stopped bothering to file tickets. Even some simple bugs took months to fix. They refuse to work on improving the search engine to use data from Wikidata to improve search. They seem to be more focused in getting in money from grants instead of improving Commons. Looks like they got a new product owner and his approach is to just close the bugs they don't want to work on. I'll do a @MPham (WMF): because I don't like to talk behind someone's back, but I doubt we'll get any response. Multichill (talk) 19:21, 6 August 2022 (UTC)Reply

Just for a bit of more accurate info, the SDC team was shut down at the end of the project in mid-2020 (I left in mid-2019 to work a different project).

The Structured Data Across Wikimedia team was established in its place to work on a different, parallel piece of work, with some of the same team, but the responsibility for SDC work was not transferred to them.
The Search Platform team, for whom Mike is the PM, is responsible for Wikimedia Search for all Wikimedia sites, but principally the non-MediaWiki parts of our search infrastructure (i.e. the ElasticSearch cluster and the WDQS and CDQS Blazegraph clusters) rather than the custom integration (which e.g. for wikitext is conceptually the MediaWiki Platform team's responsibility, etc.).

If you think there should be a Structured Data on Commons team (or a Commons team, or a Multimedia team, etc.) please don't blame the individuals who don't get to decide these things. Jdforrester (WMF) (talk) 15:25, 8 August 2022 (UTC)Reply

Value type

@Jura1, Dominic, Multichill, Yann, AntiCompositeNumber, Spinster: There are currently three distinct value-type constraint (Q21510865) statements on this property, one of which links to the original property proposal for reference, while another is indicated as a suggestion constraint (Q62026391). The allowed value classes are mostly different, with occasional overlaps.

I can't even figure out what they mean together. Is there any reason for having three distinct statements, or could they be merged into one? Having read the discussions concerning the creation and (withdrawn) deletion proposals, I understand this property describes a pretty intricate relationship between objects of visual art and their depictions within a Wikimedia Commons context (where I'm not involved), so I'd rather not try to change anything here myself, but it sure doesn't look right to me.

All the constraints are right now flagged for lack of a stability of property value (P2668) statement. It's probably not important, but if you have an idea of whether it "never" or "sometimes" changes, you may want to specify that as well. --SM5POR (talk) 12:25, 18 December 2022 (UTC)Reply

Add topic