Property talk:P4765

See Commons:User:Multichill/Paintings to upload. Multichill (talk) 18:44, 22 January 2018 (UTC)Reply

May this property only be used for images or may it also be used for video, audio and documents? Or should different properties be created for that? Ainali (talk) 18:50, 22 January 2018 (UTC)Reply

@Ainali: it includes image in the name because we have image (P18). You can give it a shot with other file types, just do include file format (P2701) and figure out a way to actually upload the files so it doesn't become a huge backlog :-) Multichill (talk) 18:52, 22 January 2018 (UTC)Reply

Ah, I thought the intended use was exactly to create a backlog for someone else™. If I am supposed to upload myself, why should I bother adding this property first instead of just uploading? Ainali (talk) 19:00, 22 January 2018 (UTC)Reply

I also see this property to fill and someone specialised or a bot can do the commons transfer later on. --Hannolans (talk) 20:19, 23 January 2018 (UTC)Reply

I could likely add a lot of statements for this property (quick guess, ~50K for free species images on Flickr alone), but they would be name-based matches, found by a bot. Is that permissible? In other words, can I add what is likely to be a suitable image, and the uploader has to do a sanity check, or only add URLs where I know with absolute (well...) certainty it's the right one, and uploads get done by a bot?

Somewhat different issue, do I link (e.g. on Flickr) to the binary of the image, or the description/landing page? --Magnus Manske (talk) 08:35, 23 January 2018 (UTC)Reply

The same issue arise with museum collections as there are always execptions. I had a talk with Mulitchill and this property can be seen as a suggested. The user adding this value should do a basic check, the user transferring the files to commons, and the user verifing the uploaded images as we can add a review needed tag if the source is inconsistent. --Hannolans (talk) 20:15, 23 January 2018 (UTC)Reply

No, please don’t do that. Imagine how the community would react if you add 50 K image (P18) claims just based on a name match.

This property is just to disconnect the data import process from the upload process. I encounter free files on importing data. Now I can just add this property and get back to this later. Previously I was forced to upload right away or loose the data because I have nowhere to store it.

This should link to the actual file. Have a look at the usage to see some examples. Multichill (talk) 22:01, 23 January 2018 (UTC)Reply

I set up the constraints. Completely focused on artworks now, but that can always be changed.

@Hannolans: Interesting query for the copyright edge cases:

SELECT ?item ?inception ?dod ?country WHERE {
  ?item wdt:P4765 ?url .
  { ?item wdt:P571 ?inception  . FILTER(YEAR(?inception) > 1923) . OPTIONAL {  ?item wdt:P170 ?creator . ?creator wdt:P570 ?dod } } UNION {
    ?item wdt:P170 ?creator . ?creator wdt:P570 ?dod . FILTER(YEAR(?dod) > 1923) . OPTIONAL { ?item wdt:P571 ?inception } }
  OPTIONAL { ?item wdt:P170 ?creator . ?creator wdt:P27 ?country } 
  }

My focus is currently on the easy cases. Multichill (talk) 17:46, 24 January 2018 (UTC)Reply

On Flickr (and many other platforms) there are plenty of free images on all sorts of objects. I suggest removing the domain constraint entirely to allow for photos of places, persons etc. to be added. Ainali (talk) 15:19, 27 January 2018 (UTC)Reply

Can you give some examples? Multichill (talk) 15:24, 27 January 2018 (UTC)Reply

I'll give one, you can surely extrapolate from there: this would fit well on Jakop Dalunde (Q5616258). Ainali (talk) 20:35, 27 January 2018 (UTC)Reply

We could use this property, with a suitable qualifier, for images that are not yet free, but will be on a given date. Then, every January, a bot could process those that fell free at the turn of the year. This would be analogous to commons:Category:Undelete in 2019, et seq. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:34, 6 February 2018 (UTC)Reply

No, let's not do that. This will just become a huge backlog pile linking to copyrighted works that by the time the copyright has expired, will be broken links. Multichill (talk) 21:59, 6 February 2018 (UTC)Reply

We seem to mange web links in other properties well enough. We could also have a bot parse uses and add them to the Wayback Machine's archive. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:35, 7 February 2018 (UTC)Reply

FYI, we now have non-free artwork image URL (P6500). Multichill (talk) 16:25, 25 March 2019 (UTC)Reply

I'm looking at the edge case of images on enwp which are free in the US but not in their source country. For these non-free artwork image URL (P6500) would not work but this one could, with a start date qualifier. /Lokal_Profil 19:12, 26 March 2021 (UTC)Reply

In nearly 2/3 of UN member countries, we really meet the URAA problem(s): Some files can be Public Domain in these countries, but not-PD in the United States, and thus those files are not suitable for Commons and must therefore be uploaded to local projects, hence must consider fair using them. How do the maintainers of this property accounted this problem and detect them periodically? --Liuxinyu970226 (talk) 23:14, 22 October 2018 (UTC)Reply

The last two Complex constraint templates said that creators that died after 1923 will have problem, but not only this problem, some Chinese (ethnic) creators that died ≤ 1923 will also meet URAA problems on Commons, if **their works are published after 1923, and no fair reasons that why US Federal Government agreed that they're Public Domain in US**--Liuxinyu970226 (talk) 23:19, 22 October 2018 (UTC)Reply

Indeed, we should avoid using this property for (ethnic) Chinese-made images because of many kinds of URAA conflicts in Sinophone areas. Or we should say that all items that are having zh.wiki* links should avoid this. --117.14.243.153 02:58, 10 November 2018 (UTC)Reply

@Multichill: Have you ever saw this? Can you please avoid using this property for Chinese-made works? --Liuxinyu970226 (talk) 00:22, 27 April 2019 (UTC)Reply

I’m very good at ignoring. Multichill (talk) 09:04, 30 April 2019 (UTC)Reply

@Multichill:And I'm very happy to explain that all Chinese-made works, that your property linked, are subject to c:Category:Chinese_FOP_cases, happy now? --Liuxinyu970226 (talk) 22:40, 23 May 2019 (UTC)Reply

  Comment Maybe if @Jusjih: can tell us about the copyright problems in Sinophone area. --117.14.250.7 03:01, 24 May 2019 (UTC)Reply

Almost every item using this property had a constraint violation because item requires constraint was set for copyright status (P6216) and copyright license (P275). I disabled the constraints for now. The coverage of copyright status should probably be increased significantly before enabling it again. I'm puzzled by the license constraint. It's on non of the items and I wouldn't expect it on any of them because the original works are in the public domain. @Andrawaag: why did you add the license constraint? Multichill (talk) 12:45, 24 March 2019 (UTC)Reply

We can't add a copyright status for paintings before 1923 when the date of publication is not added. A painting before 1923 can still be copyrighted if the painting was published after 1923. We assume PD, but can't state it --Hannolans (talk) 13:25, 25 March 2019 (UTC)Reply

@Multichill: It wasn't my intention to add it as a logical AND. Of the images added from iNaturalist, I had license statements (i.e. CC0 or CC-BY), which are more expressive than copyright status. So my plan was to add license as an alternative to copyright status. It seems to break, so I will revert. Any idea how to state the applicable license, while ignoring the copyright status?--Andrawaag (talk) 23:35, 25 March 2019 (UTC)Reply

@Andrawaag: I do it like this because the license applies to the URL, not to the item. Multichill (talk) 16:35, 26 March 2019 (UTC)Reply

@Multichill: I like how you use qualifiers to capture the license. It actually makes more sense. I will adapt all items to follow a similar pattern. In the example you give, there are no references. Why don't you use the copyright status property, and would't this example also lead to a constraint violation? --Andrawaag (talk) 08:58, 27 March 2019 (UTC)Reply

@Andrawaag: let's take a step back because this is not really a normal property. This property is intended to be use for temporary statements. Take for example the history of Baroness Antónia Mednyánszká (Portrait of Antónia, Countess of Bolz) (Q50748718). First one bot adds the image suggestion. After a while (quite long, usually it's much faster) the other bot uploads the image and removes the suggestion. References seem a bit pointless in this context. Multichill (talk) 10:30, 27 March 2019 (UTC)Reply

@Multichill: But this is exactly the narrative for our use case, i.e. semi-temporarily placeholders. iNaturalist is a crowdsourcing community, that contains some high-quality content on observation of species. Quite a substantial number of these observations can act as valuable additions to different Wikipedia's. Initially, I started adding those commons compatible images to commons. However the number is quite high, so progress was quite slow. Getting thing forward (e.g. improve Wikipedia pages on nearly extinct species) requires a much higher number of available images.}} iNaturalist has about 200k CC0 images. Also, not all observations are made with the intention to share on Wikipedia. Their main intention is to record the existence of a given species. Having URLs of these images helps in selecting those that can improve a Wikipedia article. Once selected and moved to commons, the statement will be removed. In this use case, having the observation ID, as well as the license as references is essential. iNaturalist observations are available in all many creative commons licenses, and knowing the applicable license helps in selecting images for use in for example Wikipedia or other use-case and decide whether it should be moved to commons or not. Maybe this is similar to author name string (P2093) -> author (P50) --Andrawaag (talk) 12:23, 27 March 2019 (UTC)Reply

Do they have an API? I might just setup a service to harvest it to Commons. Multichill (talk) 13:10, 27 March 2019 (UTC)Reply

Yes there is an API. It is also possible to download CSV. I have mainly used those for further processing. I think such a service is a great idea. I started a thread in the Wikiproject-iNaturalist. Andrawaag (talk) 17:56, 27 March 2019 (UTC)Reply

Hello! I am uploading a number of items from Yale Art Gallery, many of which have Commons compatible image available at URL (P4765). However, I am having some issue with the qualifier constraints. Take Q100314922 as an example. This object is not really a work of art (Q838948) or subclass thereof but rather a commonware utensil. author name string (P2093) also does not feel appropriate here, and I am also not sure about the other two required qualifiers operator (P137) and URL (P2699). I'd value any advice on the best way to apply these qualifiers. Valeriummaximum (talk) 12:38, 15 October 2020 (UTC)Reply

Please see Wikidata:Property proposal/Commons compatible image available at URL (non-artwork). --- Jura 13:25, 12 December 2020 (UTC)Reply

The usage of this property grew to nearly 40.000 items. That's quite a long queue of stuff to upload. I'm working on reducing it a bit:

• Uploading a lot of files: The bot that runs twice a day only works on a subset. I'm improving the bot and also working on the other files.
• Removing links from already uploaded files: Quite a few files had this link for a file that was already uploaded to Commons. No point in keeping it.
• Fixing and removing broken links: Link rot happens all the time. When possible I try to fix the link otherwise remove it.
• Cleaning out non-free files: Some suggestions turn out not to be free. These are moved to non-free artwork image URL (P6500) with the exception of files that become free in the next 5 years on Public Domain Day (Q2917032). Someone might want to do some investigation on these files using the Hirtle chart and might be able to fish out some free files.
• Add missing creators: To determine public domain status the creator and/or the inception needs to be known. Work list at https://w.wiki/ruc (currently nearly 1700 entries)
• Add missing inception: If the creator anonymous or didn't die more than 95 years ago, we need the inception to know if it's public domain. Work list at https://w.wiki/rue (currently nearly 5000 entries)

Multichill (talk) 16:06, 24 December 2020 (UTC)Reply

I suggest we rename this to "Commons compatible image URL". WDYT?--So9q (talk) 06:47, 27 February 2021 (UTC)Reply

If you propose something it's common to provide a rationale why it's better. The current label is just fine. Multichill (talk) 19:13, 27 February 2021 (UTC)Reply