Wikidata:Property proposal/Sister projects


Property proposal: Generic Authority control Person Organization
Creative work Place Sports Sister projects
Transportation Natural science Lexeme

See alsoEdit

This page is for the proposal of new properties.

Before proposing a property

  1. Check if the property already exists by looking at Wikidata:List of properties (research on manual list) and Special:ListProperties.
  2. Check if the property was previously proposed or is on the pending list.
  3. Check if you can give a similar label and definition as an existing Wikipedia infobox parameter, or if it can be matched to an infobox, to or from which data can be transferred automatically.
  4. Select the right datatype for the property.
  5. Start writing the documentation based on the preload form below and add it in the appropriate section.
Caveat
Do not use the Visual editor, because it will mess up the content of your request (the order of the template parameters will be shuffled and paragraphs are concatenated as one long string of text).

Creating the property

  1. Once consensus is reached, change status=ready on the template, to attract the attention of a property creator.
  2. Creation can be done 1 week after the proposal, by a property creator or an administrator.
  3. See property creation policy.

  On this page, old discussions are archived. An overview of all archives can be found at this page's archive index. The current archive is located at 2022/05.


WikipediaEdit

WiktionaryEdit

WikiquoteEdit

WikisourceEdit

WikivoyageEdit

WikinewsEdit

WikiversityEdit

WikibooksEdit

WikispeciesEdit

See Wikidata:WikiProject Taxonomy; Wikidata:Wikispecies; wikispecies:Wikispecies:Project Wikidata

Wikimedia IncubatorEdit

Wikimedia CommonsEdit

alt textEdit

   Under discussion
Descriptionalternative text used when an image can't be rendered or when accessed from assistive technology such as a screen reader
Representsalt text (Q60844786)
Data typeMonolingual text
DomainCommons image
Example 1File:Ansel_Adams_and_camera.jpg » "Black and white photograph of a man with a tripod-camera and a pine tree in the background."
Example 2File:Apollo_11_Crew.jpg » "Three men in white spacesuits without helmets in front of an image of the moon."
Example 3File:Panthera_tigris_altaica_13_-_Buffalo_Zoo.jpg » "Tiger cub in from of a mature tiger in snow."
Planned useUsage in various tools as well as on Wikimedia Commons and Wikipedia.
See alsoformer proposal for Wikidata

MotivationEdit

This will allow editor to specify an alt-text(alternative text which describes the visual features of an image) for images on Wikimedia Commons which can then be reused by various projects and tools to set an alt-attribute. See the tickets below and the previous proposal.

See Phab:T166094 and Phab:T213585 Abbe98 (talk) 20:09, 20 February 2021 (UTC)

DiscussionEdit

  •   Support Good idea! Thanks for explaining the process. Jane023 (talk) 20:16, 20 February 2021 (UTC)
  •   Support --Lectrician1 (talk) 01:29, 21 February 2021 (UTC)
  •   Support   Don't ping me NMaia (talk) 10:36, 21 February 2021 (UTC)
  • Strongly oppose per discussion in the previous proposal, and Phab. tickets, since when nothing of significance has changed. As I said in the first Phab. ticket - and as I advised the proposer, in the second - "Please do not progress this proposal without first consulting with screen reader users and/or accessibility professionals." It appears this had not been done. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:16, 21 February 2021 (UTC).
    Please provide some constructive feedback rather than repeating a statement that questions others expertise. I have worked professionally with web accessibility. Also note that this is not about implementation of alt-text but about a way to store generic alt-texts. Abbe98 (talk) 15:04, 2 March 2021 (UTC)
    Oh FFS. I have provided plenty of constructive feedback on past iterations of this benighted proposal. I am sick of people trying to wear down sensible and reasoned opposition including that by colleagues who are blind and use assistive technologies like this. I too have "worked professionally with web accessibility" - that doesn't make me an "accessibility professional" and nor does it make you one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:57, 2 March 2021 (UTC)
  •   Comment From the domain in the proposal, I note this is limited to Commons (not for use on Wikidata itself). So from Wikidata's POV, there isn't really any reason not to create this. It seems that Monolingual text properties are now possible on Commons [1], so technically, this could be implemented. Maybe the property description could recommend reading some help text that explains how to write alt texts. --- Jura 11:31, 21 February 2021 (UTC)
  •   Support This really is common sense but in any case I asked some people with relevant expertise to comment. (Andy you might want to explain or link to your objection to make it easier for them to assess it.) I'll also note that there are various places where we cannot add alt text currently (category pages, image description pages, generated reuse snippet etc) and this proposal would help with that; the benefits would not be limited to fallback alt text in articles. Also, having a large corpus of well-described images might have value of its own for developers of assistive technology. --Tgr (talk) 15:19, 21 February 2021 (UTC)
    • The links are in the proposal. this is now the fourth discussion in which I have had to state them, in this context. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:14, 21 February 2021 (UTC)
  •   Comment I imagine the eventual data type of this property would be multilingual text, but for the time being it should be created as monolingual, as done for other properties. --Tgr (talk) 15:26, 21 February 2021 (UTC)
    • Please keep in mind, that screenreaders would read out monolingual content not marked via appropriate `lang` attribute in the respective language wiki wrongly. --Volker E. (WMF) (talk) 21:38, 22 February 2021 (UTC)
  • "planned use = Usage in various tools as well as on Wikimedia Commons and Wikipedia." (my emphasis) Wikipedia is an encyclopedia and only includes an image for the information that the image provides to the reader that is relevant to the article . It's not there to make the page look pretty. On Wikipedia, images are almost invariably accompanied by a caption that supplies additional information not apparent from the image. It is the combination of alt text and caption that makes up the alternative text for the image. That means that the alt text is context dependant and cannot be prescribed from a central location. If you place File:Washington and Lafayette at Valley Forge.jpg in an article about en:Valley Forge, it doesn't matter that there are two officers with red capes and five soldiers, but it's important to say that it's winter. If you put it into an article about en:George Washington, it doesn't matter what colour the horses are, but it probably does if it's in the article about en:Nelson (horse) (he's the one on the left). If you want to annoy screen reader users, put File:Ansel Adams and camera.jpg into the en:Ansel Adams article with the alt text suggested as an example. Try explaining to them what relevance "a pine tree in the background" has to his article. Was he notable for standing in front of pine trees? By the way, the suggestion here would still be an improvement over the abomination actually used in his article ("the open shirt collar is spread over the lapel of his jacket" - suitable for a fashion magazine, not for an encyclopedia). --RexxS (talk) 02:05, 23 February 2021 (UTC)
This is all very true and I believe it important to note that this proposal is only a proposal to have a way of storing generic alt-texts. Wikipedia might choose to somehow use this and it might also choose not to. In my opinion Wikipedia editors and should always be in control of the alt-texts in articles. Abbe98 (talk) 15:00, 2 March 2021 (UTC)
  • Oppose as a screen reader user – nothing's changed since last time. Graham87 (talk) 06:16, 23 February 2021 (UTC)
  •   Oppose on philosophic grounds, and per views of previous opposers. I don't like Wikidata increasingly building itself as "the one true God" of all that is Wikimedia. Context matters in alt text as well as captions (as described at en:Wikipedia:Manual of Style/Accessibility/Alternative text for images). What happens on Wikidata (or Commons) need not necessarily be reflected in every source that uses Wikidata data (or Commons media). Poorly curated infoboxes will accept whatever is pumped into them from Wikidata, regardless of relevance. The existing media legend (P2096) for example often results in a redundant, unhelpful and/or arbitrary foreign language caption in Wikidata Infobox (at least when implemented on Commons), unless one adds an arbitrary legend in their preferred language. No matter how well the intentions are, the more centralized and prescribed data presentation becomes, the harder it becomes to maintain local control on individual articles, infoboxes, and whatever third-party sources draw from Wikidata. Someone will probably eventually make a bot that registers all incongruences between local and Wikidata values as "errors", giving some other bot operators incentive to wrongly "fix" them. -Animalparty (talk) 01:41, 24 February 2021 (UTC)
    • Too bad you didn't bother reading the proposal .. contrary to previous ones, it's not for Wikidata, but Commons. --- Jura 10:38, 24 February 2021 (UTC)
      • Why then is it being proposed and discussed on Wikidata instead of Commons? -Animalparty (talk) 16:53, 24 February 2021 (UTC)
        • Because Commons has no property namespace. --- Jura 17:01, 24 February 2021 (UTC)
  •   Support Very good! This will facilitate translations, make pictures better searchable and provide material for the developers of image description AI. Most of all it will make it more effective to provide images with alt texts. Regarding the context issue: In my opinion, the image related text form that should deliver the context is the CAPTION. Context is necessary for ALL users. So it should be readable for everybody, but alt text is only readable for screenreaders or when image display is disabled by the browser. Alt text should only replace the VISUAL CONTENT of the image. It should tell those who cannot see the image what people who can SEE. In Wikipedia every image has FIVE image related text forms: Name, caption, alt text, image description, article. The caption changes from article to article so it should give the context. The longer image description does not change but since its longer it can be sensitive to different possible contexts. The alt text should change as little as the image's file name. It's not necessary and would be even redundant if the alt text would repeat the caption. KH32 (talk)16:39, 25 February 2021 (UTC)
    • @KH32: A user who is blind and who uses assistive technology and relies on alt text attributes commented against the previous proposal, explicitly on the basis of context; and reiterates their opposition here. Can you explain the basis on which you have a better understanding of this matter than they do? And can you explain how this will make images "better searchable" than the proper use of "depicts" statements will? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:57, 2 March 2021 (UTC)
    • @Pigsonthewing:I am speaking for the group of blind and sighted people of our Photo Studio for Blind Photographers in Berlin. We are working with picture descriptions since 2011. But that doesn't mean that we have automatically the better understanding in this particular question. The reasons why we disagree in the question of context in alt texts are just as I tried to state them briefly. Regarding your second question what do you mean by "depicts" statement? KH32 (talk)18:59, 02 March 2021 (UTC)
    • @Pigsonthewing: Ah that alt texts = alt tags make pictures better searchable is because "Google uses alt text along with computer vision algorithms and the contents of the page to understand the subject matter of the image."(Google) KH32 (talk)19:17, 02 March 2021 (UTC)
  •   Oppose if this should be implemented, it shouldn't be implemented as a property, but using the empty "descriptions" array, see phab:T166094.  – The preceding unsigned comment was added by Multichill (talk • contribs) at 18:56, 3 March 2021 (UTC).
    • @Multichill: care to argue (here or on the task) why? --Tgr (talk) 10:35, 5 March 2021 (UTC)
  •   Support to provide a default, and as alt-text for the Commons information page; and for when the image appears without context, for example on a wikidata page. Where the image appears elsewhere, make sure there is provision to override the alt-text locally. Jheald (talk) 22:51, 3 March 2021 (UTC)
  •   Comment On the Phabricator task, User:FRomeo (WMF) says: We're thinking of organizing a workshop on this topic, with accessibility consultants, people with lived experience, the WikiBlind user group, and anyone else who is interested. - which sounds to me like the best way forward for this proposal. --Tgr (talk) 10:35, 5 March 2021 (UTC)

"beforehand owned by" & "afterwards owned by"Edit

beforehand owned byEdit

   Under discussion
Descriptionperson or institution that owned the subject just before stated event. Aliases: acquired from, bought from, purchased from, seller
Representsproprietor (Q16869121)
Data typeItem
Template parameterc:template:Template:ProvenanceEvent "oldowner"
Domainitems work of art (Q838948)
Allowed valuesperson (Q215627), organization (Q43229)
Example 1At Girl with a Pearl Earring (Q185372):
significant event
  purchasing
point in time 1881
beforehand owned by Arnoldus Andries des Tombe
0 references
add reference


add value
Example 2At The Bohemian (Q1000128):
Example 3At The meeting of Jacob and Rachel (Q53673495):
Planned useLook through items which use of (P642) qualifier of significant event (P793) to see if we can fix some of the ambiguous statements by replacing of (P642) with the new properties. I would also rewrite c:Module:Wikidata art's "get_object_history" function used by c:Template:Artwork.
See alsoowned by (P127), significant event (P793), of (P642) (might get depreciated)
Distinct-values constraintno
Wikidata projectWikiProject Painting (Q14942930)
Proposed byJarekt (talk) 03:54, 14 February 2022 (UTC)

afterwards owned byEdit

   Under discussion
Descriptionperson or institution that owned the subject after stated event. Aliases: acquired by, bought by, purchased by, buyer
Representsproprietor (Q16869121)
Data typeItem
Template parameterc:template:Template:ProvenanceEvent "newowner"
Domainitems work of art (Q838948)
Allowed valuesperson (Q215627), organization (Q43229)
Example 1At Mona Lisa (Q12418):
significant event
  acquisition
point in time 1519
afterward owned by Francis I of France
0 references
add reference


add value
Example 2At The Bohemian (Q1000128):
Example 3At Bridge in winter (Q79041853):
Planned useLook through items which use of (P642) qualifier of significant event (P793) to see if we can fix some of the ambiguous statements by replacing of (P642) with the new properties. I would also rewrite c:Module:Wikidata art's "get_object_history" function used by c:Template:Artwork.
See alsoowned by (P127), significant event (P793), of (P642) (might get depreciated)
Distinct-values constraintno
Wikidata projectWikiProject Painting (Q14942930)
Proposed byJarekt (talk) 03:54, 14 February 2022 (UTC)

MotivationEdit

When describing provenance of artworks one of the most useful properties on Wikidata is significant event (P793), while on Commons we model it with c:Template:ProvenanceEvent template. One challenge with P793 property is that different types of events require different set of qualifiers to fully describe the event. Some events can be well modeled with the existing properties (like bequest (Q211557) or art theft (Q1756454)), however the most often used group of events which describe some form of change of ownership (for example change of ownership (Q14903979), significant event (P793), sales (Q194189), auction (Q177923), purchasing (Q1369832), trade (Q601401), etc.) do not have usable properties for describing old and new owners. As a result, many artworks are missing this most basic information about the event, or items use badly fitting existing properties resulting in unclear statements open to interpretations.

Some examples of such confusing or statements:

At Mona Lisa (Q12418)
significant event
  acquisition
point in time 1519
of Francis I of France
0 references
add reference


add value

where "of (P642)" property is used to specify either seller or the buyer. In above case it is a buyer, but at almost identical statement for The meeting of Jacob and Rachel (Q53673495) it is a buyer. I am not sure of other languages but in English it seems like we are talking about "acquisition" "of" that person.

At Girl with a Pearl Earring (Q185372)
significant event
  purchasing
point in time 1881
owned by Arnoldus Andries des Tombe
price 2 Dutch guilder
0 references
add reference


add value

where owned by (P127) property is used to specify the owner either before or after the transaction, but it is not clear which one.

So the motivation for those properties is to

  • be able to accurately models statements like "Acquisition method: purchased from Thomas Agnew and Sons Ltd, 1937"[2], which is currently not possible
  • to fix previously added ambiguous statements
  • to provide better mapping between Wikidata's data model and the way we model the same data since 2009 using c:Template:ProvenanceEvent on Commons and allow better use of Wikidata resources by c:Module:Artwork and other projects
--Jarekt (talk) 05:22, 14 February 2022 (UTC)

DiscussionEdit

  •   Support A question might be: how much of this is redundant to owned by (P127), or could be done via that property. But I think these two new properties would be much neater, notably for modelling 'provenance events' where we have a particular pattern of data.
    Yes, a "beforehand owner" should also be indicated by owned by (P127) + end time (P582) + end cause (P1534), and some people won't like that redundancy. But IMO, when we have data about a particular sale event, it is useful to be able to pull that together on a single statement, together perhaps with additional information like venue or auctioneer. Yes, perhaps one might be able to infer from "X owned the portrait until ..." + "Y owned the portrait from ...", that X had sold it to Y. But that might be an inference that might be wrong, because the actual chain might have been, X sold it to dealer A, who sold it at auction to dealer B, who sold it privately to Y.
    So having the information of the actual transfer in a single significant event (P793) statement is useful, I think, and does seem more secure and a more sure way of modelling things, than trying to draw inferences from owned by (P127) statements even when apparently successive. I therefore support these two properties, as together creating a useful neat and tidy model for such transaction events. Jheald (talk) 16:00, 14 February 2022 (UTC)
    • Agree to this whole analysis that it can create some redundancy, but is still useful. --Marsupium (talk) 08:42, 7 May 2022 (UTC)
  •   Comment Provenance is complicated so thanks for adding these proposals and spelling out issues with Commons templates that I heavily use but which are still a mystery to me. I suspect this conversation can better be had over at Wikidata:WikiProject Provenance, which I set up to gather such questions and answers. Despite the desire to place provenance events in a distinct timeline, I doubt it’s always possible to do with “before & after” context in a verifiable way that would make such properties useful. In the end we would like to use dates as much as possible but for inheritance chains it would be nice to be able to do those “by inheritance” handoffs semi-automatically. Jane023 (talk) 15:50, 15 February 2022 (UTC)
Jane023, Thanks for alerting me about Wikidata:WikiProject Provenance. I did a lot of digging about current providence modeling, but never run into it. --Jarekt (talk) 02:58, 20 February 2022 (UTC)
  • I had to dig a bit to find Wikidata_talk:WikiProject_sum_of_all_paintings/Archive/2020#Refining_provenance_events, nothing really happened so thanks for bringing this up again. This is a more generic problem. We have events that involve multiple actors, one persons sells and the other buys. That's both the same event. This proposal seems to be too limited in scope. Probably needs more refinement. Maybe we can have a look how this gets modeled in other place? So   Oppose for now to prevent premature creation. Multichill (talk) 21:05, 16 February 2022 (UTC)
    • Multichill, I am fine with refinement if there are some other ideas. Those 2 properties were based on how we were modeling it on Commons for the last decade, but I am open to alternative proposals. One think I would like to avoid is postponing this discussion for next number of years, because people are trying to model it now and the results are incomprehensible . A lot of provenance data you can find for artworks is an array of ownerships punctuated by change of ownership events. So we can model it either by owned by (P127) with the 2 book-end events or by significant event (P793) with before and after owners. I doubt you can find other approaches, but I am OK with wider discussion on how to model this (perhaps at Wikidata:WikiProject Provenance), before we proceed. --Jarekt (talk) 02:58, 20 February 2022 (UTC)
        Comment Multichill, Jarekt: To "Maybe we can have a look how this gets modeled in other place?" (repeating myself from here where Jarekt considere these properties in 2018 already): "They would be similar to CIDOC-CRM's P22 transferred title to (acquired title through) and P23 transferred title from (surrendered title through)".
      I think this is a good proposal, I think I want support it, but want to have a look into the CIDOC-CRM solution another time and read the full discussion here before. Are there more specific, good reasons against the properties, also considering the "postponing this discussion for next number of years"?? Best, --Marsupium (talk) 07:56, 30 April 2022 (UTC)
  •   Comment same as Jane023 and Multichill. Additional to Jane023 there are not only heritage chains but also sales-chains and combined chains by sales, heritage, gift and bequest. So we have to model credit line. And we have Wikidata_talk:WikiProject sum of all paintings/Archive/2021#Provenance, continued. There is also a need to express on loan; --Oursana (talk) 12:19, 18 February 2022 (UTC)

@Jarekt, Jheald, Jura1, Jane023, Multichill: I just want to give you an example with gift, which in my opinion works fine with owned by (P127) and gift: Statue of Venus (Q98784999). "previous owner" / "subsequent owner" can also be expressed by date and series ordinal (P1545). In my example I would rather delete significant event (P793)--Oursana (talk) 19:19, 12 March 2022 (UTC)

  • One of the main points was to reduce the use of "of" in significant event. In this case Oursana you have used significant event to show that Louis XV gave it as a gift in 1750. I added this the same way I have been doing for bequests, with donated by (P1028) with qualifier point in time (P585). To indicate reception, I added the qualifier start time (P580) to the relevant collection (P195) statement. It's still missing a location (P276) statement. Just saying "we need to model the credit line" is much more complex than adding a 'credit line' property or making a 'credit line' significant event. Jane023 (talk) 10:03, 13 March 2022 (UTC)
    • Please see also my changes to the example item The Bohemian (Q1000128). Jane023 (talk) 10:03, 13 March 2022 (UTC)
      • @Jane023: Have to admit, I can't see a Bouguereau now without thinking of this sequence in a documentary a few years back by David Hockney: [3]  :-)
As to the edits, yes you can now sort-of work out what happened (or at least you can as a human), by spotting that the start of the time in the collection at Minneapolis matches the time of the donation; but I do think that the "subsequent owner" property proposed here would a valuable addition, to make the chain a lot more concrete, without needing to use a certain amount of inference to 'join the dots'.
Good move to try to get rid of of (P642) though, it's a menace. Jheald (talk) 19:56, 14 March 2022 (UTC)
Thanks for that clip! Bouguereau annoys me personally for a multitude of reasons, but this wasn't one of them until now. Thanks for the approval and my intention was to show how modelling provenance can never be done in one property, but it touches virtually all properties we currently use for paintings (including at times, dimensions and painting surface). In this case, I also changed the significant event itself, from the general sales (Q194189) to art auction (Q74570489), because the qualifier lot number (P4775) was used. I have been using this combo for works that have sold for high prices, such as this one. That said, in my opinion the other more significant part of this event in this particular case is deaccessioning (Q25339601) which I added under has cause (P828). The reason I set up the WikiProject Provenance was to centralize decisions on this. As far as I can tell reading through this proposal, the before and after are just for use in modelling significant events for artworks? I assume because we haven't decided what types of Qids can be the object of the before & after? I would like to draw a line in the sand as far as types of entities that can be collections or owners, but have been unsuccessful thus far in ordering my thoughts on this. I am unwilling to touch P127 on the Mona Lisa, but I disagree with stuffing whole countries in there. To sum up my objection to this specific proposal: There are more ways to get rid of "of" by getting rid of the significant event using other properties. Jane023 (talk) 11:43, 15 March 2022 (UTC)
  •   Support, an important property for culture.--Arbnos (talk) 15:15, 23 April 2022 (UTC)
  •   Comment Jarekt, would you be okay with replacing anonymous (Q4233718) ("term used to describe the unknown creator of a work") in the examples with "some value"? Thanks, --Marsupium (talk) 08:42, 7 May 2022 (UTC)
  •   Support per all above, modelling for this is needed, the proposed properties solve at least part of the problems, I don't see huge issues with this proposal, no good alternatives shown, proposed modelling is in line with CIDOC-CRM. --Marsupium (talk) 08:42, 7 May 2022 (UTC)

GBIF occurrence IDEdit

   Under discussion
DescriptionIdentifier for occurrences of species in Global Biodiversity Information Facility (Q1531570)
Data typeExternal identifier
Domain(formarly) living things
Allowed values[1-9]\d*
Example 1<https://commons.wikimedia.org/entity/M114906872> → 2350455454
Example 2<https://commons.wikimedia.org/entity/M114977180> → 1655936481
Example 3<https://commons.wikimedia.org/entity/M114725902> → 2831935646
Sourcegbif.org
Planned useAdd provenance to images uploaded in commons and references in Wikidata, similar to iNaturalist observation ID (P5683)
Expected completenessalways incomplete
Formatter URLhttps://www.gbif.org/occurrence/$1
Robot and gadget jobsOpenRefine, Tarsier, manually.
See alsoiNaturalist observation ID (P5683) GBIF taxon ID (P846)
Applicable "stated in"-valueGlobal Biodiversity Information Facility (Q1531570)
Wikidata projectWikidata:WikiProject Biodiversity

MotivationEdit

GBIF or Global Biodiversity Information Facility is a free and open access portal to biodiversity data and images. Quite some of those images use a Wikimedia compatible license (CC0, CC-BY) which allows reuse. We would like to have a property to link to the original occurrence record to maintain the provenance in Commons and Wikidata. Andrawaag (talk) 22:47, 18 February 2022 (UTC)

DiscussionEdit

  •   Support Useful proposal Spinster 💬 22:50, 18 February 2022 (UTC)
  •   Support I'm supportive, but we should also add an example for how it can be used on Wikidata to make it easier for more users to understand. Ainali (talk) 08:36, 19 February 2022 (UTC)
    • Apparently this is not a stable identifier, and even changes "a lot", without redirects. As such, I am very hesitant supporting this as a property. Ainali (talk) 12:20, 19 February 2022 (UTC)
  •   Comment the images I uploaded in 2019 from the GBIF dataset "Invertebrate Zoology Division, Yale Peabody Museum" seems to have stable occurrence IDs. E.g. the following files, the links to the occurences are provided in the source field of the file pages and have not changed since the time of the uploads:
c:File:Chelonibia testudinaria (YPM IZ 028450).jpeg350589333
c:File:Cypria petenensis (YPM IZ 005670.CR) 008.jpeg1039235957
Note that an additional potential useful use is to link type specimen items to their occurences in GBIF, e.g.
NHM 2011.2080 (Q54854611)1055358369
  Question how do we know that they " changes "a lot" "? Christian Ferrer (talk) 08:31, 20 February 2022 (UTC)
  •   Comment (I'm a software developer at GBIF.) GBIF is an index of over 65,000 datasets published by over 1,700 institutions, and updates from those publishers can vary significantly -- some datasets are essentially static, others have weekly or even daily changes.
When a dataset is newly published, or additional records added to an existing dataset, we generate new GBIF occurrence IDs for the new occurrence records. If records within a dataset are changed, we aim to keep the same GBIF occurrence ID. We use four fields within the dataset to do this (dwc:occurrenceID, dwc:institutionCode, dwc:collectionCode, dwc:catalogNumber). If these fields are not changed, the occurrence record will keep the same GBIF occurrence ID. If any of these fields are changed, the record may be assigned a new GBIF occurrence ID, and the old one deleted. (In some cases we can detect the change, and maintain the original IDs.) Additionally, if records are moved from one dataset to another, they will get new IDs.
We're currently working to improve ID stability as we recognize there are more users relying on the stability of these IDs, though this will not solve all cases.
Some publishers aim to keep identifiers within their record (dwc:occurrenceID, dwc:institutionCode, dwc:collectionCode, dwc:catalogNumber) stable, and others do not. Some keep them stable as a human sees it, but not stable as a machine sees it ("A 123" → "A123" → "http://occ.example.org/A/123").
M Blissett (talk) 11:26, 21 February 2022 (UTC)
@M Blissett Can you give an estimate on the number of GBIF occurrence ID changes, with respect to the stable ones. It is not specific to GBIF that identifiers do get obsoleted. I would argue that in most if not all databases this is the case. If the number of ID changes is low, I would still like to move forward with this property proposal. We need this property to provide attribution and provenance to the reused objects. Maybe it is even helping solving this issue, since commons will contain a copy of the digital object being referenced. GBIF might be able to use this linked data to create mappings to those cases where the identifier is reissued. Andrawaag (talk) 11:58, 21 February 2022 (UTC)
(I also work at GBIF)
Please also be aware of this issue which will bring the last known view to the tombstone page, even when records are removed.
I will try and resurrect some previous work I did that illustrates the extent of the changes.
Tim (trobertson@gbif.org) Timrobertson100 (talk) 13:12, 22 February 2022 (UTC)
@Andrawaag
To get a rough sense of ID stability, during 2021 GBIF added 285.4M records (to a total of ~1.9B) and issued 416M identifiers. This indicates 130.6M records lost their IDs or were removed, or ~ 6.8% of records Timrobertson100 (talk) 14:04, 22 February 2022 (UTC)

Example 1 and 3 can be argued to be examples of a different thing (preserved specimens) than species occurrences ("Occurrence", the target of the Occurrence ID). These (particular) specimens can rather be argued to be possible tokens of evidence for species occurrences. Why not simply find better examples in line with example 2?--Dag Endresen (talk) 07:29, 23 February 2022 (UTC)

georeferencing control point dataEdit

   Under discussion
DescriptionTabular data file in the Commons Data: namespace containing georeferencing control points for all or part of a Commons old map image
Representsgeoreferencing (Q772007)
Data typeTabular data
DomainCommons image
Allowed valuesData:.+\.gcps(\..*)?\.tab
Example 1File:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.jpgData:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.gcps.tab
Example 2MISSING
Example 3MISSING
Sourceuser input via app; also existing data in Commons MapWarper, NYPL MapWarper, British Library Georeferencer, David Rumsey maps, other sites with georeferencing
Planned useMovement of data from Commons MapWarper site to Commons Data namespace; import from external sites
See alsoWikidata:Property proposal/external georeferencer URL
  •   Support I think this is an excellent idea. However we should have more examples. Are there any plans to use this data in some way?

georeferencing pixel mask dataEdit

   Under discussion
DescriptionTabular data file in the Commons Data: namespace containing the pixel coordinates of the boundary of the georeferenced area
Representsgeoreferencing (Q772007)
Data typeTabular data
DomainCommons image
Allowed valuesData:.+\.mask(\..*)?\.tab
Example 1File:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.jpgData:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.mask.tab
Example 2MISSING
Example 3MISSING
Sourceuser input via app; also existing data in Commons MapWarper, NYPL MapWarper, British Library Georeferencer, David Rumsey maps, other sites with georeferencing
Planned useMovement of data from Commons MapWarper site to Commons Data namespace; import from external sites
See alsoWikidata:Property proposal/external georeferencer URL
  •   Support --Jarekt (talk) 03:01, 1 July 2020 (UTC)

georeferencing mask geoshapeEdit

   Under discussion
DescriptionGeoshape containing the georectified latitude and longitude coordinates of the boundary of the georeferenced area
Representsgeoreferencing (Q772007)
Data typeGeographic shape
DomainCommons image
Allowed valuesData:.+\.mask(\..*)?\.)\.map
Example 1File:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.jpgData:Pigot_and_Co_(1842)_p2.138_-_Map_of_Lancashire.mask.map
Example 2MISSING
Example 3MISSING
Sourcecomputed from pixel mask using georectification based on a particular set of control points
Planned useMovement of data from Commons MapWarper site to Commons Data namespace; import from external sites
See alsoWikidata:Property proposal/external georeferencer URL

MotivationEdit

Moving Georeferencing data from its present silo in the MapWarper application into the Commons Data: namespace brings it much more naturally into the domain of the Commons community, and will make it much more accessible for use in gadgets or other reuse.

These SDC properties will enable apps to find what has been put where, for the two main types of information used as input for the process; and for queries and apps to access a geoshape showing the real-world position and characteristic boundary of the georectified map.

qualifiers, etcEdit

Note that multiple sets of control-point (gcps) data may exist concurrently for the same image. Different sets of control points may relate to different maps contained in the image (eg multiple sub-maps; or main map/inset map(s) combinations); to sets of control point data obtained independently from different sources (eg Commons MapWarper / external source); or to control point data obtained from different features for different purposes (eg projection estimation [4] is often most effectively achieved based on control points representing a graticule of intersections of lines of latitude and longitude, whereas final map-warping often aims to distort the map to most accurately place depicted land-features and population centres).

Different sets of control points may be associated with the same or with different pixel masks.

The output mask geoshape will in turn relate to a particular pair of control-point and pixel-mask datafiles.

These potentially complicated relationships can be captured by qualifiers on the statements, in particular parallel applies to part (P518) qualifiers on each of the statements to indicate a particular part of the image (eg main map / top-left map / inset map / second inset map etc), object has role (P3831) to distinguish sets of control points relating to different features; and referencing to distinguish sets of control points with different provenances.

The control-point and pixel-mask statements should also be qualified to associate them with a particular revision-id of the file (Wikidata:Property proposal/image revision-id), in case it may subsequently have been cropped/modified.

The georectified mask should be linked to the inputs it is derived from (Wikidata:Property proposal/based on tabular data). It should also have, for convenience, a P518 to indicate the particular map it relates to, where the image contains multiple maps. Jheald (talk) 06:01, 17 August 2019 (UTC) (revised proposal)

DiscussionEdit

  • Proposed. Jheald (talk) 06:01, 17 August 2019 (UTC)
  •   Support I've just watched the summary of what is possible at min 22.30 of this presentation at Wikimania. The potential for this looks amazing. - Ambrosia10 (talk) 20:58, 18 August 2019 (UTC)
  •   Support I also saw this demoed at the Wikimania hackathon showcase and think it makes a lot of sense. --Daniel Mietchen (talk) 00:31, 19 August 2019 (UTC)
  •   Support Thisismattmiller (talk) 13:20, 19 August 2019 (UTC)
  •   Support --Sabas88 (talk) 16:12, 19 August 2019 (UTC)
  •   Support Buccalon (talk) 17:54, 19 August 2019 (UTC)
  •   Support link Wikimania 2019: Hackathon Showcase 22:05 --Salgo60 (talk) 06:33, 22 August 2019 (UTC)
  •   Support Never heard about this, but it looks like it could be covered by Wikidata. --Juandev (talk) 20:15, 29 September 2019 (UTC)
  •   Conditional support @Jheald: Hello, Could you include other examples so that future properties don't start production with "warnings"? This will also verify if the RegEx are compliant. —Eihel (talk) 06:45, 20 January 2020 (UTC)
  •   Support Susanna Ånäs (Susannaanas) (talk) 10:12, 17 May 2020 (UTC)

I agree that we need to get the data out of the silo, but this proposal seems to make things more complex than needed. I've been poking around a bit today based on https://github.com/bertspaan/wikimania-hackathon-2019 . This is what we want to store and how it's done in the example:

I would like to have just one (geojson) file to contain all this data. To test this I'm using Commons:Data:Georectification.example.geojson.map which is a json file with a geojson part in the data field (see also mw:Help:Map Data). Above I read the motivation for multiple pieces. Just create a new map data file if you have another source or another view. Mixing everything makes it extremely complicated. As for the specific revision. These maps shouldn't be overwritten at all per overwrite policy. So one file per warping. Containing the points mentioned above. I had a look at the RFC and Geojson allows foreign members. In the example I made use of that to have several parts in the file:

  • A feature of type "mask" contain the polygon for the mask. You can see the shape on the map
  • A feature of type "gcp" for every geo control point containing the pixel x and y and a point with the lat and long. I would like to group these and maybe add numbering to them. Not sure what is possible here and I have to poke a bit more (maybe GeometryCollection)
  • A feature of type "pixelmask" containing the file name, the entity id and all the pixels (x and y) for the pixel mask

The exact format is open for improvements. This way we can have everything in just one data file making it much easier to work with. Note that the data file contains what file it applies to so it doesn't even have to be linked for the file to work. I would prefer to go down this path and only have one property to link the image file with the geojson file. Multichill (talk) 11:05, 17 May 2020 (UTC)

  • I   Support this new proposal. I cannot see any obstacles in putting the different parts together.
    • It makes great sense in putting the two different parts of the mask in the same file.
    • Bundling all parts of one warping reduces complexity, and makes versioning easier. – Susanna Ånäs (Susannaanas) (talk) 15:29, 17 May 2020 (UTC)
  • Looks reasonable to me. I'd may have suggestions for small tweaks, I'll have to think some things through. But it is a good start. I'd suggest adding a 'sha1' or 'sha256' field to pixelmask, to identify and track the exact version of an image that the mapping was made from, should be easy for mapwarper to add that. TheDJ (talk) 11:09, 18 May 2020 (UTC)
    • @TheDJ: thanks for you input. My main point is to use one Geojson file with everything in it. I made an example to show it's possible. The format is in no way final and we should probably think it through properly before mass deploying it. I like the hash suggestion. Let's just do the sha1 of the file because that's already exposed in the api anyway and saves the hassle of calculating it ourselves. Multichill (talk) 20:37, 18 May 2020 (UTC)
  •   Support   Don't ping me NMaia (talk) 01:29, 11 November 2020 (UTC)
  • Looks like this (like the other Commons property proposals) fell thru the cracks; there is clear support for the three proposals on this page, so I've marked them ready. JesseW (talk) 21:56, 30 March 2021 (UTC)
    • Actually, looking further, it looks like they are superseded (maybe) by @Multichill:'s proposal. @Jheald:, what are your thoughts? JesseW (talk) 21:59, 30 March 2021 (UTC)
      • @JesseW: Thanks for going through these proposals. Having talked about it with User:Multichill since first proposing this, I agree that it does make sense to keep all the data together in one file, as sketched out at c:User_talk:Multichill/Map_warping_format, so I think that probably is the best way forward. The separate files have a certain amount to be said for them in terms of transparency, but I agree that is outwieghed by the convenience of just having to deal with one file, and not having to worry about any versioning issues. So there would then be one property "georeferencing data" pointing to a 'geographic shape' object, ie a .map file in the Data: namespace on Commons.
I am not sure whether one could go ahead and create such a property based on the support already shown on this page, or whether it would need a new proposal. But we are probably quite close to wanting to deploy at least some test examples of this, and IMO it would be useful for development to have statements on SDC pointing to which the relevant georeferencing data file was. Jheald (talk) 11:31, 31 March 2021 (UTC)
I think the given support for Multichill's proposal is sufficient, but it'd be nice to have the proper template set up to make it clear what exactly is being proposed. Once you do that, I think it's fine to mark it as ready. JesseW (talk) 14:20, 31 March 2021 (UTC)
@Jheald, JesseW: I realize this has had a long wait for various reasons, but I think it could be dealt with quickly (i.e. in about a week) as a new proposal, assuming nobody objects. I think that would be cleaner than trying to rewrite the proposals on this page for the new approach. ArthurPSmith (talk) 17:36, 31 March 2021 (UTC)

@MasterRus21thCentury: why did you mark these as ready? This proposal is stale and unclear how to go next. If these properties are created now, we'll just end up with a bunch of unused properties that end up getting deleted. Multichill (talk) 21:11, 14 April 2022 (UTC)

  Question: So, the discussion should be closed due to inactivity? MasterRus21thCentury (talk) 21:18, 14 April 2022 (UTC)

image revision-idEdit

   On hold
DescriptionQualifier to inidicate the particular revision of an image that a statement refers to
Data typeString
Domainstatements with value: media
Allowed values\d+
Example 1File:Pigot and Co (1842) p2.138 - Map of Lancashire.jpg (revision-sensitive statement) → 279847594
Example 2File:Larousse,_Plan_de_Paris,_1900_-_David_Rumsey.jpg (revision-sensitive statement) → 180884966
Example 3File:1768_Jeffreys_Wall_Map_of_India_and_Ceylon_-_Geographicus_-_India-jeffreys-1768.jpg (revision-sensitive statement) → 345654849
Planned useTo indicate which revision of a map image has been georeferenced on Commons MapWarper. But further use-cases are likely to emerge.
See alsoWikimedia import URL (P4656)

MotivationEdit

Sometimes it is important to be able to indicate which particular revision of a Commons image a Wikidata or SDC statement refers to. For example, georeferencing information will fail to be correct if an image has been cropped. A mechanism is therefore necessary to be able to specify a particular version of a Commons file. Jheald (talk) 13:16, 14 August 2019 (UTC)

DiscussionEdit

  • Proposed. Jheald (talk) 13:16, 14 August 2019 (UTC)
  •   Comment This is not going to work properly, because, when someone will upload a new version, the file will change its version number, but the value in the property may stay the old one. Moreover, there was a discussion with WMF team, that it's not possible to track different versions so they cannot be stored in Wikidata. --Juandev (talk) 20:21, 29 September 2019 (UTC)
    • @Juandev: The whole point is that we want the property to point to the old version of the image, because that is the one that the georeferencing was done against, not any later reupload that may potentially have been cropped. Jheald (talk) 22:15, 13 October 2019 (UTC)
  • I think the (current) samples give the revision of the file description page, not the image version. --- Jura 09:35, 13 October 2019 (UTC)
  • Slight   Support. I understand the argumentation, but during my 15 year old presence I havent encountered such situation.--Juandev (talk) 12:47, 15 November 2019 (UTC)
  • Slight   Oppose. I do not see the need, and it might not be technically freezable. I am open to change my vote if there is a clear need. --Jarekt (talk) 01:54, 15 May 2020 (UTC)

I marked this proposal as on hold. Currently we have two solutions:

  • Wait phab:T28741 to be fixed so file versions have unique identifiers
  • Create a property "image timestamp", but 1. we still does not have the datatype unless we store timestamp as string and 2. timestamp may still be not unique.

--GZWDer (talk) 23:20, 28 May 2020 (UTC)

Commons infobox based onEdit

   Under discussion
DescriptionID of an object, which was depicted or digitized to create this file and which will be used to create infobox (like Book or Artwork template) describing it
Data typeItem
Template parameterwikidata parameter in c:template:Artwork, c:template:Book, c:template:Photograph, c:template:Art photo,
Domainobject (Q488383): mostly object (Q488383), but also some abstract object (Q7184903)
Allowed valuesspecific artworks, artifacts and other museum holdings, as well as movies, or music compositions
Example 1Structured Data for  The Starry Night (Q45585) (for artworks opposite of image (P18))
Example 2Structured Data for  Mona Lisa (Q12418) (opposite of image with frame (P7420))
Example 3Structured Data for  David (Q179900)
Example 4Structured Data for File:Julien Bryan - Siege.ogvSiege (Q1351398) (opposite of video (P10))
Example 5Structured Data for File:"The Star-Spangled Banner" performed at the White House in 1994.ogaThe Star-Spangled Banner (Q44696) (opposite of audio (P51))
Example 6Structured Data for  Mona Lisa (Q12418) (opposite of 3D model (P4896))
Example 7Structured Data for File:EiffelTower fixed.stlEiffel Tower (Q243) (opposite of 3D model (P4896))
Example 8Structured Data for  March Constitution of Poland (Q2535435) (opposite of document file on Wikimedia Commons (P996))
Example 9Structured Data for  Nałęcz (Q1785126) (opposite of coat of arms image (P94))
Planned useThis SDC property will be used by file infoboxes on Commons to indicate which item should be used as basis for the infobox. It will have single-value constraint (Q19474404)
Robot and gadget jobsUser:JarektBot or others will populate this property based on current digital representation of (P6243): copying the values for 2D artworks and moving them for other objects.
See alsodigital representation of (P6243), based on (P144), image (P18), main subject (P921)

MotivationEdit

Property digital representation of (P6243) was originally proposed to be used with c:template:Artwork and be equivalent to {{Artwork|wikidata=...}}. It is being used that way right now by couple hundred thousand files and several templates. However other users had plans to use this property for 2D artworks only to indicate that the file is a faithful reproductions of two-dimensional works of art that meets requirements of c:template:PD-Art or to tag files where wikidata relative position within image (P2677) properties are valid. As a result Wikidata:Property proposal/Digital representation of proposal when finally approved was ambiguous about its purpose. Ever since, most of the discussions at Property_talk:P6243 revolve around multiple visions different users have for this property. Based on Property_talk:P6243#2D_vs._3D discussion it seems like the best solution is to split digital representation of (P6243) into at least 2 properties: one to be used by Commons infobox templates and one for digitizations of 2D artworks. --Jarekt (talk) 04:36, 28 September 2020 (UTC)

How is it different from other properties:

In general, getting a new single-purpose property with name linking it to its purpose is important, since adding this property would affect the displayed metadata, and should be independent of any other task.--Jarekt (talk) 12:53, 28 September 2020 (UTC)

DiscussionEdit

Mike, Can you provide details on your proposal? How would it work? Depict statements seem particularly badly suited for this task:
If depicts (P180) is used correctly (i.e., for the specific things depicted, not random things), then it works well. E.g., see commons:File:Jodrell Bank Mark II 5.jpg, which uses commons:Template:Structured Data to pull out information about multiple telescopes in the image. The same should work fine in the cases here. Thanks. Mike Peel (talk) 18:28, 5 October 2020 (UTC)
However depicts (P180) is usually not used correctly and yes you can handcraft an image where it works but for great many images it does not. c:template:Artwork uses depicts (P180) to find and list depicted people. That code was crashing on some pages due too many depict statements and taking too long. I had to limit it to only first 50 depicts for which I was looking up instance of (P31). That is why "Infobox based on" only allows a single value. The purpose of depict is to list depicted people, places, objects, etc. and purpose of "Infobox based on" is to choose a single item to base the infobox on. Those 2 purposes are very different. We already tried to use a single property for 3 different tasks: digital representation of (P6243) and as a result it does not work well for any of them. --Jarekt (talk) 00:56, 7 October 2020 (UTC)
  •   Comment unless we have samples of uses elsewhere, could you add "Commons" to the property label? --- Jura 07:12, 7 October 2020 (UTC)
Sure --Jarekt (talk) 02:09, 1 November 2020 (UTC)
  •   Support Christian Ferrer (talk) 22:18, 20 February 2021 (UTC)
  •   Support I'm not fully convinced about not using main subject (P921), but right now we're in a deadlock and I want to get digital representation of (P6243) cleaned up so we can go to the next step with that property. Let's create this new property. Clean up digital representation of (P6243) and maybe later decide to merge the new property into main subject (P921) (or not). That way we can do incremental improvements. Multichill (talk) 12:18, 7 March 2021 (UTC)
  • Weak   Support. I'm not a big fan of creating and using properties that are solely designed for the purpose of displaying (or not displaying) certain data on our wikis. (Said differently: I think our properties should be Wikimedia-independent and purely semantic, and the way we display content on our wikis should smartly work with those semantics.) I also think it would be most future-proof if we would rethink the way we do infoboxes for files on Commons, not try to stuff structured data in the old flawed ways we used to do things with the limits of Wikitext. That said, the way we've ended up misusing digital representation of (P6243) for photos of three-dimensional works is also not great at all. So I'm with Multichill on being pragmatic and using this property temporarily as hopefully a step forward towards hopefully a more and more correct and clear way of displaying semantically correct data about creative works, files showing these creative works, and the creators of the works and the files. Spinster 💬 12:37, 7 March 2021 (UTC)
  •   Question At Property talk:P6243, User:Jarekt has floated the idea of using depicts (P180) or main subject (P921) with a qualifier object has role (P3831) = "appropriate subject for infobox" (or similar), that the template could pick up. Is that a model that could work? Would it cover all the use-cases? Jheald (talk) 10:47, 12 April 2021 (UTC)
It would not work well with depicts (P180) as you might have large number of those and it might be a mess to find the depict with the qualifier. main subject (P921) might work because there should be only one of those. Tools like c:User:Magnus Manske/sdc tool.js which I currently use to add digital representation of (P6243) to files, do not support qualifiers. Is main subject (P921) appropriate for files which show image details or for PDF files which we would link to items? --Jarekt (talk) 01:28, 20 April 2021 (UTC)

Switched to using main subject (P921) on Commons so I think we can close this one. Multichill (talk) 21:07, 14 April 2022 (UTC)

International Standard Content NumberEdit

   Under discussion
DescriptionUnique identifier of a piece of content metadata registered on blockchain.
RepresentsISCN (Q110014315)
Data typeURL
DomainCommons image
Allowed valuesiscn:\\.*
Example 1File:Peak_view_of_West_Buffalo_Hill_Hong_Kong.jpg → iscn://likecoin-chain/k-IVrALxRK8b0_hHsztdT6WYFddETfPeUhpXpEdrCOA
Example 2File:香港大埔元洲仔直升機坪.jpg → iscn://likecoin-chain/_chLIJxwK_UD8Ph08kAXVSfrU6zT8xlVSSkJPzEsJQg
Example 3MISSING
Sourceuser register via chain API, or any other tool using chain API such as https://app.like.co
Planned useAny content to be referenced to a metadata record on blockchain can has an ISCN. In example 1, for instance, the corresponding transaction on chain can be view at https://likecoin.bigdipper.live/transactions/AD9A4625F8D51DAFB93F3B1FD10C10A11AB825482090EE2FA0993B4E23B09759. ISCN record on chain is immutable. ISCN can be searched at https://app.like.co.

MotivationEdit

 – The preceding unsigned comment was added by Edmondyu (talk • contribs) at 21:30, December 9, 2021‎ (UTC).

DiscussionEdit

mediumEdit

   Under discussion
DescriptionType of medium depicted by the image, eg. photograph, painting, sculpture, etc. (not genre!)
Data typeItem
Example 1File:Bangor,_Suspension_Bridge,_From_Anglesey_(254)_LACMA_M.2008.40.202.10.jpg -> photograph (Q125191)
Example 2File:Portrait LACMA M.77.25.jpg -> painting (Q3305213)
Example 3File:Andromeda and the Sea Monster, and Leda and the Swan, 11364501.jpg -> sculpture (Q860861)
Planned useWikimedia Commons structured data


MotivationEdit

Using this we can distinguish between photographs, paintings, drawings, etc. --Adam Harangozó (talk) 19:03, 23 August 2020 (UTC)

DiscussionEdit

Jheald (talk) 06:27, 17 August 2014 (UTC) Micru (talk) 07:20, 17 August 2014 (UTC) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 17 August 2014 (UTC) Sannita - not just another it.wiki sysop 12:50, 18 August 2014 (UTC) Susannaanas (talk) 08:05, 19 August 2014 (UTC) Mushroom (talk) 12:02, 21 August 2014 (UTC) I do think Commons is the better place to talk about this. Multichill (talk) 18:50, 21 August 2014 (UTC) Jarekt (talk) 04:38, 3 September 2017 (UTC)  徵國單  (討論 🀄) (方孔錢 💴) 11:23, 14 November 2017 (UTC) Mike Peel (talk) 22:50, 12 May 2018 (UTC) Yann (talk) 23:27, 7 July 2018 (UTC) John Samuel (talk) 10:10, 22 September 2018 (UTC) 99of9 (talk) 06:27, 12 July 2019 (UTC) Christian Ferrer (talk) 18:05, 19 July 2019 (UTC) Jura GPSLeo (talk) 13:30, 29 July 2019 (UTC) Tris T7 TT me
Juandev (talk) 17:35, 7 September 2019 (UTC) Jean-Fred (talk) 15:21, 26 September 2019 (UTC) Premeditated Vahurzpu Dr Isaac Andy (talk) 05:21, 29 January 2020 (UTC)
  Notified participants of WikiProject Commons Ruthbrarian (talk) 16:50, 6 May 2020 (UTC) Erussey (talk) 17:12, 6 May 2020 (UTC) Pobocks (talk) 17:36, 6 May 2020 (UTC) Codewitch (talk) 17:57, 6 May 2020 (UTC) Lottebelice (talk) 11:34, 12 July 2020 (UTC) Librarian lena (talk) 19:03, 14 August 2020 (UTC) Jneubert (talk) 07:03, 24 September 2020 (UTC) Sp!ros (talk) 12:39, 6 October 2020 (UTC) Sradovsk (talk) 16:13, 9 December 2020 (UTC) Heberlei (talk) 14:57, 11 June 2021 (UTC) KelliBee123 (talk) 03:46, 1 July 2021 (UTC) --F.Gelati (talk) 12:05, 4 October 2021 (UTC) Ballerlikemahler (talk) 16:22, 2 November 2021 (UTC)  Notified participants of WikiProject Archives Linked Data Interest Group Weadock313 (talk) 01:27, 20 April 2020 (UTC) 2le2im-bdc (talk) 19:36, 30 May 2018 (UTC) Beat Estermann (talk) 23:29, 1 June 2018 (UTC) Flor WMCH Gilliane Kern (talk) 05:47, 5 June 2018 (UTC) Mauricio V. Genta (talk) 23:42, 1 September 2018 (UTC) Laureano Macedo (talk) 09:49, 13 September 2018 (UTC) Daniel Mietchen VIGNERON scottythered Patafisik anarchivist KelliBee123 (talk) 16:29, 6 August 2019 (UTC) Anne Chardonnens (talk) Yooylee 30 (talk) 23:15, 11 August 2019 (UTC) Mlemusrojas (talk) 19:40, 19 February 2019 (UTC) erussey Kcohenp (talk) 16:28, 03 June 2019 (UTC) Mrtngrsbch Amandine (talk) 19:58, 12 August 2019 (UTC) René La contemporaine (talk) 11:17, 13 February 2020 (UTC) Sp!ros (talk) 09:00, 27 April 2020 (UTC) Ccooneycuny (talk) 16:49, 19 May 2020 (UTC) Librarian lena (talk) 19:57, 11 August 2020 (UTC) Valeriummaximum (talk) 16:42, 23 August 2020 (UTC) Jneubert (talk) 07:11, 24 September 2020 (UTC) MaryCDominique (talk) 10:06, 25 October 2020 (UTC) Epìdosis 17:16, 16 February 2021 (UTC) P feliciati (talk) 17:18, 16 February 2021 (UTC) JnyBn (talk) 07:27, 22 April 2021 (UTC) Hsarrazin (talk) 13:25, 1 July 2021 (UTC) Carlobia (talk) 15:27, 6 October 2021 (UTC) Heberlei (talk) 20:19, 29 July 2021 (UTC) KAMEDA, Akihiro (talk) 18:30, 18 September 2021 (UTC)  Notified participants of WikiProject Archival Description Tubezlob VIGNERON Jane023 Pigsonthewing Ambrosiani Spinster Wittylama Fuzheado Emijrp Daniel Mietchen Marsupium Martingggg Anne-LaureM Beat Estermann Manu1400 Mauricio V. Genta Patafisik MartinPoulter Tris T7 BeatrixBelibaste Clifflandis Mrtngrsbch Reciproque Weadock313 (talk) 21:56, 27 November 2019 (UTC) Nomen ad hoc Crowjane7 Scarey1 (talk) 11:55, 9 February 2021 (UTC)   Notified participants of WikiProject Museums   WikiProject sum of all paintings has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

  Question Why not instance of (P31)? NMaia (talk) 09:49, 24 August 2020 (UTC)

  Question Is there any relation to P7937 - format of creative work or is this something completely different? Moebeus (talk) 16:42, 24 August 2020 (UTC)

  Question aren't all of the samples above photographs? For this to work, it's probabaly better to call it "Wikimedia Commons basic type" with a clear set of values to use and explicit rules when they apply. @Adam Harangozó: --- Jura 21:51, 28 August 2020 (UTC)

e.g. if more than 80% of the image reproduces a painting, use painting (Q3305213); if a drawing, use drawing. If the main subject is a sculpture, statue or installation, use sculpture (Q860861). Otherwise, if it's a photograph, use photograph (Q125191). --- Jura 14:06, 29 August 2020 (UTC)
If the photo shows at 100% an artwork, it is still a photo. --XRay (talk) 19:53, 24 October 2020 (UTC)

  Comment @NMaia, Moebeus, Jura1: Sorry for my very slow reply.

  • instance of (P31) could work but I feel it's a bit conflicting with digital representation of (P6243) - so it an instance of a painting or a digital representation? I know this sounds nitpicking, I'm just trying to advocate for a unified way of handling this issue.
  • form of creative work (P7937) I feel is a bit confusing as I feel it rather refers to size or some specific type but not a medium as a whole. At the same time the many of the examples on the property page are genres (novel) so it doesn't seem to work consistently.
  • What is problematic with the "Wikimedia Commons basic type" is that I feel there is a difference between a photo depicting a sculpture - even if it's the main subject, that is a photo, not a sculpture, it's depicted only, and it could be a historical photo where it's "photoness" is important - and a drawing which might have been photographed or digitalised but the whole image represents that drawing, is a drawing. --Adam Harangozó (talk) 17:26, 15 September 2020 (UTC)
    • Isn't that the same problem as your proposal has? The main difference is that the label explicitly refers to Commons' view of that problem and provides clear guidance how to determine it. --- Jura 08:23, 22 September 2020 (UTC)
  • @Adam Harangozó: Term "medium" is already used for other things on Commons: Artwork template has a field medium and it might have values like "Oil on Paint". And we need to be clear that the file is likely a photograph or a scan of an object and that object is... Can we call it "digitized object is a" and allow values like: painting, music recording, movie, sculpture, book, page of a book, etc. ? --Jarekt (talk) 02:34, 28 September 2020 (UTC)
    • One thing that would be important to consider with naming this property is that it might be a very popular search keyword/option in future Commons (for example if I only want to search for drawings). Because of this I think it should have a name which is friendly to those not using Wikidata, and "digitised object" is a bit too "tech". I would wait for more opinions but maybe something like the mentioned Commons basic type or Commons artwork type could work. Commons artwork medium? Adam Harangozó (talk) 22:57, 20 October 2020 (UTC)
  • IMO a photograph of a sculpture or something similar is still a photograph. We should not reduce a photograph to a digitised Object. This would demean the work of the photographer. The sculpture is part of depicts (P180), not more. --XRay (talk) 19:32, 24 October 2020 (UTC)
  •   Support, an important property for images.--Arbnos (talk) 16:38, 19 February 2021 (UTC)
  •   Oppose no, this is not the solution how to deal with multiple works. Multichill (talk) 19:07, 3 March 2021 (UTC)

New Mexico Digital Collections identifierEdit

   Under discussion
Descriptionnumerical identifier pointing to a record of a historical document or photo in the NMDC union catalogue (hosted by the University of New Mexico)
RepresentsNew Mexico Digital Collections (Q61756328)
Data typeExternal identifier
Domainitem, MediaInfo
Allowed values/\d+
Allowed unitsunitless
Example 1file:Tom O'Folliard circa 1875 retouched and cropped.jpg229
Example 2file:Old Courthouse Building, Mesilla, New Mexico.jpg5092, 10237
Example 3file:group on plaza, Mesilla, New Mexico.jpg10224
Example 4file:Lamy.jpg10104
Example 5file:Carl Lotave.png82
Example 6file:Rafael Chacon.jpg3619
Example 7file:the Franklin Bond House 1920.jpg8190
Example 8file:Samuel-Beach-Axtell-1876.jpg3
Example 9file:Marsh-Giddings-1871.jpg546
Example 10file:John E. Miles.jpg20
Example 11file:Frente Democratico Revolucionario - Nueva Alternativa.png4234
Example 12file:Джон Танстелл.jpg211
Example 13file:camping on the Border, near El Paso, Texas.jpg78
Example 14file:Tanystropheus fossai.JPG246
Example 15file:Tanystropheus fossai Zogno.JPG246
Example 16file:railway stations of Fayoum Light Railway shown in Baedeker 1908.jpg529
Example 17file:Southwest Presbyterian Sanatorium (Albuquerque, 1911).png11433
Example 18file:Frank Bond 1903.png1037
Example 19The Triassic-Jurassic Terrestrial Transition (Q112086097)265
Example 20Caudal fin skeleton of the Late Cretaceous lamniform shark, Cretoxyrhina mantelli, from the Niobrara Chalk of Kansas (Q112086045)683
Example 21A small coelurosaurian theropod from the Yellow Cat Member of the Cedar Mountain Formation (Lower Cretaceous, Barremian) of eastern Utah (Q112085834)953
Example 22A new genus of hesperhyine peccary (Artiodactyla: Tayassuidae) from the late Oligocene of Oregon (Q112084540)7107
Sourcehttps://econtent.unm.edu/digital/search/order/subjec/ad/asc
External linksUse in sister projects: [ar][de][en][es][fr][he][it][ja][ko][nl][pl][pt][ru][sv][vi][zh][commons][species][wd].
Planned uselinking images on Commons to this catalogue
Number of IDs in source138,996
Expected completenessalways incomplete (Q21873886)
Formatter URLhttps://econtent.unm.edu/digital/search/searchterm/$1
Robot and gadget jobsperhaps semi-automatable, but I have no plans
See alsoNMSRCP reference number (P6473)
Applicable "stated in"-valueNew Mexico Digital Collections (Q61756328)
Wikidata projectWikiProject New Mexico (Q21830484)

MotivationEdit

To improve metadata of media related to New Mexico on Commons and thereby other projects. Arlo Barnes (talk) 10:27, 21 May 2022 (UTC)

DiscussionEdit

"start time in media" and "end time in media"Edit

   Under discussion
Descriptionqualifiers for stating to which part of a media file a statement applies to. These qualifiers (i.e. "start time in media" and "end time in media") should only be used in media files (i.e. audio and videos) of Wikimedia Commons.
Data typeQuantity
Allowed values(\d{1,2}:)?(\d{2}):(\d{2})(.\d{3})? (same notation that uses FFmpeg for specifying times, documentation can be found here)
Example 1Video file: commons:File:WikidataCon 2017 - Languages in Wikidata.webm
main subject
  Wikidata label
start time in media 00:02:36
end time in media 00:03:33
0 references
add reference
  Wikidata editor
start time in media 00:09:02
end time in media 00:12:00
0 references
add reference


add value
Example 2Video file: commons:File:35c3 WikipakaWG - Wikidata-introduction Wikidata Query Service introduction (eng).webm
main subject
  Wikidata item
start time in media 00:16:34
end time in media 00:22:46
0 references
add reference
  Help:Interlanguage links
start time in media 00:22:46
end time in media 00:24:20
0 references
add reference
  Commons category
start time in media 00:38:12
end time in media 00:39:09
0 references
add reference
  Structured data on Wikimedia Commons
start time in media 00:39:09
end time in media 00:40:04
0 references
add reference
  depicts
start time in media 00:40:04
end time in media 00:40:24
0 references
add reference
  Commons category
start time in media 00:40:24
end time in media 00:40:54
0 references
add reference


add value
Example 3Video file: commons:File:WIKITONGUES- Diego speaking Portuguese, English, Spanish, French, Italian, and German.webm
language of work or name
  French
start time in media 00:00
end time in media 00:52
0 references
add reference
  English
start time in media 04:16
end time in media 06:28
0 references
add reference
  Spanish
start time in media 06:31
end time in media 07:30
0 references
add reference


add value
Example 4Video file: commons:File:Ex1402-dive02.webm
depicts
  crab
start time in media 00:03:44.992
end time in media 00:03:55.869
0 references
add reference


add value
Example 5Audio file: commons:File:Debate-presidencial-peru2006-parte1.ogg
speaker
  Alan García
start time in media 00:04:46.353
end time in media 00:07:50.131
0 references
add reference
  Ollanta Humala
start time in media 00:08:40.531
end time in media 00:11:39.293
0 references
add reference


add value
Planned useI mainly plan to use it in conference presentations (e.g. WikidataCon 2017) since those are the media files that I mostly watch, but I'm sure people will be able to use in the structured data of media files of any kind.

MotivationEdit

In Wikimedia Commons, there are long videos (00:57:31, 00:52:50, 00:48:37, 00:36:36) and long audios (01:15:57, 00:45:31, 00:27:51, 00:18:51). The statements in SDC sometimes only apply to some parts of the media files. For example, an indigenous language can be spoken in a short part of a documentary or the main subject during the part of a lecture can be a specific topic or a person can be the speaker at multiple parts of a conference presentation. For this reason, we need qualifiers for stating to which segment of the media file a statement applies to. I'll list some more examples.

In File:WIKITONGUES- Pau speaking French, the languages used are French, Lithuanian, Italian, English, Spanish, and Catalan. A user that would find this video might find difficult to know the parts in which each language is spoken. This qualifier can solve this issue by using it as it follows.

language of work or name
  French
start time in media 00:00
end time in media 00:52
0 references
add reference
  English
start time in media 04:16
end time in media 06:28
0 references
add reference
  Spanish
start time in media 06:31
end time in media 07:30
0 references
add reference


add value

Another example: Consider File:35c3 WikipakaWG - AI in Wikipedia (eng).webm. Its duration is 37 min 13 s. Because of the title, we can say the main subjects are artificial intelligence and Wikipedia, but, during the presentations other topics are discussed. This qualifier can help for specifying those topics and the segments in which they are discussed.

main subject
  ORES
start time in media 02:27
end time in media 03:10
0 references
add reference
  MediaWiki
start time in media 04:57
end time in media 05:54
0 references
add reference
  ethics of artificial intelligence
start time in media 19:09
end time in media 19:51
0 references
add reference


add value

Final example: Consider File:Documentary - The Fourth Industrial Revolution.webm. Having support for milliseconds will provide users the opportunity to be as granular as they need.

depicts
  firework
start time in media 00:02:12.603
end time in media 00:02:15.523
0 references
add reference
  firework
start time in media 00:02:22.923
end time in media 00:02:26.203
0 references
add reference


add value


Rdrg109 (talk) 08:04, 21 December 2021 (UTC)

DiscussionEdit

  •   Comment we already have time index (P4895) for start time, but lack a property for end time. --- Jura 12:59, 21 December 2021 (UTC)
  •   Comment Someone in the telegram group of Wikimedia Commons mentioned that these qualifiers could also be used in audio files. I've updated the proposal. The name of the qualifiers are now "start time in media" and "end time in media" instead of "start time in video" and "end time in video" so that they can also be used in audio files. --- Rdrg109 (talk) 15:16, 21 December 2021 (UTC)
  •   Support This will be especially useful on longer media files. Ainali (talk) 22:42, 27 December 2021 (UTC)
  •   Oppose per above. Use existing property for start time. Datatype for end time shouldn't be string, but the same as time index (P4895). --- Jura 09:54, 28 December 2021 (UTC)
    @Jura1: The problem with the quantity data type is that it only allows a single unit. This means that if someone wants to specify a timestamp, they should use the unit of the smallest time unit. For example, if someone wants to store 01:00:00, they would use 1 hour. If someone wants to store 01:32:00, they would use 92 minutes. If someone wants to store 01:12:37, they would use 4357 seconds. If someone wants to store 01:13:18.322, they would use 4398322 millisecond. Having to convert the timestamp to different units makes it more difficult to the user to contribute which might cause the property not to be used at all.
    Because the data type of time index (P4895) is "quantity", I think that the proposed properties are more suitable.
    Rdrg109 (talk) 04:45, 2 January 2022 (UTC)
    • You can enter 18.322 seconds as 18.322 second. No need to input 18322 millisecond.
    It's clear that it requires some thought about unit selection and value entry (but even date entry require date precision to be determined). If you need help with that, please ask on project chat.
    It may be easier to add "01:32", but a user couldn't really know what it means. Is is 1 hour and 32 minutes, 1 minute and 32 seconds?
    Quantity datatype does provide an automatic conversion to seconds on query service, so fairly easy to figure out the values, even without checking units. --- Jura 14:40, 2 January 2022 (UTC)
    @Jura1: We can avoid the confusion of taking "01" in "01:32" as hour or minute, by using the same logic that uses FFmpeg. You can find information about that in this link. Here's the notation: [-][<HH>:]<MM>:<SS>[.<m>...] (omit the hyphen at the beginning -). As you can see, the hours are only considered when there are three parts in the time. --- Rdrg109 (talk) 15:48, 12 January 2022 (UTC)
    Seems possible. Still, I think it's better to use the available datatype that has conversion built in. --- Jura 12:20, 18 January 2022 (UTC)
  •   Oppose start time is a duplicate of time index (P4895) and data type should be quantity. --Dipsacus fullonum (talk) 09:21, 1 January 2022 (UTC)
    time index (P4895) is the relative equivalent of point in time (P585), not start time (P580). I agree that the datatype should be quantity though. - Nikki (talk) 03:41, 2 January 2022 (UTC)
    @Nikki: @Dipsacus fullonum: I've shared my thoughts on why I think we shouldn't use the quantity datatype for this use case in the Jura1's answer in this property proposal. Let me know your thoughts please. --- Rdrg109 (talk) 04:50, 2 January 2022 (UTC)
    @Nikki: Two out of three uses of Wikidata property example (P1855) for time index (P4895) (for Blade Runner (Q184843) and Stairway to Heaven (Q192023)) are similar to the examples given in this proposal except the end time isn't indicated. I see no reason why media files at Wikimedia Commons should use other properties for relative times than media files in general. --Dipsacus fullonum (talk) 05:09, 2 January 2022 (UTC)
    To me that is a clear argument for these properties. "Blade Runner depicts a unicorn at 72 minutes" is true as long as there is a unicorn visible at that time, whether it only just appeared or not. If you agree with that, then we're missing a way to enter the start time. If you disagree with it, then the property is ambiguous and we're missing a way to distinguish start time uses from point in time uses. - Nikki (talk) 09:52, 4 January 2022 (UTC)
  •   Comment A more appropiate data type for these properties would be Duration, but because, apparently, it hasn't been fully integrated into Wikibase, I think that if these properties were to be created, they could be handled with String until the Duration data type is fully implemented. --- Rdrg109 (talk) 04:58, 2 January 2022 (UTC)
    I wrote that ticket, but it doesn't really seem to be acted upon.
    One of the suggestions in the ticket is to display quantity differently, so entering it as quantity already would allow to convert values easily later.
    BTW, speaking of "duration" (different sense), instead of specifying end time, one could just use duration (P2047) and time index (P4895). --- Jura 08:25, 11 January 2022 (UTC)
    @Jura1: In regards to the ticket: Hopefully, it'll be implemented some day. If not, we can use String for the time being.
    In regards to using duration (P2047): I think the same problem happens: More friction for the user. The user would need to compute the difference between point 1 and point 2 in the video and then use that value for duration (P2047). With this properties, they would just need to use the time that is shown in their media players which most of them, if not all, show the time in the format [<HH>:]<MM>:<SS>[.<m>...] which is the one that would be used in this property. --- Rdrg109 (talk) 16:15, 12 January 2022 (UTC)
    I think the time format shown in one's player depends on the player's localization. I strongly disagree to the datatype string with a format used in English. While we wait for the duration datatype, quantity is much better as it includes unit so people don't have to guess to interpret the string, and it be usable for all independent of language, script system and culture. It will also be easy to make tools to convert to and from whatever format different people prefer. Wikidata is primary intended to be accessed by computers, and datatypes should be intended for easy computer handling. --Dipsacus fullonum (talk) 18:41, 12 January 2022 (UTC)
  • I have boldly changed the datatype of proposal from string to quantity.--GZWDer (talk) 18:45, 16 February 2022 (UTC)
  •   Support very useful!--2le2im-bdc (talk) 19:59, 20 February 2022 (UTC)
  •   Comment Why not speak of "start validity in media" and "end validity in media"? It would be also possible to use it for a text. Ex : One text depict something from page 2 to page 5. --2le2im-bdc (talk) 20:14, 20 February 2022 (UTC)

GeneralEdit