Swedish Royal Theater Archive will be another step in introducing linked data for museums/theaters related to music and theater. In the long run
I hope they will be candidates for implementing their own instances of Wikibase - Salgo60 (talk) 18:55, 4 May 2019 (UTC)
Comment This is great however I think the second example should be invalid. ?category=roles&query=Bettsy+Trotwood is clearly no identifier, nor does its result represent the same thing as the Wikidata item. Abbe98 (talk) 08:30, 6 May 2019 (UTC)
@Abbe98: agree. I dont see that Dramaten gives us a query a problem (if it is stable) more who should have what data. I think we need to start having a dialogue inside Wikidata and with external parties like Dramaten
Should Wikidata has the persons and major plays and we tell the domain experts to join our echo system setting up a Wikibase (Q16354758) - see my presentation last week(GITHUB) were I hope this is the way forward but today I feel its not realistic as its a mismatch between complexity of the concept/Wikibase product maturity/#LOD skills at domain experts
@Salgo60: your comment is not related to my concern. The identifiers look fine to me but the query is defiantly not stable and will break sooner or later. It would in almost all cases just be the Wikidata label URL encoded, if applications would like to create such links they could do it on the fly. Linking to unstable query links is the opposite of Linked Open Data. Abbe98 (talk) 12:07, 6 May 2019 (UTC)
@Ambrosiani: Yes and I think they should maybe be in a local en:Wikibase installation at Musikverket?!?!? I guess when connecting a general knowledge graph as Wikidata with a specialist "domain" we have to define "responsibilities" who is caring about what. A good pattern would be if we could get Musikverket to define User stories so that we better understand what added value Wikidata can add. I recommend the Future learn training about how to work together in Open networks link - Salgo60 (talk) 17:43, 10 May 2019 (UTC)
Sure, but until then I think it's only the /Person/ID endpoint that can be used by wikidata items. Ambrosiani (talk) 08:43, 11 May 2019 (UTC)
Weak oppose I support this only on the condition that the format is enforced with a slash and a list of things to go before the slash (Play, Person, etc). The second example is gonna break when they revamp their search engine. We can save external ID's but saving search queries is too fragile. --Ysangkok (talk) 22:32, 8 July 2019 (UTC)
I deleted the query example with search engine - Salgo60 (talk) 11:14, 14 September 2019 (UTC)
Oppose per Ysanglok − Pintoch (talk) 20:41, 23 July 2019 (UTC)
marking as not ready while one of the examples uses a search engine − Pintoch (talk) 21:16, 23 July 2019 (UTC)
I deleted the query example with search engine - Salgo60 (talk) 12:47, 9 August 2019 (UTC)
@ChristianKl: I presume it'd need retranslated and linked more appropriately. That would be my preferred option, honestly, but I don't know how to even propose that. Adam Cuerden (talk) 19:21, 2 July 2019 (UTC)
Generally, the way to do this is to start a discussion on the talk page of the relevant property and ping all the people that participated in the property discussion that lead to the creation of the property and any WikiProjects that are associated with the property. ChristianKl ❪✉❫ 20:47, 3 July 2019 (UTC)
@Trade: please don't add statements in a constraint violating way as in the example of La Navarraise (Q2709440). If you think the scope of a property should be changed seek consensus for that instead of using it outside of the scope. ChristianKl ❪✉❫ 08:58, 2 July 2019 (UTC)
Comment Either use inventory number (P217) or the label on this identifier needs to be much more specific (for example "Staatlichen Museen zu Berlin ID"). About how many artworks are in the collection and have these identifiers? ArthurPSmith (talk) 15:15, 1 July 2019 (UTC)
Agree that the name needs to be a lot more specific. --Ysangkok (talk) 19:33, 8 July 2019 (UTC)
Comment Some items have really weird Ident.Nr., like e.g. this Bluse. What is the value of having the Ident.Nr if the museum doesn't actually use it itself for indexing? As you can see, the URL's do not reference it. It's called a Nummer, but is not actually a number. How do they actually use the number in the museums? Because their IT departments don't seem to cherish the system... --Ysangkok (talk) 19:33, 8 July 2019 (UTC)
It doesn't matter if there is no formatter url/direct way of linking. --- Jura 23:52, 8 July 2019 (UTC)
Conditional support @M1fischer14: There are arguments above, have you read them? Would you be kind enough to complete your proposal, please? You can help yourself with comments next to the lines to fill in or get inspired by other propositions. Otherwise the proposal may be badly received. Cordially. —Eihel (talk) 03:49, 1 August 2019 (UTC)
Comment Hi Oursana; shouldn't we broaden the proposal to all types of work's comprehensive lists (like full publications lists)? I would love to have such a tool for researchers, for instance... Nomen ad hoc (talk) 14:34, 2 July 2019 (UTC).
@Nomen ad hoc: I am not quite sure, if I got you right,perhaps you could give an example. The Werkverzeichnis is a very special list, the list for the artist's work, with a great authority.--Oursana (talk) 19:31, 2 July 2019 (UTC)
Support - and with a separate field in the artwork template on Wikimedia Commons --Trzęsacz (talk) 21:09, 3 July 2019 (UTC)
Question Is there a particular advantage to creating this property for use on the artist's item, over the existing pattern of using instance of (P31) = catalogue raisonné (Q1050259) / main subject (P921) = <artist> on the item for the catalogue? Usually we prefer properties in the direction that connects many items to one, rather than one item to many. Jheald (talk) 17:39, 8 July 2019 (UTC)
Comment I agree with Jheald here - the direction of this property feels wrong to me. Is there not a risk that a given item could have a lot of statements for this property? Marking as not ready. − Pintoch (talk) 21:09, 23 July 2019 (UTC)
one item to many?? I do not understand the arguments of Jheald and Pintoch. Could you please give an example and explain. There are very few Werkverzeichnis, normally none to one, maximum very seldom 3--Oursana (talk) 10:37, 24 July 2019 (UTC)
By one item to many we mean that it would be more natural to add a statement in the other direction, from each "catalogue raisonné" to its subject. The many in this phrase does not mean that there would be too many links to do it in the other direction, it is just a description of the relation (see en:One-to-many (data model) ). − Pintoch (talk) 10:49, 24 July 2019 (UTC)
I'm neutral on this one. I'm quite reluctant about creating one to many properties, in this case one person with multiple catalogue raisonnées, but what would be the maximum here? What artist has more than 10 of them? Maybe Rembrandt (Q5598)? @Jane023: as our catalog queen, what do you think? Multichill (talk) 09:40, 27 July 2019 (UTC)
Thanks for the ping. Though I am all for more catalogs raisonné on Wikidata for artists, the catalogue raisonné (Q1050259) is currently also in use for all sorts of things, not just "all works by artists", but also "all items in collection". That said, yes it would be nice to have a link from the artist to an item about their most notable (or only!) monograph. But the problem here is exactly the same as the one for the "Notable print" proposal for paintings that I had before. Who is to say that the notable print is indeed notable? Is it notable because it made the painting famous? Or is it notable because it was copied by a notable painter? Or was it made when the painting was in an important collection? Though valid, those questions don't even come near the crux of the matter which is that the print (or catalog in this case) has a specific instance as an edition. Do we want all editions and/or translations? I think not. The way to handle the problem this proposal tries to address is to try and address the issue of having a "reasonator-like link" on the artist page that will point the reader to all Wikidata resources available, such as the creator lists of course, but also (and not limited to) the catalog raisonné listeria list (if it exists). Signed, the catalog queen! Jane023 (talk) 10:18, 27 July 2019 (UTC)
Comment Pinging project Jean-Fred (talk) 16:48, 6 July 2019 (UTC)
Well, I opened one of the links, and after about 20 seconds of loading the site asked me for signing in. Everybody sees same or does it depend on country you are based in? --Wolverène (talk) 17:15, 6 July 2019 (UTC)
Same for me, and by the screenshoot on the main page (section "rich data"), I assumed login is required to browse data. And its Wikipedia article says that it "recommends movies for its users to watch, based on their film preferences using collaborative filtering of members' movie ratings and movie reviews" .Esteban16 (talk) 21:18, 6 July 2019 (UTC)
Then it's not obvious how it will be helpful for Wikimedia editors/readers which may not have a wish to waste time on creating account in a highly specialized site. --Wolverène (talk) 21:57, 6 July 2019 (UTC)
Agree. That leans me to Oppose this proposal. Despite the useful data it may contain, to be required to have an account makes it unpleasant. Esteban16 (talk) 22:18, 6 July 2019 (UTC)
Currently for this purpose start time (P580) and end time (P582) are used. This is incorrect as the english description of both implies that they can be used to express the date an item, like a collection, begins to exists. Clearly the date here is not the date the collection begins to exists but the date of the items that it collects begins to exists themselves, so this is not a good use. We need new properties to correct this bad and conflicting use.
author TomT0m / talk page 14:42, 10 July 2019 (UTC)
The name doesn't seem yet to be clear to me. Are there other databases that already have a name for this property? Why should the property be named "begin..." and not "start..."? Very little property names use brackets in their name. Do we really want to have them here? ChristianKl ❪✉❫ 10:05, 16 July 2019 (UTC)
Support Seems to meet a need. Anchardo (talk) 08:35, 19 July 2019 (UTC)
Support Je vote pour, plus adaptée pour la détermination de périodes historiques Tatakdh --Tatakdh (talk) 10:38, 19 July 2019 (UTC)
Comment I removed "ready" from the 3rd proposal. The samples don't seem to match the definition. Please fix first. Oppose as presented. --- Jura 17:12, 19 July 2019 (UTC)
@Jura1: Can you be more specific ? Is this the « Auswitch » example you have a problem with ? This is meant to refer to the historical period of the concentration camp, and there is indeed begin date and end date about this period in the item, as qualifiers of the instance of (P31) statement. This could do the trick if we consider the « historical period » aspect of items values of this property. But maybe you would expect plain statements such as start time (P580) / end time (P582) or inception (P571) / dissolved, abolished or demolished (P576) on the items as a definition of the « historical period » associated to an item ? Or would you more expect only instances of
as authorized values for those kind of statements ? author TomT0m / talk page 10:00, 20 July 2019 (UTC)
There doesn't seem to be an end date. It's not even clear it's a time period. I'm sure you can come up with samples that match your definition. Looks like we lack three samples for the first two as well. In that case, this isn't actually ready either. A link to external website doesn't work for samples. --- Jura 10:33, 20 July 2019 (UTC)
Support all, although I'm not sure example 2 for the third property (the Auschwitz one) would be appropriate. For that example maybe something like main subject (P921) might be better, especially since the first two properties would be used to indicate the time period. Jc86035 (talk) 16:20, 26 July 2019 (UTC)
I agree with Jc86035 on the the Auschwitz example - it does not seem suitable to me so I have marked the remaining property as not ready until there is an agreement on this. − Pintoch (talk) 17:48, 27 July 2019 (UTC)
@Pintoch: I have added some further possible examples. A challenge is to identify relationships that would not be better described by main subject (P921) on the one hand, or the new specific start-year and end-year properties on the other. I am not sure I have succeeded -- others may be able to suggest better choices. Jheald (talk) 19:27, 27 July 2019 (UTC)
Notified participants of WikiProject PokémonWD:PKMN seems dead so I make this proposal here, without a earlier discussion. Some Pokémon species change, they evolve and since 2nd generation they can also recess by making an egg and sometimes the original Pokémon must own an item. There are also many ways to evolve a Pokémon: some by level, some by giving a stone, some in a particular (and unmappable singularly) way (e.g. by level and turning 3DS upside down, under the rain or when another Pokémon reach a level, there is room in the team and you have a Pokéball in the bag). This kind of information is important and must be mapped in Wikidata but as long as it need some subproperties to define the way to evolve, I think this needs a standalone property.
The name of the property is temporary so if needed, change it.
I'm going to show you how to map items: the property will be useful for both evolution and "deevolution" (I don't think there is a specific term for that kind of operation). The property must have one of these as statement, for each way of (de)evolving:
leveling up with high level of friendship
leveling up while holding an item
leveling up while knowing a certain move
leveling up in a certain location
leveling up during a certain time of day
leveling up while holding an item during a certain time of day
leveling up while is a certain gender
leveling up in a certain game
leveling up with a certain Pokémon or Pokémon of a certain type in the party
leveling up while the Nintendo 3DS is upside-down
leveling up a Pokémon during certain types of weather.
trading the Pokémon
trading the Pokémon while holding an item
trading the Pokémon for specific Pokémon
using an evolutionary stone on it
by a particular method
breeding while holding an item
Items must be created yet. Then:
In case of leveling up, it needs numeric value (P1181) to define which is the lower level in order to trigger evolution
In case of move/type of move to be known, the time of day, the gender, the game, the Pokémon/Pokémon type, the weather, the specific Pokémon to be traded and the evolutionary stone to be used, the property applies to part (P518) should work well.
Every statement should have also direction (P560) in order to define which Pokémon you get after the (de)evolution.
I think I wrote everything. During next week I will create items about evolution, if a sort of consensus is found --★ → Airon 90 09:24, 3 October 2018 (UTC)
How do you handle the fact that different Pokemon editions have different rules? ChristianKl ❪✉❫ 13:30, 31 December 2018 (UTC)
This property could be used also to map mega evolution (Q16577590), as example 7, but I don't know how to link back, as I don't think it is possible to use the same property again. --★ → Airon 90 09:32, 3 October 2018 (UTC)
Comment I know we have lots of Pokemon items, but this seems awfully specific for a property. Could you perhaps use instead followed by (P156) or a similar property, with appropriate qualifiers? ArthurPSmith (talk) 18:01, 4 October 2018 (UTC)
I already considered this option but don't think it is useful, because it would need a qualifier for the qualifier and as of now, Wikidata doesn't have such option: indeed, if I use followed by (P156) then I need a qualifier to define how the item (de)evolves into that specified Pokémon and then I need a qualifier for the qualifier to clarify level/item/Pokémon/...
See examples in order to understand how many data would this operation needs.
Other way to mapping these data are obviously welcome! --★ → Airon 90 06:48, 7 October 2018 (UTC)
EDIT: IMHO, I also think that it doesn't have any sense to partially map the way of evolution. It is useless to just know that certain Pokémon evolve leveling it up or trading it with another Pokémon withour specifying the level which it evolve since or the Pokémon needed to be traded to trigger evolution. I think that either we allow mapping all data properly or it is useless partial work and it would be then better not to map at all these data :) --★ → Airon 90 06:53, 7 October 2018 (UTC)
How do you handle the fact that different Pokemon editions have different rules? ChristianKl ❪✉❫ 13:30, 31 December 2018 (UTC)
@ZI Jony: Sorry, where is the «lack of consensus»? --★ → Airon 90 07:10, 9 July 2019 (UTC)
Given that nobody voted against this propsal, I don't feel the need to close it and reopened it. Plenty of proposals are open for more then 3 months. ChristianKl ❪✉❫ 07:24, 15 July 2019 (UTC)
Weak oppose I'm not sure Wikidata is the place to get so specific on the mechanics of one specific game. It's Pokemon now, and what other game will come later? NMaia (talk) 06:31, 18 July 2019 (UTC)
@NMaia: That info is mapped in many infoboxes, so I think it is somehow useful to Wikipedia, otherwise this info would not be inserted there. If info about other games should be added then we decide what to do later. If you think that this info could be mapped in another way I am open to listen to your proposal ;) --★ → Airon 90 07:29, 18 July 2019 (UTC)
Support. Since there are loads of Pokemon fans editing Wikidata and Wikipedia, and Pokemon is already deemed notable for Wikipedia, the argument of "we can't have properties for every fantasy" is moot. If there were no community behind it, we couldn't, but since there is a lot of interest, it won't be an issue. This point can be raised once somebody wants to make a property for something more obscure. --Ysangkok (talk) 16:02, 31 July 2019 (UTC)
@MJL: Either you didn't read the proposal or you didn't understand it. appears in the form of (P4675) is about what an item turns into (Zeus into a *bull*), my proposal is about how an item turns into another item (Bulbasaur into Ivysaur *by levelling it up* to 16). I am not a Digimon fan and AFAIK this proposal is not useful for Q2577011, unlike mega evolution (Q16577590) as megastonesare different from each other.
I would broaden the scope a bit, but I don't see how to do that. We can broaden the scope later, too. --★ → Airon 90 07:13, 11 September 2019 (UTC)
Not in general, only for the relevant part in the (first) sample above. Similarly column (P3903) didn't replace it either. Maybe "verse" would need to be deleted from the label of P958. --- Jura 11:30, 11 August 2019 (UTC)
Support so. (And the current proposal to be entitled "line(s)/verse(s)".) Nomen ad hoc (talk) 12:43, 11 August 2019 (UTC).
I'm fine with having it as an alias, but w:line (poetry) compared to w:verse (poetry) has the advantage of not having too many other meanings. --- Jura 12:54, 11 August 2019 (UTC)
The canonical (official or recognized) translation of the title of an work (usually an scientific article) in a foreign language (usually English), where the work itself is usually not translated. It is usually translated by the author of the work.
Comment I'd argue the referenced edit was in error. If the article has an official title in any language, that should be under title (P1476), with the appropriate language tag. This doesn't seem in any way wrong or confusing. ArthurPSmith (talk) 16:45, 22 August 2019 (UTC)
Why would we do it differently for Chinese articles? --- Jura 20:01, 22 August 2019 (UTC)
Why would this be special for Chinese? Articles in Canadian media may have both a French and English title, and I'd consider it the right thing to do to add both to the Wikidata item. ArthurPSmith (talk) 18:01, 23 August 2019 (UTC)
Thanks for clarifying your POV. --- Jura 22:38, 23 August 2019 (UTC)
Label can not be sourced and does not imply the translation is official.--GZWDer (talk) 22:14, 22 August 2019 (UTC)
Comment Some further clarification needed as to how the usage of this property would differ from the present practice of adding literal translation (P2441) qualifiers to the title (P1476) statement to give translations of the title into different languages. Do we need both approaches? Can we clearly identify when one should be used rather than the other? Jheald (talk) 18:55, 26 August 2019 (UTC)
Support given that labels in some fields are polluted with not translated titles. Should we also allow translated titles by, e.g. pubmed? Many English titles seem to come from there, but I don't think this matches the current definition. Any that can be referenced? --- Jura 09:53, 13 September 2019 (UTC)
James A. Farley Papers (NAID 146765098) (Q66759541) → "The papers of James A. Farley consist of letters and a telegram from Harry S. Truman to Farley. The subject matter varies from responses to recommendation letters sent by Farley, to discussion of the political climate in Missouri during Truman’s time as a Senator."
Rafael Pico Papers (NAID 146765108) (Q66759542) → "The papers of Rafael Pico are composed of correspondence from his time as President of the Puerto Rico Planning Board, as well as letters related to his nomination as Commissioner of Education of Puerto Rico. Many of the papers concern his later appointment by President Harry S. Truman as a member of the Anglo-American Caribbean Commission."
Madge Gates Wallace Papers (NAID 2642226) (Q59495126) → "The Madge (Margaret) Gates Wallace Papers contain bank statements, canceled checks, receipts, correspondence, invitations, memorabilia, printed material, and other items relating to her life and family. Madge Gates Wallace was the first daughtof George P. and Elizabeth Gates, and the mother of Bess Wallace Truman."
Scope and content (or a "scope and content note") is a standardized data field used in finding aids or catalog records for describing collections in archival science. It is usually a brief narrative field in which the archivist gives a formal overview of the collection in a human-readable statement. The A Glossary of Archival and Records Terminology (Q59211060)describes it as "A narrative statement summarizing the characteristics of the described materials, the functions and activities that produced them, and the types of information contained therein." It is defined in data standards such as DACS, Library of Congress, Jisc, and NARA. Note that it is typically considered mandatory for describing archival collections.
Please note, though it may seem unstructured, this is not the same as Wikidata's "description" field, and that is why a property is necessary. It is a defined field from the data standard, with a specific meaning, and archivists follow a certain procedure in constructing it. Dominic (talk) 20:44, 26 August 2019 (UTC)
Updating per Will's suggestion below, a description I am using for one of the examples above is "collection in the National Archives and Records Administration's holdings". We don't usually put much more detail than that in the Wikidata item description, so that's how scope and content differs. Dominic (talk) 14:02, 30 August 2019 (UTC)
Support This is great. It may be worth contrasting a Wikidata description example agaainst a scope and content example in this proposal so editors less familiar with this can distinguish the two. Wskent (talk) 21:46, 29 August 2019 (UTC)
I understand your point of view, but I don't share it. --- Jura 15:03, 6 September 2019 (UTC)
It's fine to have a considered opinion on a topic, but I have linked to actual data standards this property is defined in, so you cannot simply call it "unstructured" and say we have a different point of view. Dominic (talk) 15:33, 6 September 2019 (UTC)
It's a summary text, just like a Wikipedia article. Wikipedia isn't actually unstructured either, but it's generally seen as such from a Wikidata point of view. --- Jura 16:04, 6 September 2019 (UTC)
It's not similar at all. You are conflating all strings of descriptive text, referring to it as "unstructured," whereas this one is actually a required field in widely used data standards–which is different from just making a free-text field Wikidatans can put descriptions in. Dominic (talk) 19:23, 9 September 2019 (UTC)
Not sure if people doing Blazon descriptions would appreciate that. Blazon descriptions can appear cryptic, as the vocabulary being used in highly specialized. How is that different from what you are proposing? --- Jura 18:43, 11 September 2019 (UTC)
I think you are confused, because I didn't say anything about cryptic vocabulary being a good or bad thing. We are not here to argue for or against that other property, either. I am talking about a having a property so we can import particular fielded data, about items we already describe, from JSON- or XML-encoded archival datasets using professional data standards. You are calling that unstructured, which is just not true. If you believe a particular type of data is not appropriate for Wikidata, that is one thing, but it actually seems like you just have an axe to grind. Dominic (talk) 23:43, 11 September 2019 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘Comment Just to summarize: it's a free text field and as such I oppose its creation. --- Jura 02:37, 12 September 2019 (UTC)
@Jura1: Repeating your falsehood with a "Comment" and unindenting does not make it true. It's kind of rude. You are saying "free text" to imply anyone could put whatever they think in the field, whereas the actual proposal is for importing a data element from archival descriptions, which are generated by trained archivists at the repositories that contain the collections. It is a text field, but not in any way "free" text. Dominic (talk) 15:39, 12 September 2019 (UTC)
I think we know about the problems with your imports, but this no reason to accuse people who review your addition of falsehood. It's probably preferable if you just link the source: this would avoid the problem with had with your previous import of 200,000 defective statements. You could use Wikisource or Commons for this set of free text descriptions. They are made for that. --- Jura 15:48, 12 September 2019 (UTC)
Support Just to make clear my support for this. ArthurPSmith (talk) 17:10, 6 September 2019 (UTC)
Support - PKM (talk) 19:11, 8 September 2019 (UTC)
I'm not against the property itself, but I'm a bit worried that this is going to be filled with non-CC0 content, and therefor opening up a possible license issue, content wise. If the field is going to be filled with copy/paste texts from an archive website, it will not contain CC0 texts, and might therefor not belong to WikiData at all. Edoderoo (talk) 07:06, 12 September 2019 (UTC)
@Edoderoo: That is for the editor to determine, just as with other string properties (e.g. "excerpt" or "quotation"). My data source, for example, is a US government agency, and the values would all be PD. If an institution claims copyright, then it would not be able to be imported, but Wikidata already has policies for that. Dominic (talk) 15:31, 12 September 2019 (UTC)
Oppose I have read the arguments above by the proponent. I think if the text has a restricted vocabulary, you should make an ontology and import it. If it's not formalized it either should be, or it is free text. I agree that the description field often has problems but that should be addressed elsewhere. --SCIdude (talk) 11:43, 12 September 2019 (UTC)
@SCIdude: I suppose you're against titles, then, since they do not use a controlled vocabulary? I don't understand where these arguments are coming from. It doesn't align with actual practice on Wikidata. Dominic (talk) 15:31, 12 September 2019 (UTC)
@Dominic: Titles and descriptions, and what else? --SCIdude (talk) 15:56, 12 September 2019 (UTC)
@SCIdude: The description is not a property, as that truly is free-text, but I am talking about the fact that Wikidata does allow and encourage many properties with non-controlled vocabulary values, such as "title", as long as they have a clear scope and rationale (as in this case). This is what the monolingual-text datatype is for. Just because the value does not consist of an entity (Item datatype) does not mean there can't be a single true value. It's not a free text field, as claimed above. Dominic (talk) 16:24, 12 September 2019 (UTC)
There are standards on what to add to a Wikidata item description, just as there are for blazon descriptions or the property you are proposing. --- Jura 10:27, 13 September 2019 (UTC)
I posted there already when this property was proposed. Also, for what it's worth, I work at the US National Archives, and have specialist knowledge (which I have been sharing in the form of this proposal :) ). Dominic (talk) 19:36, 12 September 2019 (UTC)
All right, I didn't see it. And yes, I know you are; I should have said "other specialists" instead. Cheers, Nomen ad hoc (talk) 20:09, 12 September 2019 (UTC).
Comment Dear @Dominic:, we, archivist, have to recognize this proposal as a borderline cas for Wikidata. String values are exceptions in Wikidata Properties and string with many sentences even more. "Scope and Content" is one of our keys standards description properties but not one obligatory. The really great job you make in Wikidata with archiv of NARA will it be stop without this properties? @Wskent, ArthurPSmith, Nomen ad hoc, PKM, Edoderoo, SCIdude: @Gilliane, Anchardo, LuciOle: --2le2im-bdc (talk) 06:39, 13 September 2019 (UTC)
Support obviously, this seems to be an essential part of archiving procedure. Cheers, VIGNERON (talk) 08:20, 13 September 2019 (UTC)
Neutral per 2le2im. Furthermore, chat about widening corporate purpose (P6346) (also a string-text property) to all kinds of project, unit or group officially proclaimed scopes (@Dominic:)? Nomen ad hoc (talk) 10:21, 13 September 2019 (UTC).
@Nomen ad hoc: Sorry, late reply, but regarding your suggestion, I think there is probably a distinction to be made between "authoritative" (as in, how it is described by some qualified source, such as a relevant heritage organization) and "official", (which is to say, probably found in a legal document, and generated by the corporate body itself, as seems to be the intention of corporate purpose (P6346)). For thinking about the "authoritative" meaning, we might look to descriptive elements for authorities are defined in data standards, such as DACS Description of Person, Family, or Corporate Body. I am not as well-versed in authorities, but I do think it's worthy of further discussion. Dominic (talk) 16:50, 2 October 2019 (UTC)
Support Speaking as an archivist and someone who builds archival discovery systems, this is needed. The extent to which it is a required element from the standpoint of descriptive standards varies, but for example in Describing Archives: A Content Standard (Q5263780), it is required for single-item or top-level archival descriptions. Anarchivist (talk) 18:29, 25 September 2019 (UTC)
I think there are other fields that could benefit from a synopsis fields. It's just that we generally leave that to other WMF sites. --- Jura 15:46, 4 October 2019 (UTC)
We could use both proposed properties for Wikidata items about coins & emails, also. However, I oppose under the proposed name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:14, 13 September 2019 (UTC)
? this property is for front and backside of the same specific object, coins or not. For another use then that should be another property. Christian Ferrer (talk) 09:32, 14 September 2019 (UTC)
Oppose The proposed relation is between two digital representations of a single object; I think this is the wrong way to model it. The subject of such a relation should be the object itself (i.e. an item representing the object), not its digital representation. And I think we already have a property that handles this: digital representation of (P6243) - just attach a qualifier to indicate which side of the object is being represented by the file. ArthurPSmith (talk) 16:40, 13 September 2019 (UTC)
@Andrew Gray: I understand that it may be theoretially appealing, but I don't think it's a good idea to make separate items for Commons files happen to based on a scan of a printed photograph. --- Jura 19:01, 13 September 2019 (UTC)
@Jura1: Good catch - I think I had assumed this would be used for existing items describing the works, rather than new items for each image file (which, as you say, is not desirable on Wikidata). Presumably the property as described would be useful for structured data on Commons but not intended to be used on Wikidata items? That seems more reasonable.
(For paintings with two sides where both are significant works in their own right, agree two items makes sense.) Andrew Gray (talk) 19:37, 13 September 2019 (UTC)
@Andrew Gray: is there some aspect of your oppose we haven't addressed yet. I'd try to include it. --- Jura 08:57, 20 September 2019 (UTC)
@Jura1: If it's clear this is for linking media files together rather than for use on normal items, I'm fine to Support the proposal with those limits. It certainly sounds useful. I agree with Arthur that it might be simplest to just have one property - "image showing other side". Andrew Gray (talk) 10:25, 22 September 2019 (UTC)
The first one might also have a use for cases like the oxbow sample above (fixed the filename just now, see comment below). --- Jura 17:09, 23 September 2019 (UTC)
@Thierry Caro: do you think there something else that needs adding? --- Jura 08:56, 20 September 2019 (UTC)
Comment Ok, if this is intended ONLY to apply to commons files which have no associated item, they why is more than one property needed? Something like "image of opposite side" would cover both cases just fine. ArthurPSmith (talk) 14:02, 16 September 2019 (UTC)
Question Will the inverse constraint work with itself? I guess yes... Christian Ferrer (talk) 17:41, 16 September 2019 (UTC)
Yes that would work. Actually you might get more votes by suggesting both properties for a WGA painting currently lacking an item. So the main point of this proposal is that my original comment in the Commons discussion doesn't work. There I said that you need a Commons-based placeholder for the "thing itself" which normally lives on Wikidata for notable paintings. As far as the recto/verso thing goes, your proposal applies beter to e.g. this: File:Huys Dever -Ego sum pastor bonus.jpg as well. Jane023 (talk) 07:25, 20 September 2019 (UTC)
@Jane023: At this stage, I mainly try to integrate and improve the proposal based on constructive input received (or formulate an entirely different one). I think it's important to delimit the proposal to properties used for two-sided artworks (done above now). Also to use for actual backsides of paintings hadn't occurred to me, but somehow it does seem missing. I think some art historians like to see them even if images aren't necessarily easily available (added the sample above now). File:Giovanni di Paolo - Virgin and Child - WGA09479.jpg mentioned above didn't actually have an item prior to this proposal. --- Jura 08:56, 20 September 2019 (UTC)
SupportDavid (talk) 16:28, 24 September 2019 (UTC)
Comment Is there some reason you picked String datatype instead of Quantity (integer values are fine) or even Item (we have items for all integers up to many thousands)? ArthurPSmith (talk) 19:24, 24 September 2019 (UTC)
That means one would need to know all characters, enter all characters, be sure that a given Wikidata item includes all characters. Not sure how one could do the last one and if it's efficient to do the first two in advance. --- Jura 15:43, 4 October 2019 (UTC)
“one would need to know all characters” → Are there cases where one would know the number but not have the list? Jean-Fred (talk) 17:05, 4 October 2019 (UTC)
I'm not sure about the need for this property as I don't edit these items, but I tried to spell out what would the underlying assumptions of the "use P674" argument. I don't think it's comparable with "number of editions" as that is not a static number. --- Jura 11:39, 5 October 2019 (UTC)
Well, from a gamer's point of view, i just don't see how this property could be useful, that's why I wrote I'm skeptical. It's much more informative to write for example, that one can choose Raiden, Sub-Zero or Scorpion in Mortal Kombat (Q150294), than to say it has max. number of 7 playable characters. Sir Lothar (talk) 08:39, 7 October 2019 (UTC)
Support Thanks for creating this. I am now wondering if it is only useful for paintings with frames. I can imagine in the case of sculpture, you might want an image of the whole gallery, and for historic events such as movements of large paintings, you might want a picture of it in transit. So this property could be in use more than once when paintings go on show in exhibitions and they are hung next to a copy or pendant or some other interesting combination. Jane023 (talk) 08:19, 5 October 2019 (UTC)
@Jane023: I'm a bit hesitant about including 3d works. To some extent, these tend to include surroundings. How should we delimit them? I'd tend not to include them. --- Jura 08:43, 5 October 2019 (UTC)
It has to do with context. So you could have this property on an exhibition history statement, or you could have this property as a qualifier on the image statement (if you are just including the frame). Consider this as an example of a pendant pair in an exhibition location: File:Cornelis Janssens van Ceulen - Jasper Schade and his Wife Cornelia Strick 20180716 058.jpg. You could just include the image with frame for each portrait separately, but having the pendant painting also showing in the image adds important context that the frame alone doesn't show. Jane023 (talk) 08:51, 5 October 2019 (UTC)
@Jane023: I think the above sample would be covered. With 3d works I meant sculptures. --- Jura 09:01, 5 October 2019 (UTC)
Support Very valuable, a) to have the additional link to a painting, showing its frame; and b) to take such images as far as possible out of the regular stream of P18 links. Jheald (talk) 15:46, 7 October 2019 (UTC)
@HedgeHog: I tried to create this property but an automatic check failed: example value "Dan Simmons" does not match regular expression \d+. Please fix your proposal and your property will be created shortly. This is an automated message but do not hesitate to ping me if you need any help. − Pintoch (talk) 08:22, 15 October 2019 (UTC)
@HedgeHog: I tried to create this property but an automatic check failed: label and description are identical for languages ru and en. Please fix your proposal and your property will be created shortly. This is an automated message but do not hesitate to ping me if you need any help. − Pintoch (talk) 09:53, 15 October 2019 (UTC)
@Pintoch: Descriptions for property have been fixed. HedgeHog (talk) 11:36, 15 October 2019 (UTC)
An image of a painter's signature on a work can make it easier to compare them with signatures of the same painter on other paintings. I don't think the existing signature (P109) would be suitable as it's meant for items about people and its definition of "signature" somewhat differs.
One downside to that approach: Sometimes sources blow up the signature but have the painting as a whole at a resolution where the signature by itself is not clearly visible. Calliopejen1 (talk) 16:35, 14 October 2019 (UTC)
Support I always try to make a detail of the signature, if I spot. Would be nice to have a field to link that in Wikidata --Sailko (talk) 06:57, 15 October 2019 (UTC)