Commons talk:Structured data/Properties table

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Table of qualifiers on depicts[edit]

Suggesting so many properties to be qualifiers of depicts (P180) looks a rather bad move, as Wikibase cannot support qualifiers on qualifiers.

In most cases trying to force information like this into qualifiers is going to be too restrictive, because one may then want to add further qualifications about each fact (eg sourcing circumstances (P1480), nature of statement (P5102), earliest date (P1319), object named as (P1932), subject named as (P1810), subject has role (P2868), object has role (P3831) etc). If information like this is available about the thing depicted, in most cases it would appear a better idea to create a separate item for the depicted thing. Jheald (talk) 22:08, 29 August 2018 (UTC)[reply]

Yes, that's correct. While going through the previous discussion again, and looking at how GLAMs approach this (for instance the Europeana Data Model), there is a strong recommendation that metadata for the file itself is another layer than the metadata of the thing depicted; and we must be careful to make sure both are clearly distinguished from each other. Vladimir may have input on this too. My take, after wrangling the tables and re-processing all the examples we've looked at, would also be: if refined modelling of the depicted thing is important, then preferably the depicted thing is a Wikidata item indeed. SandraF (WMF) (talk) 06:59, 30 August 2018 (UTC)[reply]
@SandraF (WMF): But on the other hand, how are we going to square this with the fact that Wikidata is not going to want an item for every last pot in every museum collection?
Practically, some guidance is going to be needed here. At the moment I'm working on a collection of 18th century maps and engravings; and a separate collection of 19th century maps taken from books. What of these should have their own items? Jheald (talk) 09:10, 30 August 2018 (UTC)[reply]
As it was discussed on the previous discussion, I think every work of art should have its own item. Now how do we define a separate work of art is another matter... Clearly, we need more precised criteria about notability on Wikidata. Regards, Yann (talk) 09:18, 30 August 2018 (UTC)[reply]

Depicts[edit]

File:Pioneer Square, bird's-eye view looking east toward the Pioneer Building, Seattle, ca 1900 (WARNER 620).jpeg

I'm still not clear on how "depicts" fields will work. Let me take this example:

  • Clearly, this depicts Pioneer Place (a tiny park in Seattle at that time, later expanded into the larger Pioneer Square Park by closing the street behind it in this photo) and the four buildings prominently visible on the east side of what was then Pioneer Place.
    • I assume each building would get a "depicts" field
    • Would there be any particular way to indicate that this depicts the park after the erection of the (original) totem pole, but before the File:Pergola.jpg was erected in 1909?
  • Would we have a "depicts" statement for any or all of the following, and would we have something that makes it clear that they are not the central subject of the photo (e.g. this is an unlikely photo if these are what you want to illustrate):
    • Tram tracks
    • Pioneer Square totem pole
    • Alaska Building (visible in the background)
    • Occidental Block (a sliver of which is visible at right)
    • American flag (atop the Lowman Building)
    • Wooden utility pole (or maybe that is prominent enough to be seen as a major topic of the phot)
    • Horse-drawn vehicles
    • Pedestrians
  • And, perhaps heading off into the level of absurdity, but I've seen all of these used as categories on similar photos:
    • a street banner
    • shadows
    • sky
    • terracotta
    • individual shops or other businesses in these buildings at that time
    • individual signs
    • plants
    • awnings
    • power lines

This may seem a bit petty, but when the rubber meets the road all of this needs to be decided one way or another. - Jmabel ! talk 22:27, 29 August 2018 (UTC)[reply]

  • It's not petty to work out the basic principles. Another one is given a photo like File:Ali.jpg whether we can use just "Depicts: Muhammad Ali" (and any photo-relevant details like person wearing a suit and red tie), or do we also add "Depicts: Boxer", "Depicts: American" etc. etc. I.e., will the back-end search software be clever enough to find this image in a search for boxers, even if "Boxer" isn't listed explicitly in the Depicts claim? --ghouston (talk) 04:50, 30 August 2018 (UTC)[reply]
    • All of those can be found by tracing up the hierarchy from the item for Muhammad Ali. This is a different issue: how prominently an object must be displayed in a photo to merit mention as "depicts". An analogous issue for File:Ali.jpg is whether we say it depicts a suit, tie, and handkerchief. - Jmabel ! talk 15:53, 30 August 2018 (UTC)[reply]

Location from which picture is taken[edit]

Only thing I see for this is "Camera coordinate location / Photographer coordinate location". How can we characterize (for example):

  • Views from the 88th floor observatory of the Empire State Building
  • Views from Chesapeake Bay
  • Aerial photographs
  • Satellite photographs

Jmabel ! talk 22:27, 29 August 2018 (UTC)[reply]

We can consider qualifiers such as Altitude, Line string and Angle. Please check the NYPL Surveyor Data Model. It would be helpful to implement this kind of UI for geotagging photographs. Buccalon (talk) 13:51, 31 August 2018 (UTC)[reply]
So we would have no way to say something is a view from a particular body of water, only the ability to indicate this if precise geocoords are known? - Jmabel ! talk 19:16, 10 September 2018 (UTC)[reply]

Exif-like data[edit]

A few points about the fields in this section. Exposure time is given as an item, so you'd need to connect it to an item like "1/400 second" or "23.6 seconds". An enormous number of items would be needed. A number with units would seem like a better match. I'm not sure if that also applies to F-number and ISO speed rating, or if these are constrained enough to create items for each value. "Date of data generation" I assume is the time the digital file was created (e.g., when a digital photograph or a scan is made. A scan may be made of a photo taken at a much earlier time. If Camera model is an item, then Equipment manufacturer is redundant, because it can be put on the item for the camera model. With separate fields, if there were multiple bits of equipment, there'd be no way to link the manufacturers and models into pairs. Each device model will require an item in Wikidata, hopefully they can survive there without being deleted as non-notable (obscure devices may have little information available to put into Wikidata). It's also unclear if devices would be specified as model variants, where known (such as Samsung GT-I9100G) or as "models" like Samsung Galaxy S II. Camera model would be better named "Equipment model" to allow including lenses, scanners, etc. --ghouston (talk) 05:10, 30 August 2018 (UTC)[reply]

Source URL[edit]

There seems to some confusion with regards to the "Source URL" property. It sounds like this page is suggesting that this is the specific URL for retrieving the content of the file (for example, the "Wikimedia import URL" property description says "At import to Commons, this URL should become the Source URL"). However, as mentioned several places (i.e. Commons:Essential_information#Source, etc.), Commons has always been very clear that the source URL should be the link to the web page on which the image or file is displayed (that is, not the web address of the file itself, but rather the web page containing the file). This is because some sites use image hosts/content distribution mechanisms where the URL for the actual file content is often not easily related to the source website, making license verification difficult. In addition, if the source URL does not document the license of the file, Commons asks that a second link to a related page that discloses the copyright license, such as its terms of use, be included. It is, however, not uncommon for editors to include both the URL for page on which the image appears as well as the actual URL from which the content was imported (this is particularly common on GLAM imports). —RP88 (talk) 05:32, 30 August 2018 (UTC)[reply]

You are absolutely right. Thanks for noticing this. I removed that entire row! SandraF (WMF) (talk) 08:01, 31 August 2018 (UTC)[reply]

Another point of attention should be the persistence/durability of these URLs.

  1. It should be encouraged (and facilitated - but how exactly is not immediately clear to me) to use persistent URLs as much as possible. For instance, in the case of Delpher.nl: do not use https://www.delpher.nl/nl/kranten/view?query=hond&coll=ddd&maxperpage=50&identifier=ddd%3A010222459%3Ampeg21%3Aa0086&resultsidentifier=ddd%3A010222459%3Ampeg21%3Aa0086 (non-durable) but rather https://resolver.kb.nl/resolve?urn=ddd:010222459:mpeg21:a0086 (persistent)
  2. In addition - especially for GLAMs/parties that do not issue their own persistent URLs - would it be possible (and desirable?) to automatically submit the source URL to The Internet Archive and (if accepted by TIA) include the persistent TIA-source URL automatically in the file description --OlafJanssen (talk) 09:35, 31 August 2018 (UTC)[reply]

Captions/subtitles on video files?[edit]

For a video file, should we include some boolean to indicate the video is subtitled or not? And should we include a reference/url to where the subtitles (if contained in a separate file) can be found? --OlafJanssen (talk) 09:53, 31 August 2018 (UTC)[reply]

@OlafJanssen: my understanding is that subtitles are a challenge. In order for structured data on file pages to recognize and apply the subtitles, the subtitles would need to be structured as well with metadata. Subtitles don't currently exist that way, and creating a system for working with subtitles - while do-able - would need to be its own feature for this project. As such, if it's something the team is going to work, it's going to be a long time down the road, unfortunately. Keegan (WMF) (talk) 16:36, 7 September 2018 (UTC)[reply]

Properties for identifying "part of," page number, location, etc.[edit]

I have a few questions related to the relationships between files and/or catalog records. Our catalog at the US National Archives is very hierarchical, such that, for example, a given file could be one of many files—in which sequence is important, such as scanned pages from a text document—that are attached to a catalog record that describes that item, but that item also has a parent catalog record (which we call file units), and file units belong to series, and series belong to record groups or collections. So, for that image, I would want to give its digital media identifier, and say it is part of a whole in the sense that it has a particular page number within the document, and that it is associated with that document's catalog identifier. But I would also want a property which allows me to add the catalog identifiers for the document's parent records. It's not clear to me how each of these different fields are supposed to work in Wikidata. Also, this location of the record within the intellectual organization of archival records is separate from the physical location of the records/objects depicted in the scan. For that, we have facility codes and then other specific descriptors, such as container IDs, folder/box numbers or names, and so on (these vary widely depending on the type of material). These should also be able to be represented, I would think. Dominic (talk) 19:48, 11 September 2018 (UTC)[reply]

"creator"-related issues[edit]

In GLAMs, and archives specifically, there is a concept of "creator" as the entity responsible for the collection of records being described. This is different from "creator" as in an individual author or photographer, as it is currently used in Wikimedia Commons, and this has always caused us headaches. Two good examples of how this is different is that most of our individual records—such as a photo taken by the US Army—have no specific listed author or photographer, and that is considered optional, but the agency (in this case the US Army) would be listed as the creator. Even if the author of a record is known and notable, such as a US president, they are not the creator. Another example is a record, such as correspondence received by the president, in which it is actually clear that the "creating" agency did not produce the record itself, but the agency is still considered the creator of the collection (in the archival sense).

See this definition of "creator" from the guide to the DACS standard:

For archival materials, the creator is typically the corporate body, person, or family responsible for an entire body of materials. However, a creator can also be responsible for the intellectual or artistic content of a single item, as in the writer of a letter or the painter of a portrait. A collector or compiler of materials (e.g., Vietnam War memorabilia, letters of presidents of the United States, or materials relating to suffragettes) is considered the creator of the collection.

I am not sure I would be able to accurately map my "creator" field onto the properties here, since they all seem to focus on the producers of the material, but not the collection to which it belongs. Is this perhaps a new property in Wikidata that is required? Dominic (talk) 20:08, 11 September 2018 (UTC)[reply]

virtual statements for EXIF data and similar things[edit]

When working on structured data for Commons initially I thought a lot about what to do with EXIF data. I've been asked to write it down for consideration. I've been thinking about it from two sides. On the one hand we want this data to be available in the same way as all the other data for consumers - same APIs etc. It should look/feel/behave the same way as if it were a statement. On the other hand we don't want to have to duplicate all the information just to have them in regular statements. That'd be a maintenance nightmare. On top of all that you want to be able to correct this data in case it is wrong. So the idea my team and I had was that we'd introduce a new concept called virtual statements. They'd be taken automagically from the EXIF data and shown as if they were real statements but they'd not cause any maintenance. You could also add proper statements for any of the virtual statements in order to overwrite them. My team and I have not done any work to make this happen but I believe it is worth investigating further if this is feasible. We might need similar mechanisms also for lexicographical data on Wikidata. --Lydia Pintscher (WMDE) (talk) 10:16, 16 September 2018 (UTC)[reply]

Being able to query the original Exif data is desirable. I had the impression it was stored in a format which isn't very amenable to direct queries (an array coded into a single SQL text field, or something), which is why I was thinking it would all need to be copied into structured data fields. However, if such technical difficulties can be overcome, then what you are suggesting seems fine to me. --ghouston (talk) 07:18, 17 September 2018 (UTC)[reply]

Images from articles[edit]

Is there a property for indicating that an image comes from an article that has its own Wikidata item? Would this be covered under "part of..."? Or "source (website)"? Personally, I would look for this under "source". --Sohmen (talk) 12:00, 17 September 2018 (UTC)[reply]

Hi, I am not sure what you want here. Each image needs a source, but the source isn't an article. And there are articles about iconic photos, i.e. the articles are about the pictures themselves. Regards, Yann (talk) 12:25, 17 September 2018 (UTC)[reply]
I am talking about articles that contain images, for example scientific articles that use CT images to illustrate their research. Those articles are definitely the source of those images, if that is the first place where they were published.--Sohmen (talk) 12:48, 17 September 2018 (UTC)[reply]
Currently we don't do that in any systematic way, but it is perfectly possible to link to a Wikidata item somewhere in the source or description section of the Information template: use {{Q}}. Still, it's more common to link to a Wikipedia article (about the scientific article), if that exists. - Jmabel ! talk 16:12, 17 September 2018 (UTC)[reply]
I see, you are talking about being able to have the structured data handle this; yes, I suppose that a property for this would be a good idea. Really no different than a book that is a source, though. - Jmabel ! talk 16:15, 17 September 2018 (UTC)[reply]

Type[edit]

  1. There are three properties that describe the image type: Type of media file , File format and Mime Type and they overlap a lot. Is mime type really necessary since this information is mostly covered by the other two properties?
  2. A content-related image type could be useful. For example, an image could be a scan, or a drawing or a photograph. --Sohmen (talk) 12:00, 17 September 2018 (UTC)[reply]
A file can't be a drawing, it can only be a scan or a picture of a drawing. Regards, Yann (talk) 12:27, 17 September 2018 (UTC)[reply]
Would adapt / extend genre (P136) for this case. It seems to me to be most suitable and generically applicable. --Inablu

A minor whinge[edit]

It would be nice for us Antipodeans, if wikipedians in the northern hemisphere could refrain from using phrases such as "Summer 2018", "Fall 2017" when they are referring to a time in the northern summer of 2018, or the northern autumn of 2017, and replace the seasonal term with a month of the year.... (This is meant to be a universal encyclopedia. It would be nice not to always have to translate.) MargaretRDonald (talk) 23:19, 17 September 2018 (UTC)[reply]

I think we are not using it on commons so much. We moved from summer to June, July and than we place such categories to years.--Juandev (talk) 18:43, 19 September 2018 (UTC)[reply]

Date of upload[edit]

Is inception (P571) with qualifier really a good idea? I think a separate property would be warranted for the Commons upload date, since every file could have this data, and it only applies to a specific instance of a work (the copy hosted on the WMF servers) whereas almost all other statements would refer to the work in general. Jc86035 (talk) 16:43, 22 September 2018 (UTC)[reply]

source website[edit]

I see the closest Wikidata property to 'source website' as d:Property:P854. It's English description is 'should be used for internet URLs as references.' John Samuel (talk) 11:07, 23 September 2018 (UTC)[reply]

Mapping to the CIDOC Conceptual Reference Model + feedback from that community[edit]

One of the researchers working on the CIDOC Conceptual Reference Model (an ontology / data model used in the museum sector) has looked at the preliminary properties table, and has provided a draft mapping to CIDOC CRM. Hopefully this is helpful for future cases where museums want to contribute media files to Commons and want help in mapping their metadata model to ours!

The mapping table also includes some specific feedback (see the column on the right). The most important point there: it is very important to keep a crisp and clear distinction between metadata of a digital file and of the thing that is depicted/represented in it; if we don't do that from the start, we will run into major problems soon. Not a new remark, but it's good to hear it from this perspective too, IMO. Cheers! SandraF (WMF) (talk) 12:38, 29 September 2018 (UTC)[reply]

See comments on the corresponding talk page. Jheald (talk) 18:02, 29 September 2018 (UTC)[reply]

Edit summaries for property changes.[edit]

I'm not sure if this is right page for this discussion, but one concern I have is if Commons will lose the ability to have an "edit summary" associated with changes to important information (such as licensing) once that information is in the structured data as properties. Will an "edit summary" be supported when using the GUI to edit Commons structured data? Currently on Wikidata this is not available. However, I think it would be a real problem on Commons if there is no supported method of including a reason for a change to the licensing information (I suppose we could insist that every important edit to the structured data be accompanied by a note on the file talk page, but that is definitely suboptimal). —RP88 (talk) 20:51, 7 October 2018 (UTC)[reply]

+1 - Jmabel ! talk 23:15, 7 October 2018 (UTC)[reply]

P361 = P179?[edit]

Part of series/whole (subject is part of a series, the sum of which constitutes the object) = part of (object of which the subject is a part)? For example, d:Q11215 (Windows 7) is "subject is part of a series, the sum of which constitutes the object" (d:Q486487, Windows NT)? Or "object of which the subject is a part"? Fractaler (talk) 11:03, 12 October 2018 (UTC)[reply]

"Part of" is homonym (Q160843), "part of series" is not[edit]

Feedback from Europeana[edit]

Here are our (Antoine Isaacantoine (talk) with review and additions from Federica) notes. Some of the points we made echo the ones from other Wikimedians already on this page.

Mixing different levels of depiction[edit]

(Applies to 'Depicts / Manifestation of / Digital representation of', 'Language' and several other properties).
I'm worried that the same property would be used for saying that a painting that depicts a person and that a photo depicts this painting. In the current approach, the resources standing for digital files 'carry' description of the cultural object itself depicts (a person, a place). I understand (in 'Qualifiers for things depicted in a file') that your intention is to represent these statements as qualifiers to a 'depicts statement'. But I'm really not sure it will be enough to convey a clear message. And this 'mixing of levels' should absolutely be avoided. It has plagued the metadata that Europeana receives, for years.

From a cultural/metadata perspective, the distinction deserves using a different property, or subjecting the same property to clearly distinct resources, i.e. following the 'one-to-one-principle'. Not doing the latter is especially puzzling when the flexible Wikidata environment enables you to treat the situation with an appropriate level of granularity. I.e., there can be two resources, one for the digital representation of a cultural object, which is itself treated as another resource, and there's no overlap between the sets of statements that apply to both resources.

This is a better way to help ensure for example that your 'Institution's media file identifier' is not "confused with identifiers for creative works", a risk that you've correctly identified. If a resource can have properties for the level of a media file and properties for the level of the represented work, then it's sure people will misuse your 'Institution's media file identifier'. A similar benefit of separing levels is expected for the 'Creator' property, which otherwise would become quite polluted, with Leonardo da Vinci creating thousands of JPEGs...

I understand the fear that this create an awful lot of extra resources in Wikidata, many of them not being obvious cultural works at first. Perhaps the extra resources could be 'parked' in a special area of Wikidata/Wikibase, where less notorious resources would be parked. In any case, having all these qualifiers does not make the situation technically much simpler or lightweight. And again, it is conceptually (and practically) confusing.

By the way, relying on full separation of levels would allow you to get rid of the 'Qualifiers for things depicted in a file' table. It seems much easier to just rely on the patterns being defined in the cultural communities that define these lists of relevant properties for various kind of cultural works. Do you really want to (re-)define what 'After' would mean in different context and which property to create for representing it?

'Depicted place' and 'Depicted event'[edit]

It seems better to rely on a general 'depicts' property and a proper typing of the object of the statement as place or event. This makes queries about the subject of a work easier to formulate. And indirectly it also helps enforcing that the objects of statements are properly typed. Anyway, hopefully as per the comment above (Mixing different levels of depiction) you will just get rid of these two properties.

'Depicted date' and 'Depicted period'[edit]

I understand the meaning of these properties, but the labelling reads really strange, when the elements have no visual aspect. Other expressions like 'temporal coverage' may be easier to communicate to the cultural heritage community. Anyway, hopefully as per the comment on 'Mixing different levels of depiction' you will just get rid of these two properties.

Part of series/whole, Series ordinal, Follows, Followed by[edit]

In relation with the issue above (Mixing different levels of depiction), I assume that the definitions in Wikidata of these properties to represent sequences will not enforce reading the media resource as 'cultural-work-level resources'.

'Specific for maps'[edit]

In relation with the issue above (Mixing different levels of depiction), I believe that the two properties (Spatial reference system, Bounding box) are not to the level of a media file and should be used on another resource in Wikidata.

'EXIF(-like) data' vs 'Two-dimensional images'[edit]

We are puzzled to see properties for (digital) photographs in two different tables. We can understand the rationale behind them, but still it doesn't make for an easy discussion and paves the way for redundancies. Or maybe the properties in the 'Two-dimensional images' table are actually not for 2D images only? 'coordinates' and 'view direction' are relevant for (some) audio-visual files. Furthermore, 2D images table contains a combination of properties at different level of representation. For example, I would advise to not combine a property such as “depicts” with technical features such as “resolution”.

'Read-only reflections of primary data held elsewhere' vs. media-specific tables[edit]

(e.g., '3D') vs. a new general media property table.
Caring about subtle aspects of provenance (such as derivation/extraction links) may encourage to have a table like 'Read-only reflections of primary data held elsewhere'. But I would recommend to get rid of the distinction, now. This table include properties that apply to any media file, even if it would exists only in Wikimedia Commons. For example, the MIME type should be better merged with the one in one in the 3D table.
Using the same example (MIME file) I would recommend to create a table that lists the elements that are common to all types of media files, and not hint that MIME type applies only to 3D.

Completeness of property coverage[edit]

I cannot really say whether the properties in the current set of tables is complete wrt your needs. But if you seek inspiration from Europeana, the list of what EDM has for (online) media files is at Github: "EDMObjectTemplatesEuropeana

NB: these are raw listings, we have more complete documentation in PDFs at edm-documentation. Feel free to ask if you have specific questions!

Quality assessment[edit]

The implementation of this property would require the definition of a data quality framework where a sort of ranking can be established. Is something like that available for Wikidata?

Thank you.
Published on behalf of the authors (above) by Wittylama (talk) 19:12, 6 November 2018 (UTC).[reply]

Location Information[edit]

I think as addition to coordinate location (P625) there should be more information about the location with properties like located in the administrative territorial entity (P131), what could be used for every image which has coordinate location (P625) and in some cases with more specific properties like located in protected area (P3018). --GPSLeo (talk) 14:29, 23 December 2018 (UTC)[reply]

Meaning of 'User'?[edit]

The row "creator (P170)" has a Data Type of "Item or 'User'".

What does "User" mean technically here?

Is it just the 4 characters string? Or is there a data type that represents a Mediawiki user account?

Thanks! Syced (talk) 15:59, 9 February 2019 (UTC)[reply]

I think it's a URL, for a Commons user, Flickr user, etc. --ghouston (talk) 23:47, 9 February 2019 (UTC)[reply]
OK thanks! I am writing an upload tool that requires people to have a Wikimedia account, so I guess I will always set that value to "https://commons.wikimedia.org/wiki/User:" + username (even if the user page does not exist). Syced (talk) 08:41, 10 February 2019 (UTC)[reply]

What is "Media legend"? Captions seem to make it redundant[edit]

What is the row "Media legend - media legend (P2096) - Monolingual text - Media item's caption " in the first table?

If it is not a duplicate of Commons captions, how does it differ?

Thanks! Syced (talk) 12:55, 10 February 2019 (UTC)[reply]

In Wikidata if you set and image you can have there a plain text description also, so why not to duplicate Caption elsewhere? Juandev (talk) 04:42, 1 August 2019 (UTC)[reply]

Language of A/V content[edit]

So... what if the the language of the imagery (say presentation slides) in the video is English, but the language of the audiotrack is spanish... and the language of the onscreen captioning (so not our own TimedText subs) is French... Thoughts ? —TheDJ (talk • contribs) 09:53, 21 June 2019 (UTC)[reply]

@TheDJ: applies to part (P518) qualifier? Jheald (talk) 10:31, 21 June 2019 (UTC)[reply]

Copyright / country[edit]

We are usually concerned with both U.S. copyright status and copyright in country of origin. Of course, for U.S. pictures these are one and the same, but can someone give a clear example of how one might model, for example, that something is PD-ineligible in the U.S. because it is below the threshold of originality by U.S. standard, and is old enough to be out of copyright in its country of origin? - Jmabel ! talk 02:08, 1 August 2019 (UTC)[reply]

Some of the properties doesnt work[edit]

For example I typed P170 to the search row on the file and it came with No results found. What might be the cause? Juandev (talk) 04:41, 1 August 2019 (UTC)[reply]

Wiki loves monuments and similar[edit]

Currently the recommendation for capturing that an image took part of e.g. WLM is to use a new property Wikimedia campaign/project (to be created). I think its worth making a distinction between images created as part of a wikimedia project (e.g. a photowalk) amd images participating in a (albeit wiki) competition (WLM/POTY). In the latter case the creation of the image need have nothing to do with the competition/campaign. For competitions there is already participant in (P1344) and a qualifier (ranking (P1352) or award received (P166)) on the value could then be used to indicate how the file did (finalist, top 10, winner etc.) . So e.g. Mahasu Devta, Hanol. Uttarakhand.jpg would have participant in (P1344):Wiki Loves Monuments 2018 in India (Q56404102)->award received (P166):winner (Q18560095). /Lokal_Profil 17:47, 19 August 2019 (UTC)[reply]

Depicted place[edit]

How you want to set depicted place in general via Depicts? Cannot we use located in the administrative territorial entity (P131) or other properties for that. I think the specific indication of depicted place is very important. Juandev (talk) 13:25, 5 September 2019 (UTC)[reply]

Photographer[edit]

For the photographer, we need to create analog to author name string (P2093), where you can type in Author of the text and the value is the simple text. I dont expect that most of the Wikimedia Commons photographers, would have their item on Wikidata.Juandev (talk) 13:33, 5 September 2019 (UTC)[reply]

Hi, I thought the objective was to have them in the Wikibase on Commons. Did the plan change? Regards, Yann (talk) 10:05, 6 September 2019 (UTC)[reply]

Well I dont know, I thought that we couldnt have extra properties than on Wikidata. Juandev (talk) 13:52, 6 September 2019 (UTC)[reply]

Properties for telling this is a picture of the buildings front or the back[edit]

I guess one user case is 

find me all pictures of a building showing the back of the building

- Salgo60 (talk) 02:06, 22 September 2019 (UTC)[reply]

Qualifier depicted part (P5961) is available. Jheald (talk) 12:56, 22 September 2019 (UTC)[reply]

Is P859 really proper for "Created with support by"?[edit]

On that property page I can see 3 "instance of" (P31) values: Wikidata property related to sports people (Q28106456), Wikidata property related to sport organizations (Q22964372) and Wikidata property related to sports events (Q28106586) which means that this is a sport-related property, I wonder if this is really suitable for non-sport stuffs or not. --Liuxinyu970226 (talk) 12:04, 29 November 2019 (UTC)[reply]

Property proposal[edit]

Hi, I made a proposal that may be somewhat relevant for Wikimedia Commons, Wikidata:Wikidata:Property proposal/GBIF occurence ID, but as the potential use in Commons was not my firt goal it is not listed in Wikidata:Wikidata:Property proposal/Commons, therefore this message is a kind of notification. Regards, Christian Ferrer (talk) 15:50, 16 August 2020 (UTC)[reply]

Is it OK to add P854 source url values?[edit]

Hi, is there currently a proper way to add source url OR collection+identifier information as a structured data? My usecase is just to store stable (external) identifiers to files so these can be read over sparql. --Zache (talk) 07:18, 27 December 2020 (UTC)[reply]

Answer was to use described at URL (P973) per Commons_talk:Structured_data/Modeling/Source --Zache (talk) 05:41, 23 January 2021 (UTC)[reply]

Major excision[edit]

I disagree with this major removal of content by User:Schlurcher. Much of what was removed seems to me to be potentially useful, and this was done without discussion. I can see marking things that appear not yet to have been implemented, but simply removing them here amounts to burying them forever, which is not a decision that should have been taken by a single user, no matter how experienced. - Jmabel ! talk 15:01, 18 July 2023 (UTC)[reply]

Hi, I'm actually trying to transform this page (which is currently in the archive, i.e. not in active use) into to a usuable new format. My ultimate goal is to have a summary of already used properties (to be added, based on [1]) and a summary of properties that were proposed. For now I've mainly removed properties that have already been defined in Commons:Structured data/Modeling (or contradict what is described there) or properties proposed on wikidata that were not generated for that purpose. Could you highlight the ones that are worth beeing kept, so we can add them back in? -- Schlurcher (talk) 16:52, 18 July 2023 (UTC)[reply]
@Schlurcher: as long as you intend to put these somewhere that they'll continue to be visible, that's all I'm asking. What I was afraid of was a situation where the only way to find the information was to search the history, which I'm sure you know very few people do.
That said:
  • I'm rather amazed "series ordinal" hasn't been implemented, I can think of a ton of places it would come in handy.
  • Difference in numbering of pdf and scanned text seems quite likely useful.
  • I'm rather surprised that neither alt text (P11265) nor anything of the sort seems to be in the list, but it looks like it wasn't there before, either
- Jmabel ! talk 18:53, 18 July 2023 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:Structured_data/Properties_table&oldid=784513297"