Commons talk:Structured data/Get involved/Feedback requests/Properties for Commons

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Thank you for reading and participating, this has generated a lot of good information. Later this week I'm going to sit down with SandraF (WMF) and RIsler (WMF) to create the master template of existing and needed properties for Commons here in the Structured Data hub. Thanks again, your participation is invaluable. Keegan (WMF) (talk) 19:40, 14 August 2018 (UTC)[reply]

Example 1 - Photograph of an object[edit]

There are several more things to be said about this image:

  • setting=studio
  • lighting=artificial
  • subject-design:after=Riemerschmid
  • background-colour=white
  • depicts=fish
  • subject:maker=xxx
  • subject-design:copyright=xxx

Also, size=10cm is not helpful; is that height, width, diameter? And of what? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:27, 26 June 2018 (UTC)[reply]

One also somehow needs to segregate information about the photograph from information about the vase, given that the vase may well not have its own Wikidata item (or would it?) Jheald (talk) 21:27, 26 June 2018 (UTC)[reply]
Yes, and this is specially important about the copyright status, but also about other properties: author, date, etc. Yann (talk) 19:04, 28 June 2018 (UTC)[reply]
I too was going to mention the apparent inadequacy of the properties for copyright status of the photo vs the depicted items. For example, take the case of a photo that depicts a building facade that includes a sculpture. In this case we might want to indicate that the depicted building is still protected by the copyright of the architect, but we this is not an issue due to freedom of panorama in the country in question, the sculpture is PD because we know the author and they've been dead for more than 70 years, and the photo itself is protected by copyright but we've got an acceptable free license to the photo. —RP88 (talk) 19:27, 28 June 2018 (UTC)[reply]
This is an unnecessary mish mash. Final license of the photograph should be respected, Wikimedia Commons, does not host images which would break copyright terms. --Juandev (talk) 19:32, 28 June 2018 (UTC)[reply]
That is very strange remark — I strongly disagree. First, we have photos where the photo license is PD (perhaps as a work of a US government employee) but the depicted work is still protected by copyright, so the photo is a derivative work and as such we need a license from the author of the depicted work, so the "Final license of the photograph" would not be enough. Furthermore, your statement "Wikimedia Commons, does not host images which would break copyright terms" is not true. Commons strives to only host files that are free in the US and the country of origin, but does not make any claims about the status of the files is other countries. For example, we host works that are free in the US and the country of origin, but not free in countries that don't have the rule of shorter term. Our goal is to provide enough information that any potential reuser can determine if they can use one of our hosted images and Commons' current template system provides a mechanism for accurately reflecting the copyright status of such works. As an example, Commons hosts files that are free in the US and the source country of Argentina, but are not free in countries without the rule of the shorter term. I think the structured data property system we adopt should be flexible enough to do this as well. —RP88 (talk) 14:57, 29 June 2018 (UTC)[reply]
This vase - and most vases - may not have a Wikidata item; but some will. And for some, there will be an item for the design, or the range. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:43, 29 June 2018 (UTC)[reply]
@Pigsonthewing: This is also one of my question below about an ordinary, not notable engraving. Should it have a separate item in Wikidata? Vladimir Alexiev says below yes, we should. Then why shouldn't this vase have its own item? How is it different? Notability for Wikidata will become a major issue for SDC. There was also a discussion about an item for every photographer. I started a specific section below about this. Regards, Yann (talk) 11:52, 3 July 2018 (UTC)[reply]
@Yann: Could you link it?--Juandev (talk) 21:46, 7 July 2018 (UTC)[reply]
Somewhat related, if this object is old, the exact date it was created is probably unknown. I'd love for the date field on objects to allow for general dates (like "sometime in the 1880s" or "around 3rd century BC"). Rachel Helps (BYU) (talk) 17:59, 2 July 2018 (UTC)[reply]
@Rachel Helps (BYU): , we can do some very nuanced dates in Wikidata nowadays, using things we call "quailfiers". Combining a point in time of exact date, year, decade, or century with the qualifiers "sourcing circumstances", "refine date", and "nature of statement" we can say things like "circa middle of 2nd century" or "first quarter of 1897" or "earliest date 1563/latest date 1587" or "spring (northern hemisphere) 1758". - PKM (talk) 00:25, 6 July 2018 (UTC)[reply]
@PKM: oh, thank goodness. I've done some editing on Wikidata, but not with inexact dates, so I'm relieved to know this problem is already somewhat solved. Rachel Helps (BYU) (talk) 16:10, 6 July 2018 (UTC)[reply]
I want to second the importance of distinguishing between properties of the image and properties of the subject. Of the above, "depicts" should also be subject:depicts (the photo depicts a vase that depicts fish). But it is **much better** to make the subject as a separate entity, even if we know just a bit about it. Then we can manage its properties in a non-redundant way (imagine a series of 100 photos of the same subject), and can link/merge it to other entity descriptions, eg on Wikidata. --Vladimir Alexiev (talk) 09:58, 3 July 2018 (UTC)[reply]
I agree entirely that depicts should be “vase” and that the depicted things can have their own properties, in this case depicting a fish. It would be nice if we could have an “object identifier” for the depicted thing so it could be reused in multiple photos of the Sam subject, but even then there may be different sub-properties. What if there are fish on one side of the vase visible in one photo to and frogs on the other side visible in another photo? I think that perhaps it is a mistake to think of this Commons item as “photo of a depicted thing” rather than that it is thing with a depiction that is of type photo. After all on Commons we could host many photos of this vase, as well as an audio of a talk about the vase, as well as a PDF that discussed the vase and so on. So I think the subject should be at the top of the hierarchy of description ahead of the image. Obviously for practical purpose an upload wizard for a Commons item would automatically generate a new subject ID which could be changed by the uploader to refer to a pre-existing subject on Commons (or others later could do that based on the captioning or visual similarity etc). But it would be nice to have a “upload by subject” that let you upload a series of photos of the same subject. Kerry Raymond (talk) 11:37, 3 July 2018 (UTC)[reply]
It could be, but it complicate it pretty much so there will be the question about the complexity. So basically if we will leave the new uploader lost - i.e. it must know or search for property names, or if the Upload Wizzart will be requesting to fill some values.--Juandev (talk) 21:46, 7 July 2018 (UTC)[reply]

Blaue Rispe[edit]

What is Blaue Rispe as a quality? I thought the quality might be the quality of the image.--Juandev (talk) 19:28, 28 June 2018 (UTC)[reply]

Indeed, two things could be improved:
  • The verb should be something like "style" or https://www.wikidata.org/wiki/Property:P136
  • The subject is not the picture, it is the object depicted in the picture. For instance let's imagine the vase was on a Louis XV-style nightstand, then each of the depicted objects would need its own style. Having a data item for each sounds overkill, though, so maybe with qualifiers?
Syced (talk) 05:26, 29 June 2018 (UTC)[reply]
@SandraF (WMF): do you have thoughts here, as you might be more familiar? Keegan (WMF) (talk) 21:10, 2 July 2018 (UTC)[reply]
Hmm. I'm not extremely familiar with how decorations of objects are usually described by GLAMs. Blaue Rispe seems to be a (notable) pattern/motif and, as such, has its own Wikidata item. We will have more of these (example: Boerenbont (d) - many textiles also have notable types of patterns). This is not the same as a style or genre, IMHO. I think a specific Pattern/Motif property sounds useful to have? SandraF (WMF) (talk) 08:23, 3 July 2018 (UTC)[reply]
@SandraF (WMF) and Keegan (WMF): These are currently pattern and motif, though I have struggled with whether this sense of "pattern" needs its own separate item. I've done some work in this area, and now that we have the new property has decorative pattern, I'll be doing more. - PKM (talk) 00:56, 6 July 2018 (UTC)[reply]
And I have absolutely decided that this sense of pattern (a design element) needs to be broken out into a new item. I was waiting on further feedback on my question about where "physical attributes" should sit in our ontology, but it seems to have aged off of Project Chat without further feedback. I'll do something with this soon. - PKM (talk) 23:35, 6 July 2018 (UTC)[reply]
✓ Done @SandraF (WMF), Keegan (WMF), Johnbod, and Jheald: New Wikidata item Pattern defined as "ornamental design applied to or incorporated in the surface of an object, generally consisting of repeated motifs or elements", equivalent to AAT 300010108. This is subclass of Design element, also new, and of the existing main item d:Q2083958 Pattern "discernible regularity in the world or in a manmade design". The decorative patterns I found in WD under "pattern (regularity)" have been moved to be subclasses of "pattern (design element)", referencing AAT. There is still much work to be on adding (or finding) items and adding translations, but the structure is there now. - PKM (talk) 21:06, 7 July 2018 (UTC)[reply]
That sounds more like a "motif", or set of them. We probably need that, but it would cover objects hand-made by different people potentially thousands of miles and hundreds of years apart. A "pattern" in modern ceramics means a scheme of decoration repeated over multiple pieces in different shapes, to make a matching set or service, usually by a single factory, but sometimes (Willow pattern) by many factories. If WD is anything like WP, ornament is a very weak area. Johnbod (talk) 21:28, 7 July 2018 (UTC)[reply]
AAT doesn't make that distinction, or not that I can see. You're right, their "pattern (design)" is made up of "motifs", and they have willow pattern as one of their "patterns". This is likely a place where WD needs to deviate from AAT (there are many), and add a concept "ceramics pattern" (though there are similar patterns for silverware as well...maybe it's yet another thing called "pattern"?). Open to suggestions and especially to an online source to use to reference this stuff... And yes, it's a very weak area, primarily I think because the initial buildout is based on WP articles. - PKM (talk) 01:45, 8 July 2018 (UTC)[reply]
@Johnbod: WD now has d:Q55425193 Ceramics pattern. For the purposes of this discussion, the property d:P5422 has decorative pattern should cover all these types of patterns and motifs, however they ultimately are organized.- PKM (talk) 19:48, 8 July 2018 (UTC)[reply]
It's described on WD as "art movement" but I agree it's more accurate to call it style, pattern, or motif. More importantly, it's not the style of the photo but of the depicted subject! It's very important to distinguish between properties of the image and properties of the subject(s). Otherwise we'll get a mishmash that it will be impossible to manage --Vladimir Alexiev (talk)
  • The simplest and most normal statement to describe the object in the photo is that it is a piece of "Meissen porcelain", yet neither word has yet entered the discussion that I can see. This enterprise seems likely to end in disaster, as, like Wikidata, the importance of not having developed a proper vocabulary before starting has not been realized. You can't do that successfully as you go along. For GLAM objects it might be best to borrow one of the vocabularies that GLAM institutions have spent years developing, if you can. Johnbod (talk) 15:11, 3 July 2018 (UTC)[reply]
Yes, we should be able to add the properties manufacturer = "Meissen porcelain", material used = "hard paste porcelain", and fabrication method for specific processes, techniques, weaves, and so on. - PKM (talk) 00:49, 6 July 2018 (UTC)[reply]
  • "Style https://www.wikidata.org/wiki/Q55255109 (Blaue Rispe)" - "Style" is wrong here - I don't know quite how you'd describe the style here, but let's say it was Art Nouveau/Jugendstil - Blaue Rispe is a "pattern" in ceramics - a specific pretty-clearly defined thing, and I think you need a field for that, and not to go messing up that field with things that aren't "styles" at all. If WD calls Blaue Rispe an "art movement" that exemplifies the mess you get into not thinking things through properly before you start. Actually Q8022389 shows there are properties for this, and some WD vandalism! Johnbod (talk) 15:26, 5 July 2018 (UTC)[reply]
Thanks for fixing that vandalism! As of just a few days ago, we have a new Wikidata property has decorative pattern (AKA has pattern, has motif), which would be great for this. - PKM (talk) 00:05, 6 July 2018 (UTC)[reply]
  • The Getty Art & Architecture Thesaurus “Styles & Periods” hierarchy would seem like a reasonable model to adopt, but I haven’t seen any traction with that effort in Wikidata. Perhaps that’s because “style” and “period” seem like two different concepts; perhaps simply because no one there is passionate about it. I could be probably get passionate about it if another editor or two wants to work in this area, since I will have pretty much beaten textiles to death in another few weeks. - PKM (talk) 21:01, 5 July 2018 (UTC)[reply]
That's a good and obvious suggestion, but will require editors with the appropriate expertise, as most files won't carry the information (or the right information). I'm afraid I very much don't want to do anty donkey work on this, but am happy to comment on pages like this. Johnbod (talk) 23:51, 5 July 2018 (UTC)[reply]
I note that Wikidata does have era which is likely where AAT's "periods" are probably mapped, to the extent that they exist. I haven't really dived into this yet.- PKM (talk) 00:09, 6 July 2018 (UTC)[reply]

Example 2 - Animal & plant[edit]

Exif[edit]

  • I see in the second example, at the end of the table "(other EXIF metadata)" if that means a possibility to add properties for all the settings, then I agree. Especially for the following infos
Property (English label) (+ optional Wikidata Property ID) Value that you would want for item
EXIF Camera manufacturer Sony
EXIF Camera model ILCA-77M2
EXIF Exposure time 1/250 sec (0.004)
EXIF F-number f/14
EXIF ISO speed rating 320
EXIF Date of data generation 5 May 2017

Christian Ferrer (talk) 19:54, 28 June 2018 (UTC)[reply]

  • Is this a shortened version exhaustive list of EXIF information? Do we really need to show the complete version? John Samuel (talk) 18:55, 29 June 2018 (UTC)[reply]
    Maybe not the complete version, but some information are important; e.g. the camera model, the lens mounted, the unique number of the photo, the one for the camera, EXIF date. --Ruthven (msg) 09:04, 30 June 2018 (UTC)[reply]
    For the persons interested in photography, to have properties for the settings mentioned above may be a possibility to make queries, example "all the macro images taken by a Sony ILCA-77M2", "all insect photos taken below 800 ISO" ect, ect... But our category tree talk by itself and in many cases, including for long time exposure of specific subjects (waterfalls, ect, ect...), ect, ect... The interest of a date property generated from the EXIFs (when they exist) is obvious, as evidence see Category:Photographs by day and all the child categories that could be replaced by simple queries. Same thing for this kind of categories where the useful date in the EXIFs can be used as a property to generate useful queries instead of our laborious category tree. Christian Ferrer (talk) 17:23, 30 June 2018 (UTC)[reply]

This shouldn't be at the description, at the bottom as it is right now is enough. What can happen is associate the bottom items to entries. Moreover, this data, especially at the digital, are imprecise. We can have HDRs, bracketings, merges... that will not correspond to reality, even a small change at LR could change the precision of the Metadata. -- Rodrigo Tetsuo Argenton m 22:12, 3 July 2018 (UTC)[reply]

@Christian Ferrer: I agree, available exif data, including file type can be automatically load to image item. They are very userfull and important in searching images. But than we can deside, where, how and how many of them will be displeyed in the image page on Commons. One posibility is to have more styles, with drop down menues.--Juandev (talk) 22:02, 7 July 2018 (UTC)[reply]

More data[edit]

File:Indosylvirana_urbis-Kadavoor-2017-05-05-001.jpg
Property (English label) (+ optional Wikidata Property ID) Value that you would want for item
Type of media file Photograph
Photographer Jeevan Jose
Depicts (P180) Indosylvirana urbis (more photos:Indosylvirana urbis)

Curcuma angustifolia (more photo:Curcuma angustifolia)

Main subject info
Wikidata information
Indosylvirana urbis [1]
Frequency location at Commons [2] [1]
Size xxx cm
Weight xxx kg
parent taxon Indosylvirana
produced sound File:Sample.ogv
...
Information about the main subject in this photo [3]
Number of individuals 1
Sex of individuals Male (Female, Male, Both, not identify, not applicable)
habit represented normal behaviour (eating habits, mating habits, breeding...)
life phase adult (larval, elder, old individual...)
...
Photo location

(Kadavoor, Kerala, India)

Map

Camera location 10° 00′ 10.73″ N, 76° 44′ 00.52″ E
Quality assessment Featured picture
Copyright status In copyright
Licensing CC BY-SA 4.0
  • [1]It will be nice to mirror the wikidata info available as "institution" or "creator" nowadays.
  • [2]I've being in a scientific event about scientific vulgarization, and they used a lot the register of birds as a scientific data, they didn't use our data, because we are behind on this, but WikiAves have a better job, and more volunteers to register birds. Creating this frequency map: [2], I don't know how to embedded this here, but this could have a create impact as a educational tool some birds already have a okay volume as [3].
  • [3]Having the same purpose as before, we should have a better description to create more educational data, more qualifiers to be easier to read, find, and count.

I'm not a researcher, but I can contact and create a better list, also to Wikidata. I know this ones are important, that's why I put it. -- Rodrigo Tetsuo Argenton m 23:29, 3 July 2018 (UTC)[reply]

Depicts what?[edit]

Contrary to the description, it is well understood that taxon (Q16521) does not correspond to a taxon (a kind of organism or group of organisms), but to a taxon name. Many taxa are represented in Wikidata by multiple taxon names. So it is wrong to use depicts (P180). Peter coxhead (talk) 16:27, 5 July 2018 (UTC)[reply]

@Peter coxhead: Do you have a better solution? --Njardarlogar (talk) 08:39, 6 July 2018 (UTC)[reply]
I think this is a very important point. Wikidata badly needs a main item for each organism/taxon, but often one organism has multiple scientific names (synonyms) which each have their own items. Logically from a data modelling point of view we should have one item which means the organism, and that should be linked to multiple items, one for each scientific name (only containing properties relevant to that name, such as the author information). But I think that is too confusing and impractical, since it means every organism has to have at least two items. So I propose that one scientific name, the "Wikidata name", should be selected (at random) from the important names, there should be one main item for the organism, the "taxon item", which should contain the organism properties plus the properties of the "Wikidata name", and multiple "synonym items" (with only name properties) for the remaining names. It would be recognized that the real current name may be one of the synonym items and the competing claims could be recorded in the properties linking the taxon item with the synonym item. Then I think depicts (P180) could point to the taxon item. Unfortunately one name has to be selected, but it is better to recognize this and to emphasize that it is not necessarily the true name. I proposed this in more detail in this discussion of P1420. At present in my experience the Commons solution is to choose one name (generally a recent one) for all information on an organism, mention other important synonyms in the text with a template, and for the pages of the other important synonyms just make redirects . Strobilomyces (talk) 13:09, 7 July 2018 (UTC)[reply]
Note that there is normally, in my understanding, no matter if you chose a synonym, and not the current name, in Wikidata, in the extend that of course the items are connected via taxon synonym (P1420) and synonym (Q1040689). Example, no matter if you chose "depict" Nivatogastrium nubigenum (Q10601382) or "depict" Pholiota nubigena (Q53857309). Well I think. Christian Ferrer (talk) 13:38, 7 July 2018 (UTC)[reply]
In addition to taxon synonym (P1420), property subject has role (P2868) with qualifier of (P642) is wanted. Through those links it should be possible to find all the information, yes. But it is unlikely that the relevant software will do this. Here we are talking about organisms which need to be identified by their scientific names. The main relevant case at present is that of the interwiki links; the software will not trace through the links mentioned, so if the wikipedias in question use different scientific names in WD, the relevant wikipedia articles will not all be linked together. This is really a critical failure of the system. The Vernacular Names template ({{VN}}) is another example. Organism-dependent information is liable to be duplicated amongst the items with different names. There are many reasons why we need a special unique item for each organism. Strobilomyces (talk) 18:19, 7 July 2018 (UTC)[reply]
A software is usually doing what we said him to do, if at least one says something to that software. You're right that currently the software don't trace the links via taxon synonym (P1420), my example above is even a good example of that... Christian Ferrer (talk) 20:22, 7 July 2018 (UTC)[reply]
Here I might not understand Wikidata pretty well, but I was having a trouble to display items of plants, because all items of plants has the value of the property "taxon" instead of just plant. Then if you have a taxa name its way long to Plantae kingdom through the taxa system. --Juandev (talk) 22:22, 7 July 2018 (UTC)[reply]
@Christian Ferrer: Software developpers make a lot of decisions about exactly how to implement a given feature and in a complicated case like the present one they will probably not do what we want unless there is an agreed specification which defines it clearly. Use of property taxon synonym (P1420) is mentioned in the Wikidata taxonomy tutorial, but this is not definite enough, detailed enough or well-publicized enough to really be taken into account. For instance I think the developper has a right to expect that the synonym pointer would go in both directions, but it is not clear how that should be implemented. We could write a detailed specification of exactly what the wikilink software should do to trace these links, get some sort of agreement, update the taxonomy WD properties accordingly, and ask for the software to be updated. But I am not sure that that would be agreed as it is something very specific for taxonomy, and there is an alternative solution by selecting one of each set of homotypic synonyms as special (to represent the organism and provide an item for the wikilinks). Strobilomyces (talk) 12:33, 8 July 2018 (UTC)[reply]

Specific properties[edit]

Wikimedia Commons files tend to have a lot more varieties than other projects because it's easier to create content here, maybe properties around license types and sources would be good start. On Wikidata as far as I know you currently can't add different license type per instance which is something that is essential for Wikimedia Commons. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:31, 28 June 2018 (UTC)[reply]

Note, it's also best to keep these properties machine-readable based on the simple fact that if you would concern yourself with the individual subject(s) of the files on Wikimedia Commons that you'll be creating more properties than there probably are instances now, the variety is simply too complex for most current bots (although once the software gets more sophisticated I would support mapping every little detail), it's best to focus on machine-readable data such as EXIF data, maybe even dates (days, months, years, centuries, Etc.) and "created on" and "uploaded on" should be different, as long as machines can read them and add them they could add more structure. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:35, 28 June 2018 (UTC)[reply]

Keep the number of properties and generic information stored here low[edit]

From my perspective, 'depicts' is the really important one - if that's linked to a Wikidata item about the specific object shown in the photo, then we should just use the info from Wikidata, rather than encouraging people to add that info again here. If it's notable but not yet on Wikidata, then we should encourage people to add it to Wikidata rather than just adding the info here. Other values can be deduced from other properties - e.g. if you have 'coordinate location', then you can probably get the 'photo location' automatically - or at least follow through from 'Kadavoor' to get 'Kerala, India'.

So properties here should focus mostly on the metadata for the media and the licensing. I guess most of those actually want to be uneditable after upload/extraction from exif - things like the fstop shouldn't generally need to be altered. Thanks. Mike Peel (talk) 23:39, 28 June 2018 (UTC)[reply]

Fully agree with you. SDC should present a user-friendly UI for recording image data and recording (or selecting) depicted-object data, but should not mix up the two kinds of data in one place. Else we'll create a mish-mash that we cannot get out of. Just think of these situations:

  • Series of 100 photos of the same art object (eg various racourses of a golden treasure)
  • Photo depicting art object on top of another art object
  • Photo depicting art object that depicts definable subjects, which may be complex (eg persons or other art objects)

--Vladimir Alexiev (talk) 10:35, 3 July 2018 (UTC)[reply]

I totally agree that information about objects should be pulled from Wikidata wherever possible, but I assume that the appropriate properties must first exist in SDC so that the fields can be populated. @SandraF (WMF) and Keegan (WMF): Is my understanding correct here, or is there some other way to share data from Wikidata on the fly without first building out a specific structure to house that data? - PKM (talk) 18:37, 7 July 2018 (UTC)[reply]
And I am not sure, weather we dont have here kind of semi-properties, which are somewhere between those, which describe the image and metadata. Here I mean properties like Object color (predominant color of the depicted main object - we have here such categories as category:Yellow gates). Is this a description property or metadata property?--Juandev (talk) 22:30, 7 July 2018 (UTC)[reply]

Derived from[edit]

Often works are derived from other works. Somebody draws SVG diagram1. Somebody else uses the diagram to make SVG diagram2. The second should point back to the first.

A more specific property might be translation-of. User:LadyofHats draws a diagram of the body with labels in English. Sergei makes a derivative work by translating the labels to Russian. Glrx (talk) 03:10, 29 June 2018 (UTC)[reply]

Several people and dates for one file[edit]

Hi, I added 2 examples (#5 & #6) where there are several people and dates associated with each file. Each of these people has a specific role which should be documented. Same for the date: art work creation, picture creation, picture publication, upload, etc. Example #7 has also 3 dates, and 3 associated people (plus the institution which scanned the picture). Regards, Yann (talk) 15:52, 29 June 2018 (UTC)[reply]

  • The several people issue gets into some problems that don't seem to be well settled.
An instrumental music piece such as Classical Gas (Q489275) should always have a composer (P86).
A song (Q7366) should have both a composer (P86) and lyrics by (P676).
Consequently, Sunrise, Sunset (Q18164140) has both. All well and good.
There's also a set notation issue.
John Lennon (Q1203) and Paul McCartney (Q2599) had a contract where they would be joint authors.
We cannot have two independent composers of a single piece of music. In other words, we don't want
  • . P86 Q1203
  • . P86 Q2599
but rather something more like
  • . P86 {rdf:Bag Q1203 Q2599}
The Beatles songs are currently a mix of two. Some make independent statements, and others reference Lennon–McCartney (Q239177). 
  • SELECT ?song ?songLabel ?composer ?composerLabel ?lyricistLabel
WHERE
{
  ?song wdt:P31/wdt:P279* wd:Q7366 .
  ?song wdt:P175 wd:Q1299 .
  
  OPTIONAL { ?song wdt:P86 ?composer . }
  OPTIONAL { ?song wdt:P676 ?lyricist . }
  
  SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
ORDER BY ?song
    try it
There are also contributors.... The LoC has a huge vocabulary.
To add more issues, there may be dcterms:Agent wrappers.
Glrx (talk) 00:00, 30 June 2018 (UTC)[reply]
  • Hi @Yann: , thanks for the useful examples! For Example 6, I think it's mandatory to make an item for the drawing. "Do we need an item for this particular work of art (absolutely not notable)": yes we do, if we bothered to have a picture of it! This will allow us to describe the info where it belongs, rather than at a related object. You could have a photo of an art object sitting on top of another art object, both of them depicting other cultural objects: what do you do then?? --Vladimir Alexiev (talk) 10:30, 3 July 2018 (UTC)[reply]
Great examples. Now I am starting to understand a multiple license problem, which I was not taking before. But my question here is (as I dont understand your code), why we cannot have properties with more values. I can see its possible, at least an item on wd can have more images in it as values of a property image.--Juandev (talk) 22:37, 7 July 2018 (UTC)[reply]

Property and qualifiers for relations between objects[edit]

In talk with Lars Kai Hansen, we envisioned the possibility of having the means to describe relationships between depicted objects. For instance, "the photo shows a frog sitting on a plant" or "the photo shows a scale model in front of the astronauts." and "the scale model is on the table". This is not quite clear how we can do that with the Wikidata model. I suppose we can invoke qualifiers, but it is not optimal to describe the set of relationships and the connections to the objects they have.

Here is a partial example of the photo on the left:

File:Portrait of ASTP crews - restoration.jpg (Wikidata item page)

P180 Q42948 (ordinary property with a value)
P<behind> Q42537 (qualifier)
P<behind> Q154269 (another qualifier)
P180 Q154269
P<behind> Q432752
P180 Q432752
P<in front of> Q165230
P<behind> Q14748
P<left of> Q14748

It does not seem that pretty, but I am not sure what else we can do if we want to model such relationships? — Fnielsen (talk) 19:25, 29 June 2018 (UTC)[reply]

Hi, And how this information can be included into SDC? I can't imagine reviewing 40+ millions files by hand, and it needs a very smart image analysis system to do automatically... Regards, Yann (talk) 20:06, 29 June 2018 (UTC)[reply]
Am I missing something? Why would all 40+ millions files have to be reviewed? The wiki way is that contributors add information where they find it pertinent.--Anders Feder (talk) 23:16, 2 July 2018 (UTC)[reply]
@Fnielsen and Anders Feder: We already have difficulties adding categories for the inflow of files (see Category:Media needing categories, with 1,000,000 files waiting), so how do expect people to do this additional work? Regards, Yann (talk) 10:56, 3 July 2018 (UTC)[reply]
In the same way that all other work is done on Wikimedia projects. On a voluntary basis. Just like any of the other properties on this page. If you want something done that isn't on a voluntary basis, it is outside the scope of Wikimedia's projects.--Anders Feder (talk) 17:17, 3 July 2018 (UTC)[reply]
I'm not sure of the goal here. Is it identification or search?
Once somebody is looking at an image, then they can see the frog and the plant and figure out which one is which. If there is a picture of 3 people, then somebody viewing the image may not know which person goes with which name. There should be some information that identifies the people (or other similar objects). That identification can be local to the image. It would be nice if we say FDR is on the left, Churchill is in the center, and Stalin is on the right in a language-independent way.
Or is the goal about searching? Do you want to find only pictures of frogs sitting on a lily pad? Only images of astronauts sitting on chairs behind a model of a rocket that is sitting on a table?
Glrx (talk) 19:18, 2 July 2018 (UTC)[reply]
@Glrx and Vladimir Alexiev: Such data allows for better automatically generated captions, e.g. for automatic use of images in infoboxes on Wikipedia. The reader might see that it is a frog sitting on a plant, but they might not see that it is a Indosylvirana urbis (Q41581260) sitting on a Curcuma angustifolia (Q3596013); which is a caption that you should be able to generate automatically with this kind of structured information. --Njardarlogar (talk) 10:34, 4 July 2018 (UTC)[reply]
  • Let me give some context: Modeling the relationship between images and text is an active research field. Researchers employ deep learning technology both for images and text. One central dataset is the COCO at http://cocodataset.org that has more than 200K labeled images. An example labeling may be "a motorcycle parked on a sidewalk with a dog standing on the seat." [4]. With SDC we would have the opportunity to create an explicit semantic description of the components in an image. I do not expect such labeling to be completed on all millions of Wikimedia Commons files, but I think it could be valuable in machine learning. — Fnielsen (talk) 11:35, 3 July 2018 (UTC)[reply]
I agree, capturing this information is absolutely valuable. There is nothing "contrived" about it at all. The application is more well-defined than most Wikidata properties. But I also agree with you that the Wikibase data model doesn't really lend itself well to it. Another option would be some kind of free-form RDF representation, maybe using Mediawiki templates, but that would require some development beyond the scope of this discussion.--Anders Feder (talk) 17:25, 3 July 2018 (UTC)[reply]
I think there are probably limits to this. We are not just considering photos but anything type of media that can be uploaded. It might be two astronauts left and right in a photo, but it might be the same two astronauts in a PDF of a PPT presentation in which one astronaut1 is discussed on slide 4 and both astronauts are discussed on slide 8. Or we might have an audio file of the two astronauts speaking which different time periods associated with each astronaut as well as times when they spoke at the same time. I think it’s one thing to identify the two astronauts but much more of a challenge to position them in a photo, an audio etc. this might be something that we leave as a free text note field initially and perhaps refine later for specific media types. Kerry Raymond (talk) 11:48, 3 July 2018 (UTC)[reply]
  • Hi everyone. The Structured Data team is actually working on this problem now. We'll be making use of the existing "applies to part" qualifier for depicts (this qualifier uses standard Q items as its value, like "foreground", "background", etc). You can see how it works on Wikidata on the Mona Lisa Q item. We will have the ability for users to add this metadata during and after the upload process, and you'll also be able to use it as a parameter in search. We'll have prototypes illustrating this functionality in early August. RIsler (WMF) (talk) 18:20, 3 July 2018 (UTC)[reply]
And one point from non-English native speaker. The goal of this is also to make Commons accessible to those, who have difficulties with English. So I have to state that if you want to regenerate some phrase like relation, that "frog is sitting on the plant", it may be way to difficult to do it in other languages due to the different language structure. In this case talking about my mother tongue - Czech (Slavic family) we does not relate preposition to verbs to form a gramatical case, but we use suffix to nouns and other words. But they might be 24 different suffixes and the use of suffix is influenced by lots of gramatical rules, so you cannot translate from English so easily as to Spanish (frog is sitting on the plant -> la rana está sientado en la planta - > žába sedí na kytce), while infinitive forms for this case are frog, plant, rana, planta, žába and kytka and here it comes that change from kytka to kytce, which is not just a suffix, but whole change of the word.--Juandev (talk) 00:08, 8 July 2018 (UTC)[reply]

How do "Properties for Commons" differ from Wikidata properties?[edit]

I always assumed that Commons will share Wikidata properties. I have hard time imagining properties that will be used only on Commons and never on Wikidata. Even photograph specific metadata (shutter speed, ISO value, aperture) could be used on famous photographs that are on Wikidata. That is why I do not like the title "Properties for Commons" as I think we should just use Wikidata properties, and only add commons properties in case we find properties that will somehow only apply to Commons, but even for those I think we should not have different Wikidata property with the same number. --Jarekt (talk) 00:54, 30 June 2018 (UTC)[reply]

+1 I too have trouble integrating this difference. Christian Ferrer (talk) 18:29, 30 June 2018 (UTC)[reply]
Maybe one set of properties we should take a lead on would be license related properties. So per this discussion we might need properties like: justification, license URL, copyright status, etc. which are missing on Wikidata.--Jarekt (talk) 01:36, 30 June 2018 (UTC)[reply]
Since it doesn't seem like a lot of properties, I would suggest creating them on Wikidata and setting the scope to Commons items using d:Property:P5314.--Micru (talk) 18:15, 30 June 2018 (UTC)[reply]
d:Property:P5314 (property scope) is not for that, it's to state whether a prop is used in a claim, reference or qualifier. But surely we can add another one to say which WM projects use the property. Hopefully depicted subjects/objects will always be described in WD, and we won't need special "property profiles" for them. --Vladimir Alexiev (talk) 10:17, 3 July 2018 (UTC)[reply]
True, maybe it could be done with d:Property:P2302 and then as value "allowed Wikimedia project constraint" with qualifier "item of property constraint"->"Wikimedia Commons". Or maybe there are better solutions, what matters is that even if some properties are only Commons specific we could have a way to have them only in Wikidata and signal that they are for Commons use.--Micru (talk) 15:15, 3 July 2018 (UTC)[reply]
@Jarekt: In theory all the properties needed would not be only Commons-specific; there may be instances where right now the only use-cases are for Commons. I can see how the naming of this workshop might be confusing, but please do continue to think of it how you are, as that sounds right to me.
In any case, I do like your idea about splitting things up into classes of properties, if that helps. You can either do so here for your thoughts as the examples you give illustrate, or you can edit the workshop page directly if that would help everyone. Keegan (WMF) (talk) 21:08, 2 July 2018 (UTC)[reply]
Otherwise, I should add, I'll try to figure out a way to work it in. Examples would be good, so if they can be provided here we can turn it into something for the main text. Keegan (WMF) (talk) 21:19, 2 July 2018 (UTC)[reply]
I think the reuse of object/subject identifiers from Wikidata is good idea where possible. It would be ideal to use them to aggregate all articles and all media about that thing (and anything else in the sister projects such as Wikisource and Wikivoyage etc). I am not sure whether we would want to reuse properties from Wikidata or not. I think the properties in Wikidata are about connecting between things and factual values (eg population of a city) and are not generally the properties of depictions of the thing. The famous Fish Vase might have a Wikidata identifier which might indicate via a property that it is held in a particular museum and perhaps that it is from 5BC. But the image depicts the handle of vase on 3 July 2018. So I think depictions have their own properties. Eg a photo of two astronauts can identify via Wikidata the two people, and via Wikidata we might know they were crew of the STS-135 mission. However the person who uploads their photo of the two astronauts may or may not know this connection, to them the photo is of the two people who handed out prizes at their school graduation (properties unlikely to exist in Wikidata). Kerry Raymond (talk) 12:06, 3 July 2018 (UTC)[reply]
@Kerry Raymond: It is worth distinguishing statements from properties. Depictions may well have their own statements (distinct from statements about objects), but the plan is for such statements to be written in a language of properties and values that would be shared with Wikidata. Although, of course, there may be some of these properties that might only have relevance on Commons. Jheald (talk) 22:42, 8 July 2018 (UTC)[reply]

If you compare my suggestion at "animal", I believe that will be more clear, some entries should help us describe the photo, and this will not be used at Wikidata. For example, how many animals are in the photo, this could be used to create a record of registers, important for researchers, but we can use all information of the animal already available at WData... At the object example, the colour of the background, the same case. -- Rodrigo Tetsuo Argenton m 23:34, 3 July 2018 (UTC)[reply]

@Christian Ferrer, Jarekt, Micru, Keegan (WMF), Kerry Raymond, and Rodrigo.Argenton: There is an item Wikidata property to describe media items (Q28464773) that is the class of properties that describe media items: e.g., depicts (P180), copyright license (P275). These properties are used when the Wikidata item itself is the media item, such as a Wikidata item for a painting. There is also an item Wikidata property to link to Commons (Q18610173) that is the class of properties that link to Commons items: e.g., video (P10), image (P18). For instance, the item for Barack Obama points to an image of him. I suppose image (P18) (and similar properties) might even be the inverse of depicts (P180). I too believe that we should reuse properties across Wikidata whenever possible, including across all Wikimedia projects it supports. Runner1928 (talk) 21:24, 6 July 2018 (UTC)[reply]


Who owns the property creation process?[edit]

A quite important consideration to think about is which community would have final right of approval (or veto) on new properties and their proposed syntax.

If the language of Structured Data statements will be Wikidata properties and values, does that mean that the venue for nomination and discussion on new property proposals will be on Wikidata, with Wikidata admins having the final call on whether consensus is sufficient to go ahead ?

Or should there be a co-equal venue on Commons? But then could the Commons community mint new properties, that would then be also usable on Wikidata, either against or without considering the views of the Wikidata community? Jheald (talk) 22:49, 8 July 2018 (UTC)[reply]

Right now the property creation process will take place on Wikidata, and that does mean that Wikidata property creators will have the responsibility. I am aware that there is theoretical basis for conflict over this, it's been the heart of many discussion (including most face-to-face ones I had at the Wikimedia Hackathon and will have at Wikimania). However, conversations with people who are property creators and those who participate in the process have assurances that they do not see problems actually occurring in practice. If a property is needed for mapping file information on Commons, there should be a place for it within Wikidata's data model. @Pigsonthewing: you mentioned being a property creator on Wikidata, do you have anything to add here? Keegan (WMF) (talk) 16:28, 9 July 2018 (UTC)[reply]
Not a property creator (which is a technical role), but very active in property creation discussions. Most such proposals go through 'on the nod', and of those that don't even fewer are contentious. If anything the weakness of the process is lack of wider community input, so more people coming to that will help. It's in Wikidata's interest to keep the data model(s) sound; but not to discourage use on sister projects - there have been no issue making new properties for Wikitionary's purposes, for example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:56, 9 July 2018 (UTC)[reply]
 Comment Actually this is worrying me. As this shows, very few participate in this process, so a few people can block the whole process. This property should have been created long ago, and I don't see the reason for opposing as valid. Regards, Yann (talk) 11:01, 26 July 2018 (UTC)[reply]

Position of the camera, position of the object[edit]

Mouille Point and Robben Island from Table Mountain

When shooting a distant object, it is possible to localise both the object and the camera (see the example photo). In panoramas, categories often reflect the position of the camera (e.g. Category:Remote views of Vesuvius has sub-categories Vesuvius from Naples (W)‎, Vesuvius from the sea‎, Vesuvius from Sorrento peninsula (S)‎, Vesuvius from E‎, Vesuvius from N‎, Vesuvius from SE‎, Vesuvius from SW‎). There is a property for the position of the viewer? --Ruthven (msg) 09:01, 30 June 2018 (UTC)[reply]

Consider dividing the statements by level[edit]

On Wikidata items the statements are divided under two different headings "Statements" and "Identifiers", on properties those headings are "Data type", "Statements" and "Constraints". Perhaps Commons would benefit by having other headings based on the information level. For instance on images it might be useful to have "Depicts", "Image", and "Camera". Other digital objects, like books, might have other headings. What do you think? --Micru (talk) 18:52, 30 June 2018 (UTC)[reply]

Books[edit]

Draft for books. We can still add more, but I could not find a "best example" work, so added extras.

Discursos y Conferencias - Miguel Cané
Property (English label) (+ optional Wikidata Property ID) Value that you would want for item
Type of media file Version (or book?)
Author Miguel Cané
Title Discursos y Conferencias
Subtitle Something
Author of foreword Roberto Payró
Translator Someone
Illustrator Someone
Place of publication Buenos Aires
Publication date 1919
Printed by Casa Vaccaro
Language of work or name Spanish
Publisher Someone
Source A library
License PD-old-70-1923
Uploader Mauricio V. Genta
Date of upload 02 July 2018

--Mauricio V. Genta (talk) 23:37, 2 July 2018 (UTC)[reply]

I believe that the bibliographic metadata related to the book edition should be in Wikidata that have edition items. We would get something like: Tpt (talk) 08:58, 3 July 2018 (UTC)[reply]
Discursos y Conferencias - Miguel Cané
Property (English label) (+ optional Wikidata Property ID) Value that you would want for item
Type of media file book item scan?
scan of edition Discursos y Conferencias - Miguel Cané, 1919 (d:Q55238650)
Source A library
License PD-old-70-1923
Uploader Mauricio V. Genta
Date of upload 02 July 2018

Ongoing addition of properties[edit]

Will there be an ongoing property request process, like occurs on Wikidata? Properties are created there quite frequently. It's likely that experience of using the system will lead to ideas for further properties. --ghouston (talk) 03:39, 3 July 2018 (UTC)[reply]

Yes, we do envision this being an ongoing process but it is one that will probably need some refinement and trial and error so we're starting it off in this "guided" fashion. RIsler (WMF) (talk) 18:40, 3 July 2018 (UTC)[reply]

Image restorations[edit]

from
to

What about image restorations where the work involve is more than just a faithful reproduction, and the final result is from the efforts of multiple contributors. Gnangarra 09:34, 3 July 2018 (UTC)[reply]


Thats somehow discussed above. You can have a property for orginal autor and you can have a property for imprower. But what come into my mind, weater we would create a property for (page) version?--Juandev (talk) 00:16, 8 July 2018 (UTC)[reply]

Notability criteria for separate items[edit]

Hi, This needs a separate discussion. What are the notability for a separate item in Wikidata. It seems some people have different opinions about this. Regards, Yann (talk) 11:55, 3 July 2018 (UTC)[reply]

Should these objects have a separate item in Wikidata ?

  • The question is, though, should the vase have its own Wikidata item, if it eg has a specific museum accession number. If not, how to keep straight statements about the vase, and eg its material composition, style, and date, from statements about the image? Jheald (talk) 23:26, 8 July 2018 (UTC)[reply]
  • What if we have multiple images of the same print then? Do we replicate relevant statements, and relate the images to each other in a peer-to-peer fashion, rather than by reference to a Wikidata item? And again, how to distinguish statements about the engraving from statements about the image? Querying becomes quite tricky if relevant information might be in a multitude of different places. On the other hand, if we insist people make and populate a new Wikidata item as well as a new CommonsData item, that has the potential to be a completely horrible user process. Jheald (talk) 23:26, 8 July 2018 (UTC)[reply]
  • I would say yes. We can find references for that in currency catalogues.
  • I would say yes. We can find references for that in currency catalogues.
I think we need to be able to describe both a specifically identifiable thing, eg the Mona Lisa and a generic instance of a thing (a redback spider) and obviously combinations of them, eg Queen Elizabeth II holding a rose. Kerry Raymond (talk) 12:13, 3 July 2018 (UTC)[reply]
The last one of those is now at I want you for the U.S. Army nearest recruiting station (Q55364202), and I suspect a number of the others could also have Wikidata entries. Thanks. Mike Peel (talk) 00:38, 4 July 2018 (UTC)[reply]
Well, I think that the trouble here is, than when we were testing captions, it was not clearly explained by moderators, how to test them and some people mixed captions, with items. So it would help that that previous step is clarified, that everbody knows and than everybody can follow here.
I think it is allready set, that every page from ns file will have its item. So it is important to clarify that previous confusion, that caption is not an item, category will not be an item, nor "Blaue Rispe". Blaue Rispe will be an item in the main ns on Wikidata (for Wikipedia), but in the case of Commons integration, every Commons file will go to Commons ns on Wikidata.--Juandev (talk) 00:24, 8 July 2018 (UTC)[reply]
@Juandev: Obviously, all Commons files will have an entry on SDC, but here the issue is, what is the notability bar for having an entry in Wikidata. Other example: I am looking at Wikidata entries for each of en:List of iconic photographs. So all these iconic pictures have an entry on WD, but what's the limit? Regards, Yann (talk) 13:00, 8 July 2018 (UTC)[reply]
@Yann: I see, thank you to mention that point. So this may be cover by featured pictures in combination of some limits. Or two load it just from Wikipedia list, where somebody set the best representations of items manually.--Juandev (talk) 17:48, 8 July 2018 (UTC)[reply]
@Juandev: Commons featured pictures are chosen based on quality. Some images have a WD entry because they are notable. No special correlation between these. Most FP aren't notable enough to have an WD entry. Many images with a WD entry are not good enough to be FP. Regards, Yann (talk) 19:20, 8 July 2018 (UTC)[reply]
At this point probably worth mentioning d:User:Sic19/Welsh_Landscape_Collection: each image here has its own Wikidata item; and Welsh Portrait Collection (Q54859927) (see on Reasonator). Also the related queries at d:User:Sic19#Wikidata_Visiting_Scholar Jheald (talk) 23:39, 8 July 2018 (UTC)[reply]
These queries, which give counts for properties on items in the two collections, may also be of interest: tinyurl.com/ya3spzla, tinyurl.com/y92yphfe -- Jheald (talk) 00:01, 9 July 2018 (UTC)[reply]

Copyright[edit]

Somewhat broader that the topic in question, I think we need both author/creator and current copyright holder. When I say “my own work”, I should be saying I pressed the shutter button on the camera, but if I take that photo as part of my job, then my contract of employment may specify the copyright belongs to my employer, who might subsequently sell the copyright of that image to a third party. We need to get this important distinction sorted out. Kerry Raymond (talk) 12:18, 3 July 2018 (UTC)[reply]

@Kerry Raymond: . This exists: creator (P170), copyright holder (P3931). Jheald (talk) 22:11, 8 July 2018 (UTC)[reply]
On the same topic; would it be necessary to add a property for the eventual OTRS ticket, or the template in the file page should suffice? --Ruthven (msg) 19:41, 3 July 2018 (UTC)[reply]
Not only for the ticket, but also for the account who add the permission, and the date. Ideally. Regards, Yann (talk) 20:03, 3 July 2018 (UTC)[reply]

Overly simple examples[edit]

These are, for the most part, overly simple examples that do not raise the issues that will make this difficult. How about:

  • An urban scene in which quite a few objects are incidentally present?
  • A photograph of a copyrighted sculpture, but OK under German Panoramafreiheit?
  • A picture of a person holding an artwork they executed?
  • A view from a high place in which multiple significant places are visible?

- Jmabel ! talk 15:28, 3 July 2018 (UTC)[reply]

Jmabel I believe knowing a bit more of Wikidata you will have most of your answers, see this example: wikidata:Q51099274 that is the entry for this historical photo:

You have at Wikidata "main subject" and also "depicts", you determinate what is the main object, could be a whole neighbourhood, and what we can see in this photo. We will have also the same structure.

In the case of the artist, very simple "main subject" "artwork" and "painting". Or "painter"... I didn't get the problem at the second item. -- Rodrigo Tetsuo Argenton m 00:04, 4 July 2018 (UTC)[reply]

Why you are mad?
I gave to you the exactly "urban scene in which quite a few objects are incidentally present", and how to model it at Wikidata, we just need to apply here.
If you knew a bit more, you could face this example, or could search for it. By the way, knowledge is infinite, is not demerit not knowing something.
Peace.
-- Rodrigo Tetsuo Argenton m 00:28, 4 July 2018 (UTC)[reply]
  • Three examples of pictures where it is not obvious what is "primary"; all of these are, at least in part, of Lake Union in Seattle:
  • Is the park primary, or the lake? Or, although it is very small in the center, the fireworks barge, which is why this picture probably exists: the foreground turns out to be people gathering hours early for Independence Day fireworks.
    Is the park primary, or the lake? Or, although it is very small in the center, the fireworks barge, which is why this picture probably exists: the foreground turns out to be people gathering hours early for Independence Day fireworks.
  • Probably the most visually prominent thing in the image is either Portage Bay (a bay of the lake) or the Montlake Bridge, but the main reason this 1951 picture is of interest is that the boat at left is the Fantome, later lost with all hands in a hurricane in the Caribbean.
    Probably the most visually prominent thing in the image is either Portage Bay (a bay of the lake) or the Montlake Bridge, but the main reason this 1951 picture is of interest is that the boat at left is the Fantome, later lost with all hands in a hurricane in the Caribbean.
  • I took this one as part of a series of a seaplane taking off, but the plane is barely visible here. What's "primary"? The lake? Eastlake and/or Capitol Hill in the background?
    I took this one as part of a series of a seaplane taking off, but the plane is barely visible here. What's "primary"? The lake? Eastlake and/or Capitol Hill in the background?

- Jmabel ! talk 00:29, 4 July 2018 (UTC)[reply]

You answered it, "all of these are, of Lake Union" so Lake Union is one of them main subjects, open the Wikidata item that I send to you, you will see that have more than one item...
How do you categorise this pictures?
-- Rodrigo Tetsuo Argenton m 00:36, 4 July 2018 (UTC)[reply]
Above, you refer to "the main subject". That means there can be only one (unless that is not what you meant to say). Are you saying now that there can be more than one "main subject" for the same image? - Jmabel ! talk 18:54, 4 July 2018 (UTC)[reply]
Yes. Consider by analogy how books are represented in library catalogues. The multi-part subject strings you find in such catalogues, eg "Botany--United Kingdom--Field Guide" are what correspond to main subject (P921). Books often have two or three such strings. Even so, the number of subjects covered, that might be represented by search keywords, or analogously here depicts (P180) may be substantially wider.
The Structured Data plan is, I believe, to start with depicts (P180). Some of those values might then be promoted to main subject (P921) values when it becomes available. Jheald (talk) 22:19, 8 July 2018 (UTC)[reply]

Incidental inclusion[edit]

One thing I'm pretty sure of: if we are doing a "depicts" property we need a qualifier to indicate if the depiction is incidental and another to indicate that it is backgrounded. For example, File:Apartment building in Belltown with Elliot Bay in background - Seattle.JPG shown here has a small part of the Edgewater Inn at upper left, and Elliott Bay in the background, but would be extremely unlikely to use as an illustration of either. - Jmabel ! talk 15:35, 3 July 2018 (UTC)[reply]

Hello. We do intend to have the ability to mark one depicts statement as "primary", so in this case the uploader or curators would set the Apartment building in Belltown as the primary thing depicted in the photo. Do you think that would be enough, or would you still want an "incidental" property? RIsler (WMF) (talk) 18:36, 3 July 2018 (UTC)[reply]
I don't think marking exactly one thing as "primary" is at all the solution. Often, several things are equally primary. But that's a separate issue from the one I'm raising. I'm thinking of things like someone wanting to mark the (barely visible) Edgewater Inn as visible in this photo, or indicate every [damn] time there is a stop sign anywhere in a photo. These are fights we've long had on Commons; the ability to mark something as depicted, but note it as incidental would make it a lot less contentious. - Jmabel ! talk 00:10, 4 July 2018 (UTC)[reply]
Jmabel check the example that I gave to you, this also answer the "several things are equally primary". -- Rodrigo Tetsuo Argenton m 00:30, 4 July 2018 (UTC)[reply]

Bounding boxes[edit]

Certain other image databases such as w:ImageNet and w:CIFAR-10 have attributes for capturing (approximate) "bounding boxes" of objects in an image. An analogous property would enable Wikimedia images to be used for similar purposes. Perhaps it would be defined for use as a qualifier of "depicts (P180)" statements, and perhaps it would require a new data type.--Anders Feder (talk) 17:55, 3 July 2018 (UTC)[reply]

Hello. Yes, we intend to do this in early 2019 with a re-purposing of ImageAnnotations tied to depicts statements (and supporting IIIF spec). RIsler (WMF) (talk) 18:24, 3 July 2018 (UTC)[reply]
Excellent! - 18:49, 6 July 2018 (UTC)
@Anders Feder: At the moment on Wikidata the position of an object within a larger image can be specified using the relative position within image (P2677) qualifier. A javascript user-script d:User:Husky/ifff-viewer-link.js that you can install via your common.js file blue-links statements containing such values within a wikidata page, linking them to an image of just the extracted detail, cf those shown at [5] or [6]. One could also imagine an alternative script that instead might highlight the detail eg by a yellow box within the larger image. Jheald (talk) 22:29, 8 July 2018 (UTC)[reply]

Rank of prominence of depticted entities[edit]

Rank of prominence: (1) giant grouper (Q847747), (2) smaller yellow fish, (3) background fish, (?) (aquarium) sea water
Rank of prominence: (1) Falcon Heavy (Q1093627), (1) nearest landing zone, (2) farthest landing zone, (3) Vehicle Assembly Building (Q901058) (small square building on the horizon), (?) sky, clouds

There are already some other sections discussing the implementation of depiction data, but I want to take a slightly different approach here.

For many or most images depicting more than one thing, there is a clear rank of prominence of the entities depicted in the image. In the example with the fish, there is a natural rank of prominence of the different species being depicted (although the yellow fish and the big fish are quite similar in prominence). We might not necessarily want to rank the water here, but we do want to indicate that the image has a subsurface perspective (the fish is not lying dead on a pier, for instance).

In the rocket landing example, there is also the extremely common question of how to rank the prominence of the sky (an omnipresent feature for the surface of the earth), and the question of how to rank the prominence of the restricted (but very common) phenomenon of clouds.

At the same time, it might be more interesting to know (for the fish example) that the fish in the background forms the background than that it has prominence rank number 3; so maybe we would also want to have a way to indicate that something is simply in the background of the image (also discussed above). Different entities of different prominence rank could still both form the background, and the entity with the lowest prominence rank does not have to form a background (at least not if the depiction list is incomplete), so simply setting the background equal to the entity that has the lowest rank of prominence would not be good enough.

Another interesting property would be the relative distance to the camera, which I guess sometimes would be identical to the rank of prominence, but would often be different. Relatedly, it could also be interesting to know if an entity being depicted is in or out of focus.

An example of the use of a prominence ranking is the generation of smarter automatic captions. For the fish example, you could create a caption to the effect of "giant grouper (Q847747) with <yellow fish species> and <background fish species> in the background". Another example is when you want an image that features two specific species prominently; then you could search for relevant images using prominence ranks (you could for example specify that they should be the two most prominent entities depicted).

In sum, to have a property called rank of prominence or similar that could be used as a qualifier for the depiction property seems useful to me. Tricky, but useful. --Njardarlogar (talk) 12:04, 4 July 2018 (UTC)[reply]

@Njardarlogar: On Wikidata, the generic qualifier object has role (P3831) is available to say more about the role of the item identified by the depicts statement. One might consider creating a vocabulary of various values for this qualifier, eg "background object", "more minor background object", etc. Jheald (talk) 22:37, 8 July 2018 (UTC)[reply]

Example 6 - Print of château de Chillon[edit]

All sorts of issues here:

  • This is a print from a book of prints - one of 350 illustrations to Tableaux topographiques, pittoresques, physiques, historiques, moraux, politiques, littéraires, de la Suisse. That is one of the most important things to record about it, and how it will be found in libraries etc. Perhaps the prints were also sold individually, and perhaps some dealers have subsequently gutted copies of the book for the prints. As I've said above, if anything needs a WD item it is the book rather than the print, I think.
  • Further to this, some prints from the book have been hand-coloured. This may have been done after purchase at any point, but they were perhaps originally published and sold in two forms. We may need to record that this one is uncoloured.
  • Compared to the other one, this has clearly been trimmed to the image, probably at the scanning stage or after, losing the margins and legend. We might need to note this.
  • The class of objects this belongs to is the "topographical print" - the scene is a real view rather than imaginary. I would say this is the "Type of work of art"
  • "Type of work of art Engraving" - very possibly not. Only a careful and informed look at the original can make sure, but to me it looks like etching and other techniques have been used. "Engraving" & its translations is often misused in several languages as a catch-all term for all black & white prints, and descriptions on Commons are more often wrong than right - as with other non-museum internet sources. In any case, in conventional terminology this is the "medium" or "technique", not the "Type of work of art". The same issues would arise with a "Painting" (medium) in "oil on canvas" (technique), or a sculpture. Many systems have a class for "works on paper" which this no doubt is.
  • "Artist 1's function Drawer" - not sure why he is "artist 1", not the printmaker. "Drawer" is (outrageously) the WD property name - it is not a proper English word. In this case the French is "dessinateur", which is better translated as "designer (of the composition)". There may well have been a drawing, but for all we know the design may have been taken from a painting, or another print.
"Painter" isn't relevant in this case (same meaning in English). gravure should link to en:Printmaking, likewise fr:Techniques de gravure. Print and printmaking are the proper English generic terms; no museum would ever use "engraving" as such, though the general public might. "Design" is the best equivalent for dessinateur. I repeat "Drawer" is not a proper English word - museums use "draughtsman" (US "draftsman") though they often avoid a "person who does" word and saw "design by", "drawn by". Unfortunately many English terms on Commons are set up by people who don't speak English as well as they think they do. This is how the British Museum handles prints. Johnbod (talk) 13:15, 6 July 2018 (UTC)[reply]
  • Wikidata rightly says the English is also "Château de Chillon" not "Chillon castle".
Ok, fooled by the redirect. Apparently on en:wp the Swiss have "castles", the French "chateaux". Doesn't seem right to me, but there we are. Johnbod (talk) 13:15, 6 July 2018 (UTC)[reply]
  • The issues of main and secondary subjects brought up elsewhere on the page apply here too.

Johnbod (talk) 15:04, 5 July 2018 (UTC)[reply]

The best source on such things is en:ULAN, which has these Perignons. Most of the other "Authority Control" refs suggest that the earlier on is just "Nicolas". Johnbod (talk) 13:19, 6 July 2018 (UTC)[reply]
Well, ULAN is clearly wrong here. Alexis-Nicolas Pérignon (Q16739685) is certainly not Pérignon the Elder, who is Nicolas Perignon (Q20926466) (cf. http://www.isni.org/isni/0000000117812329 and other sources). And we don't even know what's the first name of this artist, so he could be Jean-Baptiste PERIGNON. But my question was, why is he not credited, although he signed his works? Regards, Yann (talk) 13:32, 6 July 2018 (UTC)[reply]
  • I changed some the properties and data following your comments above. Please review. I am not sure what should be the property for the GLAM source. And we need a hierarchical system, as some of the properties depend of other data. Regards, Yann (talk) 12:35, 6 July 2018 (UTC)[reply]
  • Comments on the changes:
  • "genre (P136) photograph (Q125191)" - Is a scan properly a photo? Everything on Commons that isn't a video or digital graphic is a photo. You need a property like "class", and save "medium" for actual photos (photos of photos). Genre is the wrong word if you ask me, but usually used wrongly on WP.
  • "Type of work of art etching (print) (Q18218093)" - I didn't say it was an etching, only that it might be. All the sources I can find call them "engravings", though one doesn't know if that uses the loose or the proper meaning of the word. At this period many printmakers used a variety of techniques on the same plate, which complicates matters further.
  • "inception (P571) between 1780 and 1788" - "creation" would be better.

Johnbod (talk) 13:47, 6 July 2018 (UTC) Johnbod (talk) 13:47, 6 July 2018 (UTC)[reply]

  • At least, we need to record that it is a 2D reproduction, so that there isn't a copyright for the photograph. Sometimes, we may have the name of the photographer, who we have to credit to respect moral rights (see Example 5). Regards, Yann (talk) 05:56, 6 July 2018 (UTC)[reply]

This artwork does seem to be notable in the Wikidata sense, and creating that Wikidata item is the obvious fix for the problem that the thing that has the property genre (P136) -> photograph (Q125191) is not the same thing that has the property creator (P170) -> Louis-Joseph Masquelier (Q26270259). A SPARQL query for people who have created photographs shouldn't return the engravers of a work which happens to have been photographed. MartinPoulter (talk) 15:14, 23 July 2018 (UTC)[reply]

Example 7 Waiting for Godot[edit]

  • On the image file (English version): "Waiting for Godot, text by Samuel Beckett, staging by Otomar Krejca. Avignon Festival, 1978. Rufus (Estragon) and Georges Wilson (Vladimir) / photographs by Fernand Michaud." - the example only gives about 50% of this (the rest bolded)!
  • The actors name are given, but not their characters, which are known.
  • Likewise no detail on the production or location (may be against terms of copyright release)
  • It's a b/w photo (from 2013) - should cover

Johnbod (talk) 15:18, 5 July 2018 (UTC)[reply]

I think this photo should not be linked to the work "Waiting for Godot", but to the specific theatre production in the context of which it was taken. The data you have highlighted, along with some of the data already given in the example, would be included in the WD item describing the theatre production. There is no need to include it on the Commons item directly. --Beat Estermann (talk) 09:53, 19 July 2018 (UTC)[reply]
Hi Beat Estermann, Right now, there is no WD item for the theatre production, and I doubt there will ever be one. That's again an issue regarding notability for WD items. Regards, Yann (talk) 11:45, 19 July 2018 (UTC)[reply]
location (P276) seems (from its English description/ labels) intended to describe the place where an item is kept, in this case the photograph that was scanned to produce this digital image. This is different from the place where the photograph was taken, so it seems that's the wrong property here. MartinPoulter (talk) 15:04, 23 July 2018 (UTC)[reply]

It looks like there is a possible confusion because this discussion is in terms of properties rather than triples. What has the property inception (P571) -> 1978? The physical photograph. What has the property director (P57) -> Otomar Krejča (Q2347415)? The play. The photograph doesn't have a director. So at the minimum, we need to be clear about the intended subjects of these statements. If there can't be a Wikidata item for the theatrical production, then we cannot identify the thing whose director (P57) is Otomar Krejča (Q2347415) and so we can't make that statement. MartinPoulter (talk) 15:04, 23 July 2018 (UTC)[reply]

Example 10. Photo of clothing[edit]

I don't have time to add this as a full-on example right now, but please see the Summary for File:Man's tailcoat 1825-1830.jpg, where several items of clothing are depicted, each of which has its own description, material used, museum inventory number (+ in collection), credit line, place of manufacture, and date range (= point in time with earliest date/latest date/sourcing circumstances). I (eventually) want to be able to capture all of this as structured data. Also, there are annotations which should be captured however we end up doing that (IIIF positional data?). I'll try to make a proper example file soon. - PKM (talk) 02:15, 6 July 2018 (UTC)[reply]

  • @Mike Peel: do you think we should carry all of this data in Commons (as above)? My thinking that this data eventually replaces categories, so that if one wanted to search for men's 1820s coats made in England, one could find them. But there may be few editors interested in adding this amount of information. Perhaps it belongs in Wikidata only, since items in museum catalogs generally meet notability criteria there. Or if the data 'is' in Wikidata, do we not want to display it on Commons? - PKM (talk) 19:51, 6 July 2018 (UTC)[reply]
    • @PKM: My view would be that the info should mostly be stored in Wikidata, and just use the "depicts" property to pull the information from Wikidata to here. But others will undoubtably disagree, it depends where the line is drawn for notability. Thanks. Mike Peel (talk) 21:17, 6 July 2018 (UTC)[reply]

Incremental addition of statements[edit]

Something that works fairly well in Wikidata, is the incremental addition of statements. Items start out with relatively few statements, then gradually grow. As many properties at Wikidata come from different aspects, this is happens fairly naturally and completeness can be assessed through the presence or absence of properties.

If one attempts to describe a photograph with a single property (such as "depicts"), the risk is that this is hard to do incrementally. At least at Wikidata properties that are meant to be multi-valued or have a large scope are complicated to handle. While queries are possible, these don't necessarily help when editing.

I'd suggest to attempt to determine several levels of properties to describe specific aspects. --Jura1 (talk) 04:55, 6 July 2018 (UTC)[reply]

+1--Juandev (talk) 00:30, 8 July 2018 (UTC)[reply]

Example 11. Subduction diagram[edit]

It is not relevant for this image, but since many scientific images were first published in journals, I would like to see the property "journal" (scientific journal or academic journal) --Sohmen (talk) 10:27, 6 July 2018 (UTC)[reply]

  • If we are using structured data to track creator for licenses that require attribution, surely we need to also indicate the attribution! For example, I'm on here as Jmabel, but I'm consistent in stating that the attribution is "Joe Mabel". I do not want some structured system to effectively suppress that. - Jmabel ! talk 16:12, 6 July 2018 (UTC)[reply]
    To me, the SVG file should already have RDF metadata that describes dc:creator, dc:date, and cc:license; it could also have other information such as dc:title, dc:language, dc:subject, and dc:source.
    There can certainly be
    to uniquely identify you and
    to show how you want your identify attributed and have a link back to Commons.
    Such information should be in the file's metadata (not just text or SD on Commons) so when somebody copies your file off-wiki, the information is not lost.
    Glrx (talk) 19:20, 6 July 2018 (UTC)[reply]

Example 1 - size[edit]

I guess size here means the size of the object. Which is not apparently clear from this photographs, but yes, there might be photograps, where it is clear (taken in schools or by scientests) or the photographer may measure it. But what kind of size for 3D object? Even 2D object, like painting reproduction, whould have two sizes. So I thing, this should be specifies. Than the other question is, if we can display value in different units (US/Europe), wheater it si possible in Wikidata?--Juandev (talk) 21:12, 7 July 2018 (UTC)[reply]

That was raised as the very first point on this long page. Obviously one needs height, width and (where appropriate) depth, which WD surely have, as well as a way of handling the units. Johnbod (talk) 21:31, 7 July 2018 (UTC)[reply]
I am sorry, I had to work last days so I was unable to follow discussions. So I would better to read all discussion here first before questioning or proposing something. Thx for info.--Juandev (talk) 21:36, 7 July 2018 (UTC)[reply]

Example 1 - Photograph of an object (Juandev)[edit]

File:Blaue_Rispe_nach_Riemerschmid_Vase_10cm.JPG
Property (English label) (+ optional Wikidata Property ID) Value
Depicts (P180) Vase, Fish
Style https://www.wikidata.org/wiki/Q55255109 (Blaue Rispe)
Material Porcelain
Main image colors White, blue
Background color White
Author unknown
Image author Kaolin
Copyright rationale Own work
License Public Domain
Date created 20 August 2010
Max image resolution 800 × 600 pix
File type jpg
On Wikipedia Link to related iteam on Wikidata uploaded from Wikipedia

Here I am removing some properties. Size, because even it is in the file description, it does not say much which size. Than Copyright status, because I dont know, what is that. On the other side I add:

  1. Material - even on commons, we sort files by dominant material of depicted subject, because we think, that someone may want to search files by their material (see. category:Iron gates or category:Wooden gates
  2. Main image colors - same as previous reason
  3. Background color - same as previous reason
  4. Image author - I removed ns prefix, I dont know wheater it would be needed to display it, but i would not display it. I have also renamed the property to specify it.
  5. Author - means author of the wase, one scupltor or a serie designer. The question is if we are interested in the values such as "unknown"
  6. Max image resolution - say something about technical quelity
  7. File type - we can host on commons wide range of file types. It would be nice to have this information as a property, because it could help us to distinguis between e.g. the video about this wase and images
  8. On Wikipedia - this is something more like a question. Commons items will stay in different ns in Wikidata. But it would be great to ling commons images to Wikipedia articles somehow

--Juandev (talk) 21:34, 7 July 2018 (UTC)[reply]

Not an improvement at all. We do know the designer
English: Richard Riemerschmid
and the factory, Meissen. "Vase" and "fish" should not be in the same field, and so on. The design includes leaves as well as many small fish. Johnbod (talk) 15:46, 10 July 2018 (UTC)[reply]

Properties of metadata[edit]

In the previous discussions, we were talking about properties of metadata. Let's list them and have a look at them in detail.

Wikimedia Commons Wikidata
No. Name on WMC Description Example WD property Values Existence
1 file:*.* File types 1 file format (P2701) file types suported by wmc (eg. jpg, pdf, ogv) yes
2 max resolution Image resolution in pixels - NUMBER x NUMBER no
3 file size data size (P3575) NUMBER yes
4 created Date or minute of image creation - DATE TIME
5 modified Date or minute of the last modification DATE TIME
6 source Source from Description template own or name
7 image author
8 depicted object author
9 digitalizator e.g. for scans
10 license license or licenses of the file copyright license (P275) ? yes
11 quality for featured or quality images
12 value for valued images
13 Personality Personality warning if people displayed
14 Camera manufacturer Exif make (P2010) yes
15 Camera model Exif model (P2009) yes
16 Exposure time
17 F-number
18 ISO speed rating
19 Exif version
20 Image compression mode
21 Flash Flash used or not, type
22 Color space
23 Exposure mode
24 White balance
25 Digital zoom ratio
26 Object coordinates
27 Photographer position Coordinates of position, may include direction of photo taking
28 User or project categories
29 Copyright
30 Watermark
31 Width Width of the file in px, loadable from exif
32 Height
33 EXIF Whether EXIF is present or not
34 Institution Donator of the file
35 Copyright holder License or copyright holder, not always an uploader
36 Project The project under which means the file was created 1
37 Catalogue number Can be multiple - catalogue numbers of donating organisations
38

The above table is unsigned, collective work.

  • On source: besides "own or name", supplementary to name we need the possibility of a wikilink or external link.
  • Also, I don't see anything here on required attribution. - Jmabel ! talk 15:43, 11 July 2018 (UTC)[reply]
  • Thanks for making this. We're looking to include properties that don't exist yet, so those that'd like to participate please keep that in mind as you fill in template fields. A 1:1 Wikidata property might not be available. Keegan (WMF) (talk) 22:05, 11 July 2018 (UTC)[reply]
  • In Commons, we'd probably want a property like "Equipment" that can be linked to a wikidata item like wikidata:Q66265. It's possible for multiple items of equipment to be associated with a single image. A value could be set automatically from the Exif fields in many cases. --ghouston (talk) 05:52, 15 July 2018 (UTC)[reply]

Free description field[edit]

Will Structured Commons be the only description for images in the future? Hopefully there will still be a free text description field. Not everything is easily modeled in Wikidata. For example this file File:Bodice Designed by House of Worth and Worn by Julia Dent Grant.jpg has the description "Brown satin bodice with lace and velvet trimmings, designed by House of Worth, worn by Julia Dent Grant, wife of President Ulysses S. Grant." which would be a pain to model and it would probably discourage anyone who just wants to quickly upload an image without learning about Wikidata first. It would be a shame if this kind of information got lost just because it is hard to model. --Sohmen (talk) 12:34, 9 July 2018 (UTC)[reply]

I think so. As far as I understand, the description field will stay and it will be deployed on WMC. While there will be also shorter Caption, which will go to Wikibase or wd.--Juandev (talk) 15:32, 9 July 2018 (UTC)[reply]
@Sohmen: I'm not 100% sure, so I'll find out. One way I know of for sure will be the free text caption that Juandev mentions, except I'd like to clarify that captions are being stored as wikitext here on Commons. Keegan (WMF) (talk) 19:09, 9 July 2018 (UTC)[reply]
To clarify Keegan's clarification :-), there will still be a free text Wikitext description field until/unless we find a way to do it well in Structured Data. Also, the new short multilingual file caption will be, as Juandev stated, stored as structured data in Wikibase@Commons. The "structured" part in this specific case refers to the way the text is stored by language, not the breakdown of the concepts into wikidata entities (that's different and would be done via depicts statements with qualifiers). If we do eventually have structured descriptions, the purpose of that would be to have a clean method for doing multilingual free text descriptions without finicky templates. RIsler (WMF) (talk) 23:21, 9 July 2018 (UTC)[reply]
Ah yes, wikibase at Commons, but not Wikidata. That was the distinction I was trying to make, thanks RIsler. Keegan (WMF) (talk) 22:02, 11 July 2018 (UTC)[reply]

Timed or otherwise sequential media[edit]

The subject(s) — main or incidental — of a media file might change in sequential media files like audio or video files (see also Example 3), books, presentations and so on. In order to model that, say, a goat is depicted/ mentioned in there, we likely need qualifiers like "point in time", "page" or some such. In many circumstances, relevant Wikidata properties already exist, but in some cases (e.g. 3D files), the existing ones may not be sufficient. Another issue to consider is what tools are/ will/ should be available/ developed to determine/ verify suitable values for such claims. -- Daniel Mietchen (talk) 01:37, 11 July 2018 (UTC)[reply]

Link to original file for cropped image[edit]

For files that are cropped versions of other images, we need a property to point to the original file. I think that the value of the source parameter for the original and truncated file should be the same and point to an external source. — putnik 19:57, 11 July 2018 (UTC)[reply]

Doesn't CC-BY require the cropped version to point to the external source? If cc:attributionURL = https://externalsource.com/mumble.html, then shouldn't every derivative work carry that URL? Glrx (talk) 18:32, 17 July 2018 (UTC)[reply]
Cropped file should link to the file stored here from where they are cropped, IMHO. It's not just a matter of url.--Alexmar983 (talk) 20:40, 11 August 2018 (UTC)--Alexmar983 (talk) 20:40, 11 August 2018 (UTC)[reply]

multiple originals[edit]

Der Rufer 2017 gnangarra-101
In the case of some works multiple statues are cast as originals, in this case Der Rufer(pictured). The issue is the three originals each have their own history/connections related to the locations Berlin, Bremen, & Perth . would each statue have its own ID or be combined into one id with multiples of each data set. Gnangarra 04:06, 15 July 2018 (UTC)[reply]
this copy might have separated ID on google maps cid, tripadvisor or whatever, they show different creation date and different coordinates. They are different, they should be tretaed differently and connected to a main file acting as an umbrella.--Alexmar983 (talk) 20:42, 11 August 2018 (UTC)[reply]

Place of discovery vs Photo location[edit]

For the species that are in museum but that of course have been discovered elsewhere, and it is also valid for archaeological objects. It would be good to have the choice to add two different properties, one for the Place of discovery and one for the Photo location. A few example : an echinoderm and a butterfly. Christian Ferrer (talk) 04:47, 16 July 2018 (UTC)[reply]

I agree.--Alexmar983 (talk) 00:11, 29 July 2018 (UTC)[reply]

Blunderbuss or marksman -- how should P180 "depicts" tags be applied on CommonsData ?[edit]

How are depicts (P180) (and other properties) going to be used on CommonsData items?

A core principle on Commons to date has been COM:OVERCAT -- don't put additional general categories on a file, if the information is already implied by a more specific category.

Equally on Wikidata the principle has been to make statements as specific as possible; and to remove any more general statements that may be redundant to them. So for example, one does not state that a place is located in the administrative territorial entity (P131) of a state, if it has a statement that it is located in the administrative territorial entity (P131) of a municipality. And similarly for depicts (P180) on Wikidata. One does not state that an item depicts (P180) an animal, if one can state that it depicts (P180) a lion. And one does not state it depicts (P180) a lion if one can state that it depicts (P180) a particular type of lion, or even a particular individual lion.

One might call this the "marksman" approach -- trying to define the information with as few statements as possible, each as precise as possible.

Yet many tagging initiatives in GLAMs -- and particularly big crowdsourced operations -- use an opposite model, of encouraging people to add any and each and every tag that seems relevant, regardless of what other tags might be added. Similarly GLAMs may include every relevant keyword in their description metadata to increase the chances of a search hit, irrespective of any redundancy between them. This one might call "blunderbuss" approach, trying to pepper the image with as many descriptive terms as possible.

Many GLAMs have found this a source of frustration and misalignment in the past -- that Commons people gets unhappy if they add categories going up the entire hierarchy of their existing keywords, and sharply direct them to COM:OVERCAT. Indeed, I believe that this is one of the key frustrations that GLAM people can feel with Commons categorisation.

So what will happen with depicts (P180) on CommonsData? Will the same issue arise again? Or, do we expect and accept (and perhaps even encourage) images to be identified by multiple redundant topic tags, and that is all good?

I don't have a particular axe to grind either way, but I do think it is something that we should have thought about. Jheald (talk) 13:27, 18 July 2018 (UTC)[reply]

I would be in favor of the first approach. The only case where a media is both "depicts lion" and "depicts animal" would be when the picture actually depicts a lion AND an unrecognizable animal". I guess. Syced (talk) 12:33, 20 July 2018 (UTC)[reply]

WD property copyright status[edit]

Hi, As shown in the discussion here, we need a property for "copyright status" for all works of art which have a WD entry, so I went ahead and made a proposal: d:Wikidata:Property proposal/copyright status. Regards, Yann (talk) 08:45, 20 July 2018 (UTC)[reply]

Metadata to indicate that a media file has a specific position in a series[edit]

Sometimes, files are part of a deliberate, ordered series - like in the case of the photo essays submitted for Wiki Loves Africa 2017. Perhaps ordered series of prints can also be considered a similar case, or even polyptych artworks. How would we indicate the numbering in such series? Wikidata has series ordinal (P1545), used as a qualifier; not sure if that would be re-usable for Commons cases. SandraF (WMF) (talk) 15:01, 25 July 2018 (UTC)[reply]

Idem for featured sets, example, we likely need a kind of property "this image is part of a set" (and then we provide a link to the set/serie), and with a possible number parameter 1, 2 3 , ect... in order to determine a potential order. Good idea. Christian Ferrer (talk) 18:08, 25 July 2018 (UTC)[reply]
Use "follows" (P155) and " followed by" (P156); and "part of" (P361). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:46, 26 July 2018 (UTC)[reply]

Maps[edit]

d:Wikidata:WikiProject Maps has done some work on mapping the {{Map}} template to Wikidata properties, for historical maps.

See d:Wikidata:WikiProject_Maps/Historical_map_properties for their work so far (though I am not sure how up to date this is).

Maps may well be a good set of images to look at for early conversion to structured data, since

  • the number on Commons using {{Map}} is so far quite small, making it appropriate for a pilot
  • {{Map}} already gives some detailed information, already in quite a strongly structured way, that would give some nice results examples for SPARQL searches.

Looking at {{Map}}, the following seem to me some questions or gaps in the current document by the wikiproject:

  • "Source" -- this is going to be an issue for all Commons images, but how will one indicate where the image has come from? One would usually want to indicate both a relevant URL for a web-page presenting the image, together with a URL where the image itself is available. (Although in some cases a Commons image may have been extracted in parts and then reassembled from eg a deep-zoom presentation). One might also want to give the organisation operating the website, which may or may not be the same as the organisation that holds the original document. In some cases the Source field has significantly more excursive information (eg specialist institutional templates, links to different institutional catalogues, health-warnings about truth of scan to original, etc).
  • "Map location" (ie location depicted) -- not completely clear whether main subject (P921) or depicts (P180) should be used.
  • "Map projection" <--- missing property ?
  • "OSM level" <--- missing property ?
  • "Heading" <--- missing property ?
  • "Bounding box" (ie bounding coordinates) <--- missing property ? (not clear that coordinates of northernmost point (P1332) etc can handle this).
  • "Georeferencing" <--- may needs specialist property: described at URL (P973) seems a bit of a stretch, even with appropriate qualifier
  • "Scan resolution" <--- missing property ?

There is also a question of what items may be expected to exist on Wikidata. Probably at the very least there should be an item for the original book or atlas or series that the map was part of (FRBR work level), if that can be identified. For printed works there should probably also be an edition item, unless the work was only published once. In most cases (for printed works), there probably isn't going to be an item for an individual exemplar of the work, or a particular scan-set of it, and perhaps also not for a particular map as part of the overall work. Yet the image on Commons should be identified to a particular scan-set, of a particular copy of the work. But this may be some information that needs to be held on Commons. Jheald (talk) 23:52, 31 July 2018 (UTC)[reply]

I agree that maps are a good pilot case, and would be immensely interesting to give a boost to their reuse by including them early. Some pointers and comments:
Here area some comments to the missing properties:
  • "Map location" (ie location depicted) < -- I have proposed depicts (P180) but it can be different.
  • "Map projection" <--- spatial reference system (P3037) should be usable
  • "OSM level" <--- Map zoom level has been discussed without conclusion
  • "Heading" <--- missing property ?
  • "Bounding box" (ie bounding coordinates) <--- There have been attempts to solve the bounding box property without success, and there may already be an existing way to handle this currently.
  • "Georeferencing" <--- There are different sets of data to store. An attempt to create a web mapping service link required more expert data to be completed. If georeferencing points for a map would be saved, it would allow migration between georeferencing platforms. The tabular data datatype could be used, but a property would be needed.
  • "Scan resolution" <--- missing property ?
The historical map example on the project page has been made using these definitions, but towards the end of the example it becomes more sketchy. Please feel free to complement!
I will not revisit the question of notability, which will be resolved in the overall process.
– Susanna Ånäs (Susannaanas) (talk) 07:21, 1 August 2018 (UTC)[reply]
(ec) Sorry, I'd missed your detailed work on "Example 9: Historical map sheet" on the main page. Some comments on the proposed properties & values there:
  • instance of (P31) -- suggested new property "type of media file" seems more appropriate than P31. Probably makes more sense for this to be something more generic, like "scan of 2d item", from a quite restricted controlled vocabulary, with "general map" or the type of map given as genre (P136)
  • start time (P580) / end time (P582) -- not appropriate as qualifiers to indicate a range of times -- these properties are used a qualifiers to indicate times when a statement may be valid. earliest date (P1319) and latest date (P1326) are the appropriate qualifiers here.
  • depicts (P180) -- I think main subject (P921) should probably be identified if possible, with depicts (P180) used to identify any additional or unusual features (eg inset map of a town on an old map of a county). This I believe is how P921 / P180 are currently used for artworks. Also for example on eg File:Antique_map_of_London_by_Braun_&_Hogenberg.jpg, one might want to have main subject (P921)="London", depicts (P180)="City of London", "Soutwark", "Westminster".
    • One question I didn't raise above, is how to note that a map presents "part of" an entity -- eg "Part of Lincolnshire". Adding a qualifier applies to part (P518) = <somevalue> might have been one approach; but (as per a few sections above), this wouldn't be appropriate, because P518 is going to be used to indicate parts of the image that a statement refers to. Nevertheless there is a strong need to be able to distinguish maps of a whole county from maps of a part of that county, maps of the whole of London from maps of a part of London, etc.
    • A further question: Some of the things depicted may not be part of the main mapping -- eg: a coat of arms; or an illustration of a building; or an inset map. Do we need a qualifier to indicate this, or is object has role (P3831) = illustration (Q178659), "inset map" etc sufficient?
  • coordinate location (P625) -- not sure if this would be the right property. (They would be the co-ordinates of the subject depicted, not the co-ordinates of the present location of the object). For photographs of places need to distinguish "co-ordinates of main subject" from coordinates of the point of view (P1259). We should follow whether "co-ordinates of main subject" gets created for that use-case.
  • spatial reference system (P3037) -- should be distinguished from "projection", I think. P3037 should be used to indicate what grid of lines (graticule) is printed on the map or marked around the frame -- eg UK National Grid, Finnish National Grid KKR3, or simply latitude (Q34027) + longitude (Q36477). A reference ellipsoid like World Geodetic System 1984 (Q11902211) may also be appropriate. But one could specify WGS84 latitude and longitude, and yet still project it in a number of different ways.
  • Georectifying control points -- Wikibase may not be the ideal form for storing tabular data, sometimes with up to several hundred rows. An associated data: object may make more sense. Note that imports from some external georeferencing tools may include additional columns -- eg the time that a control point was added, the map source and magnification level against which it was georeferenced, etc.
  • Archiving organisation -- May wish to underline that this would be the organisation which holds the physical copy of the map, not necessarily the organisation which may have scanned it; or the organisation/platform which may be providing the digital copy (for which "published digitally in" is proposed).
  • View of the georectified map -- Possibility should exist to specify an external URL, instead of or in addition to our own viewer.
  • Original title -- title (P1476) is probably appropriate here.
  • Creator role -- object has role (P3831) can be used as a qualifier on "creator" statements.
  • publisher (P123), place of publication (P291), and publication date (P577) are available for publication details
  • printed by (P872) is available for "printed by"
  • "Publication" -- part of (P361) published in (P1433) is probably appropriate here -- it is used for eg articles appearing in a book. Ideally the value would be an edition, rather than a work.
  • "License" -- copyright license (P275) is available.
  • "Map material" -- made from material (P186) is available. It should be reasonably clear that this would be about the underlying object, since the scan itself would have no material. fabrication method (P2079) is available to discuss techniques (eg "copperplate engraving", "hand coloured", etc)
  • "Dimensions" -- height (P2048) and width (P2049) are available. A convention in map cataloguing is to give the dimensions of the area within the "neat line" of the map (ie the inner frame, usually); but we might sometimes also want to record the dimensions of the whole sheet, or of the area within the print marks. applies to part (P518) is presumably the qualifier to indicate this, but it may make sense to develop a vocabulary of values.
  • "Last rights holder" -- a very useful and valuable field to record, which should be taken up more widely.
Pinging @Susannaanas: for further thoughts, with appreciation for her excellent work creating and developing this item. Jheald (talk) 08:56, 1 August 2018 (UTC)[reply]

Vectorial maps[edit]

I see some example on the historical map, can I suggest to insert in the final examples something about vectorial maps. Like this one about the metro. This is of course too complex for me, I'll never put it there myself.--Alexmar983 (talk) 20:34, 11 August 2018 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
— Preceding unsigned comment added by Keegan (WMF) (talk • contribs) 19:40, 14 August 2018 (UTC)[reply]

Property table[edit]

The grand table has been created: Commons:Structured_data/Properties_table.

Please leave your comments on the talk page, and help fill in missing property numbers if you are familiar with something that exists and could be listed. Keegan (WMF) (talk) 17:59, 29 August 2018 (UTC)[reply]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:Structured_data/Get_involved/Feedback_requests/Properties_for_Commons&oldid=317532066"