Wikidata:Property proposal/Flickr tag

Flickr tag edit

Originally proposed at Wikidata:Property proposal/Authority control

Not done

Description	Tag used on Flickr to indicate images relating to a particular item
Data type	External identifier
Template parameter	Template:Flickr tag inline link (Q21619988)
Domain	any
Allowed values	[^\s\/]+
Example 1	England Delineated (5th edition) (Q52230303) -> sysnum000033859
Example 2	MISSING
Example 3	MISSING
Source	https://www.flickr.com
Planned use	to add to items for British Library "Mechanical Curator" image sources; but the property would also be useful for images uploaded to Flickr in projects by eg the Internet Archive, Biodiversity History Library, Smithsonian, etc, etc.
Number of IDs in source	Perhaps 100,000 for institutional projects, maybe more. But probably only a certain proportion of these would actually be added to items.
Expected completeness	always incomplete (Q21873886)
Formatter URL	https://www.flickr.com/photos/tags/$1

Motivation

A number of digitisation projects have uploaded images to Flickr, using Flickr tags to group images from particular sources or relating to particular subjects. It would be useful to record these, and provide easy linking to the corresponding images. Jheald (talk) 15:02, 18 May 2018 (UTC)[reply]

Discussion

Proposed. Jheald (talk) 15:02, 18 May 2018 (UTC)[reply]
Support David (talk) 16:38, 18 May 2018 (UTC)[reply]
Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:21, 18 May 2018 (UTC)[reply]
Oppose seems to be the wrong datatype if not limited to the British Library tags. String is what we use for similar (e.g. Twitter tags). If the use wont be limited to a single item, it shouldn't be an external identifier either (compare with some other classifications).
--- Jura 18:08, 20 May 2018 (UTC)[reply]
- @Jura1: It's an identifier, it's external => it ought to have an external identifier type. Much better for it to appear below the fold than cluttering up the main section of statements on an item. If you want to record whether it is generally 1-to-1 or not (and, yes, it's probably not, if one starts going beyond institutional tagging), that's what constraint statements on property pages are for. Jheald (talk) 18:18, 20 May 2018 (UTC)[reply]
- I agree with you, but that's not the conclusion from the discussion about the string datatype conversion. Besides, mere GUI things can be changed otherwise. So to be consistent with others, it should use string datatype.
  --- Jura 18:21, 20 May 2018 (UTC)[reply]
  - @Jura1: A particular aspect of our GUI could be changed, but in this case its unlikely -- how should the GUI distinguish string-valued statements for genuine strings that ought to appear above the fold, from string-valued statements for external identifiers, which ought to appear below the fold. Much better to make all external identifiers external-identifier valued.

Even more difficult, how are external applications supposed to recognise strings that refer to external identifers, if they are not external-identifier valued? For example, Reasonator. The value of this property ought to be in Reasonator's external links box in the right-hand column. But how is eg Reasonator supposed to know that, if the property is string-valued rather than external-identifier valued?

If other properties have been given unhelpful types, the place to start changing that is here and now. So I stand firm for making this external-identifier valued, because it is an external identifier, and I believe it is helpful to external applications to mark it as such. We should remember that "consensus can change". If external identifiers haven't been given external-identifier type, that nonsense has gone on long enough, and we should end it. :::Can you give a link to the earlier discussion on this? What were supposed to be the conclusive benefits of giving external identifiers a type other than external-identifier? Is any application in the wild relying on this distinction (as opposed to being degraded by it, like Reasonator) ? And if this is about reasonably consistent single-valuedness, why is that not more effectively indicated by the explicit constraint statements on |the property? Jheald (talk) 19:29, 20 May 2018 (UTC)[reply]

It's just not the outcome of the discussion. Datatype alone isn't necessarily a good indicator for GUI construction. Currently this mixes social media accounts of a person with third party identifiers. Depending on the presentation, this can look bad. I asked our developers to look into some of the GUI issues at Wikidata. Obviously, interface things are always top priority for them ;)
--- Jura 07:14, 21 May 2018 (UTC)[reply]

Oppose per Jura1--Shizhao (talk) 07:23, 28 June 2018 (UTC)[reply]
Oppose last time I checked Flickr tags were just strings, not stable identifiers for a concept. This will just cause noise in our dataset. Multichill (talk) 10:36, 13 July 2018 (UTC)[reply]
Oppose even if some users use the tag system as a way to create collections, these tags are not designed for that and are generally just prose. So oppose for the same reason as for Wikidata:Property proposal/Gfycat tag. − Pintoch (talk) 19:28, 22 July 2018 (UTC)[reply]
Oppose per Multichill --Pasleim (talk) 22:55, 22 July 2018 (UTC)[reply]
- @Multichill, Pintoch, Pasleim: So what property do you suggest I ought to use, to record a value that can automatically be processed and presented by a {{Wikidata infobox}} on Commons? A generic URL (P2699) perhaps, with qualifier object has role (P3831) = 'flickr tag' ? Isn't it rather tidier to have a specific property? Jheald (talk) 00:51, 23 July 2018 (UTC)[reply]
  - Maybe catalog (P972) and catalog code (P528)? − Pintoch (talk) 07:03, 23 July 2018 (UTC)[reply]
    - @Pintoch: The whole point would be to have a clickable link. catalog code (P528) doesn't take a url formatter. Jheald (talk) 15:38, 25 July 2018 (UTC)[reply]
  - What exactly do you want present on Commons? For bicycle (Q11442) I can easlily find 15 tags bicycle, bicycles Zweirad, bici, bike bicyclette, fahrrad, bicicleta, vélo, vèlos, velo, Velos, biciclettecycles, ποδήλατα, 自転車, الدراجاتвелосипеды. Do you want to show all these tags, only English tags or only tags which are heavily used? --Pasleim (talk) 09:05, 23 July 2018 (UTC)[reply]
    - @Pasleim: My particular interest in is the images in the flickr accounts of the British Library, the Biodiversity History Library, the Internet Archive, etc, where there is a 1:1 corresponding Commons category and Flickr tag for the book the image was scanned from.

So for example England Delineated (5th edition) (Q52230303) -> sysnum000033859.

There's scope for perhaps up to 100,000 such categories on Commons, maybe more. Jheald (talk) 09:39, 23 July 2018 (UTC)[reply]

Some background about the machine tags at https://www.flickr.com/groups/51035612836@N01/discuss/72157594497877875/ .

Not sure if we should even link to Flickr in the example. Shouldn't all these images just be on Commons? Multichill (talk) 11:21, 23 July 2018 (UTC)[reply]

@Multichill: 1. Stats: We currently have about 40,000 images on Commons from the BL scans, out of about 1 million on Flickr. For images scanned from Internet Archive books, we have about 480,000 images, out of about 5.25 million on Flickr. We have about about 250,000 images from the BHL, out of an unknown number, mostly linked directly to the BHL website, though copies may exist on Flickr via the IA.

The issue with these pix (and the reason for those counts) is that metadata for these images is generally very very weak, generally extending no further than title, author, publisher, and date of the book the image was extracted from -- ie most usually nothing about what might be actually depicted in the image. Also, many of the images frankly aren't very interesting or of very high quality. For that reason the Commons community originally outright vetoed a bulk upload of all the BL images; instead those that have been uploaded have been uploaded selectively, and hand-curated by editors as they went along. Regarding the IA images, Fae has systematically uploaded those above a certain size, and left the rest. So that's why, in both of these cases, there are a lot more images still on Flickr than those so far copied to Commons.

Should we copy over the rest, particularly in view of Flickr's recent change of ownership, previous precarious financial position, and the recent repositioning of some other image platforms to turn against Commons images? Perhaps, but in the case of both the IA and the BL, we know where these images came from, we are on good terms with the institutions, and we could almost certainly obtain the images on hard drives if anything calamitous did happen at Flickr. So there is probably no pressing reason to change existing Commons practice. (Though I do still hope to upload 50,000 of the BL images that depict maps, for which currently underway). But it would be useful to be able to systematically link to the corresponding image-sets on Flickr, from Commons categories for books, to see what other images may be available.

2. Machine tags. Is there a Dutch translation of the English Q7691305? Perhaps with a nice informative illustrative painting by Jan Steen (Q205863) ? :-)

Yes, I know what machine tags are. The metadata improvement project for the map images has even been systematically adding them. But there are a number of problems with them, the first being that they are hardly used, so Flickr doesn't really care about making sure that software updates don't break them. There are a number of ways of constructing Flickr URLs with them that one would feel ought to work, but then strangely don't. Even if a URL template can be made to work this year, that's no guarantee as to whether it would still work next year. In contrast the simpler regular tags tend to be more bulletproof. Also the machine tags and/or the searches for them munge spaces and punctuation in various ways, making it difficult to use many existing identifiers as machine tags.

But the real point is that, for what I really want, namely to return all the images from a particular book, the images already have tags for this, systematically added by the BL and the IA when the images were uploaded, so those are the tags I'm interested in. Nobody is going to take the time and bandwidth to add machine tags to 6.25 million images, simply to duplicate information that is already there. It's the current established regular tags for books and book-volumes from the BL and the IA that one would want to link to. Jheald (talk) 14:52, 23 July 2018 (UTC)[reply]

Support by analogy with other tag properties created and proposed, though it is very clearly evident that concerns about their creation overlap greatly at least when it comes to their datatype and their general worthiness of inclusion. On this former point, until we all agree to recast hashtag (P2572) as an external identifier, I support this property's creation as a string; on the worthiness of its inclusion, I sometimes wonder, given many of the examples presented here and elsewhere, whether a single unified 'tag' property is in order, seeing as most of them pertain to exactly the same topic whether viewed on Twitter, Instagram, Gfycat, or Flickr. Mahir256 (talk) 15:10, 23 July 2018 (UTC)[reply]
Support I'm a bit unsure: this is very similar to hashtag (P2572) but there are differences. Tags are no identifiers, so the datatype should be string, but tags serve a similar purpose like identifiers. Flickr tags were one of the first popular instances of folksonomy (Q494291), that's why I support this proposal. There are several more tagging applications, (e.g. see https://www.librarything.com/tag/archaeology) and we don't want properties for all of them but this must be decided case by case. -- JakobVoss (talk) 20:41, 15 August 2018 (UTC)[reply]

Benefit of the doubt, doesn't harm imo so:

Support I'm a mergist, but tendency in occasion as this include Klaas `Z4␟` V: 20:46, 15 August 2018 (UTC)[reply]
Support Cwf97 (talk) 15:57, 21 October 2018 (UTC)[reply]

Comment : following this discussion and others on similar property propositions, I went on on generalizing hashtag (P2572) has the platform-agnostic hashtag property. -- Maxlath (talk) 00:23, 12 December 2019 (UTC)[reply]