An editor has requested the community to provide input on "Image properties: many properties or many qualifiers" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you!
THIS RFC IS CLOSED. Please do NOT vote nor add comments.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
The problem is that we need an incredible amount of properties to deal with all the special images that we want to add to items. In my opinion it would be easier to deal with those cases with item-datatype qualifiers (mainly one qualifier). Our example would look like this:
Support per Tobias1984 Comment The title of this RfC should be many properties, or one property, one qualifier and many items :). TomT0m (talk) 16:45, 9 July 2013 (UTC)[reply]
Oppose I don't see a problem with using a qualifier for image roles that border on being captions, such as the bear examples. But with images that have a very distinct role in typical applications - i.e. flags, logos, and so on - I think there should be a separate property. As a rule of thumb: If it tends to have its own parameter in infoboxes today, that is a good indication that it is viewed as special enough to warrant its own property. --Tobias K. (talk) 21:14, 14 July 2013 (UTC)[reply]
In my still very basic understanding of semantic-web, it would increase our semantic approach to define all images with existing items, than to create hundreds of image properties that are not linked to any items (I don't think that property-item-links are a planned feature). "Depicts =" would be the equivalent of "subclass of"/"instance of" for images. I think Commons would have to start organizing their images like that too. It makes sense to repeat this at Wikidata because we are making a curated image choice instead of linking a category or a image search which both don't have good control over which images show up. (See plant cell example) --Tobias1984 (talk) 13:52, 15 July 2013 (UTC)[reply]
Your argument is valid from a semantics point of view, but the logical conclusion would be to delete almost all of your properties (e.g. such diverse properties as "founder", "headquarters location" and "industry" could all be replaced by a "related item" property with the appropriate term given as a qualifier). A minimalistic approach isn't always a good choice, though. Personally, I think Wikidata should not just try to achieve semantic perfection, that's more a long-term goal and could indeed be served by introducing property-item-links at some point in the future. Right now, we should also consider practical uses of the data and user interface concerns: Wikidata will catch on if it is reasonably easy to understand and use and serves practical needs. By allowing arbitrary terms as image qualifiers, a contributor would no longer get meaningful suggestions for properties, there would be a larger risk of inconsistent usage of terms - made worse by a lack of validation - and this in turn might lead to a less reliable coverage of image types that are actually useful for many applications. --Tobias K. (talk) 00:10, 26 July 2013 (UTC)[reply]
CommentChange from "image depicts" to "description", with multilingual datatype, and I would support this. This qualifier could then be used for other things besides images. Filceolaire (talk) 12:53, 23 July 2013 (UTC)Support this property with Item datatype. We should probably also have a property for the Caption/ALT text with multilingual datatype but thats a separate discussion. Filceolaire (talk) 20:59, 15 August 2013 (UTC)[reply]
Question How to use this approach in infoboxes? For example person infobox, what image it must use? Some cases: item contains one P18 value without qualifier (typical case currently); item contains two values with same qualifier; item contains one value with unexpected qualifier. — Ivan A. Krestinin (talk) 13:36, 3 August 2013 (UTC)[reply]
One of the tools the developers are due to develop is Ranking. This will mean that where a property has multiple values one of these can be marked as the preferred value. For images this would be the image suggested for the infobox. Filceolaire (talk) 20:59, 15 August 2013 (UTC)[reply]
Could you please give a link to the tool or description? P18 already massively used in infoboxes and we already have problems with multiple values and need solution. Another problem is images with unacceptable content for infoboxes. For example person item with image of his dog (and qualifier "dog" of cause), or some house photography and qualifier "place of birth". Both images are not acceptable for infoboxes, but I have no idea how to create algorithm that divide all possible qualifier values to accepted and rejected values. — Ivan A. Krestinin (talk) 03:47, 16 August 2013 (UTC)[reply]
Support the only working approach. otherwise infoboxes need to cope with an increasing number of properties instead of just picking the image with the expected qualifier or an arbitrary one. — Felix Reimann (talk) 22:00, 25 August 2013 (UTC)[reply]
Support as far as I understand this site here, images would get a media info which could be queried as well. So we should describe the picture directly in it's media info, instead on items which are using the picture. Just a link to the image is enough, all other information should be stored within the picture. --Nightwish62 (talk) 19:09, 9 July 2013 (UTC)[reply]
My worry with your suggestion is that it would be like a image-search instead of a curated image. A lot of images could potentially say "crew photo of mission 123", but by explicitly choosing one of the images to be the default, we are doing something more than a image search can do (See eye-catching example). --Tobias1984 (talk) 20:10, 9 July 2013 (UTC)[reply]
Comment Yeah, but the fact we link an image to an item already state that this picture is suitable to be used in wiki-articles. There is still no need to describe the content of the image on every item we're linking it again and again. We also can use rankings (later). --Nightwish62 (talk) 18:27, 10 July 2013 (UTC)[reply]
I think linking images to items would be a great way of expanding the ideas of semantic-web to pictures and Commons. If the link to the item should go with the image or the statement is probably another RfC with the Commons people included. --Tobias1984 (talk) 10:36, 12 July 2013 (UTC)[reply]
I linked to that RfC at the very top. I made this RfC because I think it is easier to discuss and vote on this limited subject matter. Thanks for participating by the way ;). --Tobias1984 (talk) 20:00, 9 July 2013 (UTC)[reply]
Images also have "Captions" and "ALT text". Should these be combined with "image depicts" in one property or should we have separate properties? Filceolaire (talk) 02:11, 27 July 2013 (UTC)[reply]
Is there a way to show, for example, historical logos or coat of arms (with time qualifiers), in the proposed solution? --Wylve (talk) 08:05, 11 July 2013 (UTC)[reply]
I don't think that historical imagery would need start time (P580) and end time (P582) because it doesn't "expire" like an old flag does for example. I would use point in time (P585) for those images if you want to highlight the time it represents. But if Commons will adapt Wikidata properties then point in time (P585) will be stored with the images anyway and we don't have to add it to the Wikidata-statement. If you want to choose a specific image of London during the industrial revolution it could look like this:
I would encourage editors interested in describing images on Wikidata to read Image Annotation on the Semantic Web, a report from the W3C Multimedia Semantics Incubator Group. That document discusses use cases and possible Semantic Web-based solutions for describing images related to cultural heritage, images from NASA, and biomedical images, among other things. Those use cases are all relevant to image annotation on Wikidata. Emw (talk) 02:27, 17 July 2013 (UTC)[reply]
Can you two please tell us how you think the reports you refer to apply to the particular case raised here. I have read these and it is not obvious to me. Remember that RFC's are for trying to arrive at a decision. Not for creating ever wider never ending discussions. Filceolaire (talk) 01:56, 23 July 2013 (UTC)[reply]
We should create a new item type F on wikidata for media files from commons and transfer all the semantic data from commons to wikidata, including adding these properties. That way the Image description would be attached to the image rather than having a different image description for each place the image is linked on wikidata. Filceolaire (talk) 10:57, 27 July 2013 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Support - I think this will be the most versatile solution. --Tobias1984 (talk) 12:54, 9 July 2013 (UTC)
Comment The title of this RfC should be many properties, or one property, one qualifier and many items :). TomT0m (talk) 16:45, 9 July 2013 (UTC)
Oppose This make image (P18) useless for infoboxes and another applications. Qualifier's value is not well defined. Many images have no qualifiers at all, what we will do with it? I think this way makes P18 equals to Commons category (P373). — Ivan A. Krestinin (talk) 04:42, 12 July 2013 (UTC)
Question How to use this approach in infoboxes? For example person infobox, what image it must use? Some cases: item contains one P18 value without qualifier (typical case currently); item contains two values with same qualifier; item contains one value with unexpected qualifier. — Ivan A. Krestinin (talk) 13:36, 3 August 2013 (UTC)
