Open main menu

Wikidata:Property proposal/Flickr tag

Flickr tagEdit

Originally proposed at Wikidata:Property proposal/Authority control

   Not done
DescriptionTag used on Flickr to indicate images relating to a particular item
Data typeExternal identifier
Template parameterTemplate:Flickr tag inline link (Q21619988)
Domainany
Allowed values[^\s\/]+
Example 1England Delineated (5th edition) (Q52230303) -> sysnum000033859
Example 2MISSING
Example 3MISSING
Sourcehttps://www.flickr.com
Planned useto 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 sourcePerhaps 100,000 for institutional projects, maybe more. But probably only a certain proportion of these would actually be added to items.
Expected completenessalways incomplete (Q21873886)
Formatter URLhttps://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)

Discussion

  • Proposed. Jheald (talk) 15:02, 18 May 2018 (UTC)
  •   Support David (talk) 16:38, 18 May 2018 (UTC)
  •   Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:21, 18 May 2018 (UTC)
  •   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)
    • @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)
    • 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)
      • @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)
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)
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)
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)
@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)
  •   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 Twitter 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)
  •   Support I'm a bit unsure: this is very similar to Twitter 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)
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)
  •   Support Cwf97 (talk) 15:57, 21 October 2018 (UTC)