Wikidata:Property proposal/Creative work

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

See also

• Wikidata:Property proposal/Pending – properties which have been approved but which are on hold waiting for the appropriate datatype to be made available
• Wikidata:Properties for deletion – proposals for the deletion of properties
• Wikidata:External identifiers – statements to add when creating properties for external IDs
• Wikidata:Lexicographical data – information and discussion about lexicographic data on Wikidata

This page is for the proposal of new properties.

Before proposing a property

1. Search if the property already exists.
2. Search if the property has already been proposed.
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. Read Wikidata:Creating a property proposal for guidelines you should follow when proposing new property.
6. Start writing the documentation based on the preload form below by editing the two templates at the top of the page to add proposal details.

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 creation of 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 2024/10.

Creative work / Werk / Œuvre créative

See also: Wikidata:Infoboxes task force/works

Software products and brands, see: Wikidata:Infoboxes task force/terms

Books, see: Wikidata:Books task force

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

In trying to standardize data for Wikidata:WikiProject_Music I'm realizing there needs to be a music equivalent of edition or translation of (P629) in the way Wikidata:WikiProject_Books uses that property. For instance, MusicBrainz distinguishes between the composition itself (at the work level, like O Holy Night here and an individual recorded performance of it, like the single O Holy Night (Q7073262) performed by Ladywell Primary School (Q6470821). Rather than add the composer and lyricist for every single recording of this, they should just link to the primary original composition. Sweet kate (talk) 04:35, 9 December 2014 (UTC)

•  Comment I´d like to use it more general also for performances or live shows: "recording or performance of".  Support--Giftzwerg 88 (talk) 11:29, 9 December 2014 (UTC)

That change is fine with me. Sweet kate (talk) 21:00, 23 December 2014 (UTC)

•  Support. Filceolaire (talk) 20:35, 7 March 2015 (UTC)
•  Comment I am in support of a "recording of" property, but how exactly is musical release (Q2031291) being defined here? It seems to be a different usage than what MusicBrainz has. Given that the proposed analogy is to edition or translation of (P629), which apparently mixes text translations with book printings, perhaps in that sense it is appropriate to mix recordings with releases. My preference, though, would be to differentiate a derivative creative/intellectual work from a product issuing. Perhaps this is beyond the scope of this discussion, though. Dancter (talk) 20:14, 11 March 2015 (UTC)
  • Dancter an edition or translation of (P629) is not a reprinting of the same text. It is a new derivative work with changes from the previous edition. In the same way the recording of a performance of a piece of music or a play is different from other performances. It has a different arrangement (and arranger) and producer and director. In most cases a theatrical run of a play will be one item and this will be a 'performance' of the play item but sometimes the London and New York productions of the play will be different enough to count as different productions with separate wikidata items. In most cases a series of concerts will be a single item but in some cases (e.g. the Amnesty International series of concerts around the world with different lineups in each country) separate items may be justified. Filceolaire (talk) 22:31, 18 June 2015 (UTC)
    • Perhaps I was mistaking the approved usage of edition or translation of (P629) based on some erroneous instances, as to be acceptable for editing (Q397239) as opposed to being specifically for version, edition or translation (Q3331189), but again, in practice there doesn't generally seem to be clear delineations between issuings/publications and works/texts on Wikidata. Using "edition" in yet another sense: although a recorded performance is also a derivative work, it is not an edition of the original piece, nor does it in itself establish a new one. There are many cases in which a different recording or performance of a song is of the same arrangement.

I am somewhat wary of generalizing "recording" to "recording or performance," as in "audio production, regardless of whether a recording was made." Expressing "audio performance of" through a separate property does not add that much complexity, yet would provide for a much cleaner exchange with more mature systems, such as Music Ontology, or even just the MusicBrainz schema. I am definitely not in favor of diluting "performance" in this case beyond "individual audio performance" or even performance (Q35140) in general to other concepts that are performance-related, but not technically performances themselves. Just by the grammar of it, a run of a theatrical production is not the same as a performance of a play, and a leg of a concert tour is not the same as a performance of a concert. Dancter (talk) 01:05, 22 June 2015 (UTC)

• @Sweet kate, Giftzwerg 88: any comment on the above? MSGJ (talk) 21:25, 10 June 2015 (UTC)
•  Comment, Why not to use edition or translation of (P629) for musical albums too? --Infovarius (talk) 09:58, 9 August 2015 (UTC)
  • Because a recording of a work is quite significantly different in meaning from an edition of a book... —Tom Morris (talk) 16:18, 27 November 2015 (UTC)
•  Comment It may be useful to use FRBR terminology, at least for comparison. Literally speaking, "Recording or performance of" seems synonim to "embodiment of" (a manifestation "embodies" an expression). edition or translation of (P629) could be made more general (and precise) by renaming it to "realization of" and then it could be used for music too. Federico Leva (BEIC) (talk) 12:15, 31 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

Motivation:

Proposed by: SamB (talk)

Well, it'd be nice to be able to tie the items for programming languages and the items for the relevant implementations together somehow; this seems a straightforward, appropriate way. SamB (talk) 20:31, 23 April 2015 (UTC)

Could we make this more generic? Say have a property that specifies the standards that the output files comply with like writable file format (P1073) (or extend P1073 so it can be used for this? Filceolaire (talk) 01:47, 24 April 2015 (UTC)

@SamB: Is this indented for query language (Q845739) (e. g. SQL (Q47607), regular expression (Q185612)), or only for programming language (Q9143)? -- Sergey kudryavtsev (talk) 08:18, 24 April 2015 (UTC)

May be better generize: implements the syntax? -- Sergey kudryavtsev (talk) 08:22, 24 April 2015 (UTC)

@SamB: any further response? MSGJ (talk) 21:39, 10 June 2015 (UTC)

@MSGJ: uh, yeah, generalizing this enough to include query languages like SQL or XPath whatever would't be a terrible idea; perhaps it should be "implements computer language"? That could even work for programs that implement the JVM or .NET's CLI. (By the way, any ideas about how to represent the output language(s) of a compiler? Should every ISA also count as a computer language?)

[Oops, I forgot to sign this last night! SamB (talk) 14:25, 11 June 2015 (UTC)]

I would even further generalize and also include emulators or VMs. Rename the property implements, with software as domains, and programming languages, specifications and computer architectures as ranges. But we would need maybe to sort out the compilation/emulation stuff. It's pretty clear that a compiler produces programs in output and that emulators or virtual machines just executes ... That's too kind of implementation TomT0m ^(talk) 10:48, 11 June 2015 (UTC)

 CommentProperty proposals about computing should have their own section, currectly some are also done in Natural sciences ...

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Now filming technique is marked either by genre (P136) or simplify by instancing type of film (Last Year's Snow Was Falling (Q4341995) instance of (P31) clay animation film (Q18089617)). Although I am not against second variant, the type "genre" seem to me not exact or simply wrong. I am planning to replace P136 values which corresponds to different animation technique (Q3516833)/cinematic technique (Q1415315) with requested property. Infovarius (talk) 22:23, 1 July 2015 (UTC)

No consensus on original proposal, so changing it according to most comments. Andreasm ^{háblame / just talk to me} 00:14, 9 November 2015 (UTC)

Discussion

 Support As long as it is renamed artistic technique (Q11177771), so it can include also literary technique (Q560311), painting technique (Q1231896), cinematic technique (Q1415315), photographic technique (Q1439691), printing technique (Q3514338), music performance technique (Q6942574), and so on. Andreasm ^{háblame / just talk to me} 02:05, 2 July 2015 (UTC)

• I had a look at what links to oil painting (Q174705) and found The Vale of Rest (Q470541). This has the statement <made from material (P186):oil painting (Q174705)>. I don't think P186 is quite right here and I think a generic version of the property proposed here would be better.  Support if the property is made more general so it can be used for all sorts of art works, as Andreasm's comment. Filceolaire (talk) 01:48, 12 July 2015 (UTC)

 Comment I would indeed use instance of (P31) for that, for example

⟨ Wallace and Grommit ⟩ instance of (P31) ⟨ Stop motion film ⟩

(for example the description of clay animation (Q870889) in english is clear ... stop-motion animation made using malleable clay models it's a subclass of animation movie. Stop motion is an artistic form, like a literary genre (Q223393) so it's essentially a type of work. But I agree we need to be more able to define what is stop motion ... and which type of materials the artists uses when they build the work : drawings for old Walt Disney, CGIs for modern animations, papers, ... so i'll  Oppose the creation of what is essentialy a specialized property, but I will  Support the creation of properties to describe more precisely the material and techniques used for the kind of artworks. TomT0m ^(talk) 18:20, 16 July 2015 (UTC)

clay animation (Q870889) is a technique, so using

⟨ Wallace and Grommit ⟩ instance of (P31) ⟨ clay animation (Q870889)    ⟩

is strange. Instead one can use

⟨ Wallace and Grommit ⟩ instance of (P31) ⟨ clay animation film (Q18089617)    ⟩

. But I'd prefer to use specific type property which would allow to set specific constraints. --Infovarius (talk) 10:58, 9 August 2015 (UTC)

 Oppose as specifically for films, but  Support as a broader 'production technique' (method or technique used to create or produce the subject) that could be used as follows:

⟨ Last Year's Snow Was Falling (Q4341995)    ⟩ production technique Search ⟨ 870889 ⟩

⟨ Ford Model T (Q182323)    ⟩ production technique Search ⟨ Q455037 ⟩

Josh Baumgartner (talk) 07:43, 20 September 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

present in work (P1441) is sometimes used for characters, places, etc. that are barely named in a work but do not actually appear in it, for example the planet Coruscant (Q719329) is named several times in the original Star Wars trilogy, but no action takes place there and no image of the planet is shown. Ash Crow (talk) 16:50, 16 July 2015 (UTC)

Discussion

•  Support. TomT0m ^(talk) 18:04, 16 July 2015 (UTC)
•  Oppose. Things which are barely mentioned in a work should go in the statements about the work, not in the statements about the things. Recast this as "mentioned in this work". Filceolaire (talk) 04:18, 21 July 2015 (UTC)
• +1  Oppose Please refine it. --Succu (talk) 21:06, 7 August 2015 (UTC)
•  Oppose. Where is the separation line between "mentioning" and "full description"? 10 mentions are enough or not? --Infovarius (talk) 11:02, 9 August 2015 (UTC)

• @Filceolaire, Succu, Infovarius: "Mentioned in this work" could be a reverse property but does not remove the need for this one. For example, if I make a list of the Amazons using the Wikidata List template on Wikipedia, I want to be able to show which ancien authors mentioned each of them... And one mention in a list should be enough. -Ash Crow (talk) 20:35, 23 August 2015 (UTC)
•  Support Consider Abraham (Q9181). It would be useful (eg in queries) to be able to distinguish books of the Bible in which he was merely mentioned from books in which he was an active participant. Jheald (talk) 17:50, 14 September 2015 (UTC)
  • and you can do that by wikilinking mentions of him in the wikisource edition of the bible - much easier than trying to do something with wikidata properties. Joe Filceolaire (talk) 23:14, 14 September 2015 (UTC)

•  Oppose present in work (P1441) is useful for any time there is a meaningful mention of an item in a work. If an item is mentioned in a work, then it is present in the work, so having two different properties is just going to be confusing and lead to inconsistent use. Josh Baumgartner (talk) 17:44, 30 October 2015 (UTC)
• Comment: See also Wikidata:Property_proposal/Sister_projects#mentions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:14, 21 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

While most publications contain errors, only a small subset have published errata or corrigenda associated with them. To handle information of the latter kind, I see two main options:

1. going for a dedicated property specific for errata/ corrigenda
2. going for a more general property (e.g. "update") that could comprise other things (e.g. retractions) as well.

I have a slight preference for the first option, which also fits with existing rather specific properties like software version identifier (P348) or has edition or translation (P747) . --Daniel Mietchen (talk) 22:06, 2 August 2015 (UTC)

Discussion

 Comment @Daniel Mietchen: The range seems to me semantically like a diff (Q300901)    or a patch in computing, or an amendment in law. If the property is gerenalized I think it must be looked in that direction compared to generalize to "retractations" which seems semantically completely different (that's more like "unpublication") ...

To me a version is not specific to a software and is just an identifier for an edition, so I'm not sure I would agree with the specificity (wrt. domain) of the properties you mention.

I tend to  Support, although I would very well see the properties appliable also in the domain of law and software with a label like "correction" or modification, with a property range like "delta" (diffs, rectification law) ...

The rule would be apply "delta item content" on "an edition of a work" gives "another edition of a work", so I'll very well see a qualifier "resulting edition" on the statements built with this qualifier. That would give

⟨ EVOLUTION IN MENDELIAN POPULATIONS (Q5418627)    ⟩ corrected/amended by Search ⟨ Q20746731 ⟩
results in Search ⟨ Evolution in Mendelian Populations (corrected). ⟩

for example. author  TomT0m / talk page 09:03, 3 August 2015 (UTC)

• I would certainly prefer a diff-based system for consuming information about corrections, but publishers are not there yet, and certainly have not been in the past. So for corrections already published, we'll have to stick with what is proposed above. --Daniel Mietchen (talk) 03:54, 8 August 2015 (UTC)

Daniel any idea about how we could qualify the nature of a specific correction? I remember some cases where a basionym page was not cited or a spelling error was corrected. --Succu (talk) 19:39, 7 August 2015 (UTC)

• Haven't made up my mind about this yet, but dug a little deeper and found nothing useful in the Citation Ontology but a few useful pointers in this paper and these guidelines. --Daniel Mietchen (talk) 03:54, 8 August 2015 (UTC)

@Succu: perhaps use main subject (P921) on the corrigenda items, with values like typographical error (Q734832) or fraud (Q28813)? Still looking for a suitable controlled vocabulary but found "As of November 2014 the types of update that are accepted as CrossMark status updates are limited to: addendum, clarification, correction, corrigendum, erratum, expression_of_concern, new_edition, new_version, partial_retraction, removal, retraction, withdrawal" at CrossMark", which seems like a useful basis for discussing which terms we might need here. --Daniel Mietchen (talk) 06:55, 16 August 2015 (UTC)

OK, let's try it.  Support --Succu (talk) 22:05, 22 November 2015 (UTC)

--Daniel Mietchen (talk) 23:03, 19 August 2015 (UTC)

•  Support. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:37, 22 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

The narrator is such an essential aspect of storytelling that we should not leave characters (P674) to deal with it. First because there are extradiegetic narrators (non-character narrators). Then also because the narrator may change in one story, so we need to be able to use qualifiers on the names we associate with the property. And the new property will let us call specific items that qualify the storyteller such as unreliable narrator (Q650118) or protagonist (Q215972), as suggested above. Thierry Caro (talk) 02:29, 9 August 2015 (UTC)

Discussion

Thierry Caro Can you fix the examples? the "->" represents the proposed property so the second item should be the value of the property - the item the property links to; in this case the character who acts as narrator. Joe Filceolaire (talk) 22:59, 11 August 2015 (UTC)

The examples are fine as they are but I admit they can be a bit misleading. So please let me explain them. The first example is to show that the value of the property can be a character and I chose In Search of Lost Time (Q464928) as an example because it is one of the most commonly used examples in narratology (Q382451) after Gérard Genette (Q266247) developed key concepts using that work as his main source material. Narrator (Q3336121) is both the narrator of the story and a character in the novel but we don't really know his name, except for one passage, and so critics usually call him Narrator (Q3336121). So In Search of Lost Time (Q464928) → Narrator (Q3336121) is correct. As for the second example, it is here to show that the property could be used out of the literary field - for instance for movies - but also to show that we might use it with a value that would not be a character but instead one of those items about narrator-related concepts that we have here and that are used in narratology (Q382451), such as unreliable narrator (Q650118). At some point I think there will be more options because I think I will soon create entries for 'homodiegetic narrator', 'heterodiegetic narrator', 'intradiegetic narrator' and 'extradiegetic narrator', etc. All these concepts, again devised by Gérard Genette (Q266247), are the common way to describe a narrator in the discipline. And so The Usual Suspects (Q132351) → unreliable narrator (Q650118) is also correct! Thierry Caro (talk) 17:16, 12 August 2015 (UTC)

I would expect something more of Joseph and the Amazing Technicolor Dreamcoat (Q1708306) => Maria Friedman (Q1165133). Mbch331 (talk) 17:34, 12 August 2015 (UTC)

If an actor is widely credited as a narrator I see no reason why they should not be accepted. Whatever, your question is interesting because there might be, for these kind of situations, a potential overlap with voice actor (P725). Maybe the latter one should change its English description? All other languages might use this only for people who dubbed a movie originally in another language while English users, with the current description set as 'voice actor', might also use it for actors who only use their voice but don't appear in a movie shot in their language. The property discussion page suggests that it was created to deal only with changes of language but the English description seems looser creating a potential collision with the property I suggest. The problem has been raised by a user back in 2013, with no answer. Thierry Caro (talk) 23:18, 12 August 2015 (UTC)

I oppose this if it is to be used in the way described by Thierry above. Instead I propose

1. If the narrator is a character then the item for that character should be the value for this property.
2. If the narrator is not a character in the book then don't use this property.
3. If the character is in the book but not named then create an item named 'unnamed narrator' with description "of <name of the book>" and refer to 1. above
4. If there is a narrator in a film or a play then name the actor and use the "Character role" property (or the "as" property) to say that this actor played the narrator. This might use a generic 'narrator' item.
5. Add the qualifier <instance of:unreliable narrator> as a qualifier to this new property where needed. Joe Filceolaire (talk) 22:27, 23 August 2015 (UTC)

I have to admit you totally nailed this! I support this version now. Thierry Caro (talk) 01:58, 26 August 2015 (UTC)

Then I  Support. Can you rewrite the example based on this? Joe Filceolaire (talk) 22:11, 26 August 2015 (UTC)

@Thierry Caro, Filceolaire: Is this resolved? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:50, 29 December 2015 (UTC)

I think it is. Joe Filceolaire (talk) 18:16, 29 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Basic info for broadcast productions (production company (P272) + year of production). The date a radio drama has been produced can be different from the (often unkown) date it has been first broacasted (original broadcaster (P449) + publication date (P577)). --Kolja21 (talk) 13:21, 10 September 2015 (UTC)

Discussion

Why not just use inception (P571) ? Jheald (talk) 17:26, 14 September 2015 (UTC)

inception (P571) is too broadly interpreted. It could be the start of production, or even the first time the work emerged as a concept. Josh Baumgartner (talk) 21:20, 14 September 2015 (UTC)

 Oppose Production covers a span of time (we do not currently have a data type for this). As I understand it, the 'production date' generally cited however is the completion of the production. If this is indeed the intent of this property, it should be re-labelled and described accordingly: date upon which production of a creative work is completed or some such. Additionally, the domain should be work (Q386724) as there are several subclasses of this that this could apply to as the completion of creation as distinct from the point of release/publication/broadcast. Josh Baumgartner (talk) 21:20, 14 September 2015 (UTC)

@Jheald: This property is used with dissolved, abolished or demolished date (P576) for en:Template:Infobox company: An organisation was founded and will be closed one day. (For a broadcast production that might or might not be the day the script has been finished ("written on date"), the day the production has been announced etc.) Imho we shoulded mix to many things in one property. --Kolja21 (talk) 21:27, 14 September 2015 (UTC)

@Kolja21: We use inception (P571) for all sorts of creative works -- paintings, novels, buildings, photographs. Why not films ? Jheald (talk) 21:25, 16 September 2015 (UTC)

@Josh Baumgartner: You can label it "year of production". We have this information for most of the archived broadcast productions and we need a property where we can store it. Example: de:Portal:Hörfunk/Wikidata lists/Hörspiele. (The date of production is one of the basic infos in every catalog.) --Kolja21 (talk) 21:38, 14 September 2015 (UTC)

 Support but the description should make clear that this refers to the year/date that production was completed, as noted in archives etc. Joe Filceolaire (talk) 11:58, 19 September 2015 (UTC)

 Oppose in preference to using significant event (P793) along with start and end dates, as is done with ships (building = production) for example: HMS Ark Royal (Q1333909). Also note that there are various phases which a film goes through, not just production, such as casting, filming, production, post-production, etc. Danrok (talk) 01:32, 18 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

About 600 movie pages in the Japanese Wikipedia use the Japanese Movie Database using the Template:Jmdb title (Q14397015).ワーナー成増 (talk) 06:18, 11 October 2015 (UTC)

Discussion

•  Comment there is also Template:Jmdb name (Q6508413), so maybe this one should be called "JMDb film identifier". --- Jura 11:59, 12 October 2015 (UTC)
  •  CommentThank you. I have changed the name from JMDb identifier to JMDb film identifier.--ワーナー成増 (talk) 04:48, 13 October 2015 (UTC)
•  Support. Joe Filceolaire (talk) 09:49, 8 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

About 13,000 movie pages in the Japanese Wikipedia use the allcinema Movie Database using the Template:FilmLinks (Q18932457).ワーナー成増 (talk) 08:22, 12 October 2015 (UTC)

Discussion

•  Support. Joe Filceolaire (talk) 09:50, 8 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

About 10,000 movie pages in the Japanese Wikipedia use the KINENOTE Movie Database using the Template:FilmLinks (Q18932457).ワーナー成増 (talk) 15:12, 12 October 2015 (UTC)

Discussion

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

About 300 movie pages in the Japanese Wikipedia use the Movie Walker Database using the Template:FilmLinks (Q18932457).ワーナー成増 (talk) 06:11, 13 October 2015 (UTC)

Discussion

•  Comment I made items for Movie Walker (Q21093280), Japanese Cinema Database (Q21093526) and goo Eiga (Q21093430). --- Jura 16:51, 13 October 2015 (UTC)
  •  Comment I added properties and values to them a little bit.--ワーナー成増 (talk) 05:05, 23 October 2015 (UTC)
•  Support. --Marek Koudelka (talk) 17:06, 22 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Musical website from Ministry of Culture (Q1347047) --★ → Airon 90 16:31, 13 October 2015 (UTC)

Discussion

•  Support. Joe Filceolaire (talk) 09:52, 8 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Unique and persistent identifiers for these artworks. Corresponding URLs provide persistent links to 1) the description page of the artwork on the museum's own website and 2) its image, if available. Several thousands will be mass imported / added to Wikidata in November 2015 in the context of the project Flemish art collections, Wikidata and Linked Open Data -- Spinster (talk) 11:52, 19 October 2015 (UTC)

Discussion

•  Support. Joe Filceolaire (talk) 09:53, 8 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Complementary property to the proposed above. A simple software reverse feature won't be enough. I can't have examples ATM to present to you, but a given work can be created in reply to one or more works but a third reply can be created only in response to a portion of the works-tree. Example:

• A is replied on B
• C is replied on D
• E replies to B and D
• F replies to A→B→E without any mention to the C→D→E sequence
  

This complementary property can be delayed to get created only in the stage that the hypothetical F (not so hypothetical, I only don't remember any of this situation presently, but it certainly is somewhere else) appears on Wikidata. But to make consistency will be necessary to fill all previous records with this kind of data. Creating the property right now at the very same time than the other proposed property will prevent us of being crazy with this: we just start to store this in both directions/entries (maybe with some sort of bot help to check if both pages/entries have both directions of data; IF a is a response to b BUT b didn't says that is replied on a, bot adds b→a record on b page). Lugusto (talk) 18:37, 31 October 2015 (UTC)

Discussion

•  Support. Joe Filceolaire (talk) 09:59, 8 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

This is a key aspect of the setting of many creative works that doesn't appear to be representable currently. Thryduulf (talk: local | en.wp | en.wikt) 12:53, 4 November 2015 (UTC)

Discussion

•  Support. Joe Filceolaire (talk) 10:00, 8 November 2015 (UTC)
•  Support if clearly distinguished from movement (P135). Spinster (talk) 16:56, 8 November 2015 (UTC)
  •  Comment World War II (Q362) (in one of the examples, above) is not an instance of an era. Should there be a separate item for that? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:27, 22 November 2015 (UTC)
    • I don't object to seperate "set in period" and "set during event" properties, but I'm not sure the distinction between "era" and "event" is going to be meaningful in all contexts. For example while we could say Dad's Army (Q659575) → 1940s (Q36561) (as well) that's less precise and/or duplicative so I think I prefer just one, especially as if Wikidata:Property proposal/Unsorted#period is created, we can infer the period a work is set in from an event if the event has a period property. Thryduulf (talk: local | en.wp | en.wikt) 01:16, 23 November 2015 (UTC)

@Thryduulf, Filceolaire, Spinster:  Done set in period (P2408) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:05, 16 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

We have a property for episodes, so we should for seasons too. --AmaryllisGardener ^talk 02:00, 25 November 2015 (UTC)

Discussion

•  Support but it should be made clear in the description that this is for TV series, not sports series. Thryduulf (talk: local | en.wp | en.wikt) 11:16, 25 November 2015 (UTC)
  • Amended. --AmaryllisGardener ^talk 15:45, 25 November 2015 (UTC)
•  Comment Isn't this calculable, from "has part", "season 1", "season 2", etc? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:15, 25 November 2015 (UTC)
  • Answer In my opinion, that is too fragile and restrictive an approach. It is much more straightforward to reference a claim of a straight season count. Dancter (talk) 19:07, 27 November 2015 (UTC)
•  Support. Not every series is going to have an item for every season (long running radio programs on obscure local broadcasters for example) Joe Filceolaire (talk) 17:29, 26 November 2015 (UTC)
  • Do you have an example of such a programme? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:03, 27 November 2015 (UTC)
    • For example, Butterflies (Q5002904) -- the infobox on en:Butterflies_(TV_series) notes that there were four series, but we don't have items for each season. The same is probably true, I would have thought, for the great majority of series that aren't eg Star Trek. Jheald (talk) 16:09, 27 November 2015 (UTC)
      • "Don't have" is not the same as "won't have". There is no good reason why those series of Butterflies should not have items created. I was looking for an example of the claim of the later class ("long running radio programs on obscure local broadcasters"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:24, 27 November 2015 (UTC)
•  Neutral Why not just using
  ⟨ Happy Tree Friends (Q207627)    ⟩ has part(s) (P527) ⟨ television series season (Q3464665)    ⟩
  quantity (P1114) ⟨  5 ⟩
  ⟨ Happy Tree Friends (Q207627)    ⟩ has part(s) (P527) ⟨ episode (Q1983062)    ⟩
  quantity (P1114) ⟨  127 ⟩
  ? --Pasleim (talk) 13:13, 27 November 2015 (UTC)
  • We have a specific property for the latter - number of episodes (P1113) so the has part(s) (P527) construction is not required for that. I don't think it should be required for seasons either as it's one of the primary pieces of information about TV series. Thryduulf (talk: local | en.wp | en.wikt) 16:25, 27 November 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

We need a property for basic references that are not limited to a single information like "date of birth" etc. (See also Wikidata:Books task force.) --Kolja21 (talk) 19:09, 23 January 2014 (UTC)

Is it a "Biography-property" you are proposing? I would support that, but "Further reading" looks a little to unspecific. -- Lavallen (talk) 19:38, 23 January 2014 (UTC)

Imho we need this property for all subjects. (What would be the advantage of having a separate property only for persons = biographies?) Of cause the referred work should be "notable" in the meaning of presenting essential information about the item. --Kolja21 (talk) 20:41, 23 January 2014 (UTC)

How about "Book/article about subject" then? The problem with "Further reading" is that it may look like it invites to non-notable information or spam. I guess some projects have good guidelines about how the header "Further reading" should be used, but they are exceptions. -- Lavallen (talk) 11:59, 24 January 2014 (UTC)

"Book/article about subject" would be a good description. I've added it to the title. --Kolja21 (talk) 21:37, 24 January 2014 (UTC)

I would oppose this as the inverse of main subject (P921). --Izno (talk) 13:38, 24 January 2014 (UTC)

"Subject heading" is much broader. A book can have a dozen subject headings. "Further reading" (I try to use the same terminology as WP) should only contain the main works about an item. Take for example Boston University (section Further reading). It only contain 4 works but there can be hundreds of articles and books in WD with the subject heading "Boston University". --Kolja21 (talk) 21:48, 24 January 2014 (UTC)

 Comment Would statement is subject of (P805) work for the use case cited in the proposal? Emw (talk) 13:57, 24 January 2014 (UTC)

Good question. P805 is used in North Macedonia (Q221) and other items in a different way (not for literature). The German description "Datenobjekt über das Thema der Aussage" is hard to understand and needs further explanation. --Kolja21 (talk) 21:37, 24 January 2014 (UTC)

Let me understand: this would be a property for indicating the main works about a topic. It is thus different from the References or Bibliography on Wikipedia, right? Ths bothers me a bit, as, even so I understand the usefulness of such property, it would be very nnNOPV and it would not be decided in the Wikipedia page. I mean: the Wikipedia article is the place where there is the discussion and the creation of the article about the topic. They discuss and create the References section and the Bibliography section. Even that is extremely delicate, as you could really go nnPOV. But having a Further reading property just in Wikidata, disconnected by all the sections in Wikipedia, seems to much to me. Wikidata has a really small and dedicated community, we can't afford to decide by ourselves which is the "main" literature around a topic. If the Further reading was a conventional and common section in Wikipedia I would agree, but it seems to me it's not. --Aubrey (talk) 10:28, 26 January 2014 (UTC)

@Aubrey: We could add a note to WD:N or the talk page that only books or articles are allowed with this property that are used in the bibliography section of WP. This would minimize spam. --Kolja21 (talk) 05:54, 27 January 2014 (UTC)

On the other hand, Wikisource often have a "works about X" header in Author-namespace, so something like this is desired, no matter how Wikipedia is treating the matter. And then it does not matter how "main" the literature is or not. -- Lavallen (talk) 11:19, 26 January 2014 (UTC)

@Lavallen:, @Kolja21:: "works about X" is a good example, but it's kinda ambiguous. There are many books about X, sometimes, and not all of them should be staying in a "further reading" section. I generally like WD properties that are "facts", little pieces of information without POV issues. I agree that a simple metadata like "date of birth" or "nationality" is nnPOV sometimes, but they are often exceptions within a general rule. For example, in the Italian Wikisource we have 2 templates that are used when in a text an author/work is mentioned. See for example it:s:Storia_della_letteratura_italiana_(De_Sanctis)/I. I thus would like a "mentions" property for that, which could enumerate all the works and authors mentioned in a certain work. This is not "nnPOV", as it is the text which mentions them, and the community just puts manually the templates. This is the difference that makes me uncomfortable with the "Further reading" property proposal. Aubrey (talk) 10:19, 27 January 2014 (UTC)

I understand your worries, but intellectual work (looking at the content of a book) always involves the risk of POV issues. If you go to a library and ask for books about Oscar Wilde, you want an answer. If the librarian says: "I'm sorry, I have to be neutral but I can give you a a list of 50.000 books that mention this author", you can't work with this. --Kolja21 (talk) 15:41, 27 January 2014 (UTC)

In a first step stay with works which have an article in wikipedia or work used as reference in wikidata. This represents quite a large number of books. I think we have to fix some priorities. Snipre (talk) 13:04, 28 January 2014 (UTC)

This is understandable, but it remains unsatisfactory that, looking at the example Oscar Wilde (Q30875), an article of The Guardian (enWP, Citations 88) might be notable but main works about the author that are part of WP (listed under "References" and "Further reading") are ignored by WD. (See also: Book templates like de:Vorlage:BibISBN, used in 6 languages. Imho this bibliographic data should be transfered to WD.) --Kolja21 (talk) 14:49, 28 January 2014 (UTC)

 Support More books in Wikidata. --Recherchedienst (talk) 08:02, 3 April 2014 (UTC)

On hold Lavallen, Kolja21, Izno, Emw, Aubrey, Snipre: since our aim is mostly to collect information about the world and support other Wikimedia projects, this property qualify for creation as long as it is wished and can be used by Wikipedias to store here their "further reading" preferences. However since WD isn't ready for technical reasons to deliver this info, I'm setting this proposal as "pending", to be created when Bugzilla: 47930 is finished.--Micru (talk) 16:55, 30 April 2014 (UTC)

Kolja21: Do we really need this? --Succu (talk) 20:05, 27 November 2015 (UTC)

Imho yes. "Further reading" (= bibliography) would be great for private or public lists about a person or a subject. (Example: en:Cèmuhî language#Bibliography.) statement is subject of (P805) is marked as "qualifier only". We use notable work (P800) although we have author (P50). "Further reading" would be the conterpart of main subject (P921) but it's not a 1:1 inverse property. - I left a note on Wikidata talk:WikiProject Books#Further reading. Hopefully this will bring more comments. --Kolja21 (talk) 21:25, 27 November 2015 (UTC)

Further reading, Kolja21? Something like de:George Engelmann/Schriften or de:Ernest Rutherford/Schriften? --Succu (talk) 21:43, 27 November 2015 (UTC)

No, for these lists we have notable work (P800) (deWP: Schriften / "Further reading" = Sekundärliteratur). --Kolja21 (talk) 22:00, 27 November 2015 (UTC)

 Question Is that valid? The documentation does not indicate that list items are acceptable values for notable work (P800). That sort of substitution strikes me as something that would complicate things. Dancter (talk) 22:30, 27 November 2015 (UTC)

Sure, Kolja21 … Both never published something… --Succu (talk) 22:37, 27 November 2015 (UTC)

This is a misunderstanding. notable work (P800) is not meant for list items: you can use this property for creating Wikidata lists. For a Wikimedia list of works use list of works (P1455). --Kolja21 (talk) 00:36, 28 November 2015 (UTC)

I think described by source (P1343) does this job. Joe Filceolaire (talk) 16:54, 22 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Useful info. --AmaryllisGardener ^talk 19:32, 30 November 2015 (UTC)

Discussion

•  Comment This seems to be the inverse of based on (P144). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:20, 5 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Jamendo (Q1132897) is a famous repository of open music. ★ → Airon 90 18:35, 3 December 2015 (UTC)

Discussion

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Jamendo (Q1132897) is a famous repository of open music. ★ → Airon 90 18:35, 3 December 2015 (UTC)

Discussion

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Explanation

• As duration (P2047) is being used for almost anything, this proposal to create a separate property for runtime of films/songs, etc. --- Jura 10:57, 5 December 2015 (UTC)

Discussion

•  Support --- Jura 10:57, 5 December 2015 (UTC)
  • As noted more than once previously, as the opponent you don't need to support your own proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:18, 5 December 2015 (UTC)
    • Can you provide a reference for this affirmation? I don't think you had provided a reference for your affirmation last either. As usual. --- Jura 13:53, 5 December 2015 (UTC)
      • @Jura1: Obviously you support your own proposal. You would not propose something you don't agree with. So I don't think we should write a statement against self-support because it is implicit in the proposal itself. --★ → Airon 90 15:46, 6 December 2015 (UTC)
        • Sometimes I merely formulate proposals for other people. Some of them I support as well. I noticed others doing the same. We do have a statement requiring people to check existing property before making proposal, but it seems people don't read that either. What do you think? --- Jura 15:57, 6 December 2015 (UTC)
•  Oppose. duration (P2047) is sufficient. I also note that the edit filter suggested does not match the examples and that the datatype is not listed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:18, 5 December 2015 (UTC)
  • Added datatype (somehow this wasn't available in previous proposal). Sample is from Property talk:P2047. Obviously, this can be improved once created. --- Jura 13:53, 5 December 2015 (UTC)
  • On further examination, this seems to be an attempt to avoid the consensus at property talk:p2047, which is running against Jura1's preference. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 6 December 2015 (UTC)
•  Oppose I don't get why you should separate this property from duration (P2047). --★ → Airon 90 15:28, 6 December 2015 (UTC)
  • Just to clarify: In English, your statement would display "Oppose I don't get why you should separate this property from running time (P2047)", but as P2047 gets changed, it should read "from duration (P2047)". --- Jura 16:00, 6 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

import données de plwiki --- Jura 13:17, 13 December 2015 (UTC)

Discussion

•  Support --- Jura 13:17, 13 December 2015 (UTC)
  • And again: you do not need to support your own nominations. Also, please provide label and description in English; and a valid example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:56, 16 December 2015 (UTC)
    • Please avoid repeating the same stuff without providing valid references. Furthur, please clarify if your editorial contributions here are endorsed by the Royal Society of Chemistry, sponsered by the Royal Society of Chemistry and/or supported by the Royal Society of Chemistry. --- Jura 01:31, 17 December 2015 (UTC)
•  Oppose. Use significant event (P793). --Yair rand (talk) 21:59, 13 December 2015 (UTC)
  • P793 is useful to list different steps of the films making, but not the date of publication. In some cases, the date of publication isn't available, but the date year of production provided. I'm not entirely sure when: Yair rand, as you have a clear view on this, can clarify when this is the case? --- Jura 01:32, 17 December 2015 (UTC)
•  Oppose per Yair Rand; and as an incomplete proposal. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:56, 16 December 2015 (UTC)
•  Support This property has been already been proposed September 2015 as "production date" and is urgently needed (see above). significant event (P793) works for items like ships, but films and broadcasting productions are quite different. This property would be easy to use and can be filled by bots. We need this property for films like we need date of birth (P569) for humans. --Kolja21 (talk) 14:17, 18 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Knowing in which meter a poem is written is a useful information! Epìdosis 21:09, 13 December 2015 (UTC)

Discussion

•  Comment I don't know whether this is adequately treated in other properties, but let me float the idea of thinking about a poem's versification along 2 axes -- literally -- horizontal and vertical. Horizontal being (if I read you correctly) what you're talking about here: meter. Vertical being (usually) rhyme scheme. As an example, the horizontal verse form of a Shakespearean sonnet is "iambic pentameter" ... the vertical verse form is "ABAB CDCD EFEF GG". Why not just have 1 property that says "Shakespearean sonnet"? Because too many poems will not have such a convenient label, but can still be easily described along these 2 axes. Even "Petrarchan sonnet" fails to describe specifically what the rhyme scheme of the sestet is. This 2-axis system may also help discourage editors from saying e.g. "meter=sonnet" (a sonnet is not a meter).
  A counter-example might be in lyrics with complex versification, where it might make more sense to think of a stanza as (say) an integrated "A3 B2 B3 A4 C4 D5 C2 D4" rather than horizontal = "3.2.3.4.4.5.2.4" + vertical = "ABBACDCD". (Here, my numerals might mean "feet" or "stresses"; others count syllables -- this would all have to be worked out.)
  But a counter-counter to this might be the ease with which it can be seen that (A) horizontal = "XAXA" + vertical = 4.3.4.3" and (B) horizontal = "ABAB" + vertical = 4.3.4.3" can be sung to the same tune (exactly the same meter), even though their rhyme schemes differ.
  Finally, I would hesitate to call the vertical property "rhyme scheme", even though this would usually be correct. This is because, for example, sestinas and elegiac couplets have vertical structure, but not rhymes; on the other end, "unrhymed" or "blank" (which would necessarily be legitimate values) are not strictly rhyme schemes. Food for thought. Phil wink (talk) 07:23, 28 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

Metrical pattern of a feet or a verse is a standard information which might be included in a database. Epìdosis 19:05, 14 December 2015 (UTC)

Discussion

•  Comment I think this property in insteresting and worthwhile to consider. I suppose that the indication of the metric can be in various ways. In the Danish Wikipedia I have seen the notation "9.9.9.9" for Den yndigste rose er funden (Q21065160), see da:Den yndigste rose er funden. This notation misses the stresses. Is the suggestion for "allowed values" a standard way of defining metric? The vertical bar usually indicates bars in musical notation. — Finn Årup Nielsen (fnielsen) (talk) 12:58, 26 December 2015 (UTC)

@Fnielsen: I intended "|" for caesura (Q247417). About the notation of da.wiki: probably that is not based on quantitative metrics (Q3855709), which was the one I considered ... possibly we could create two properties, one for quantitative metrics and one for accentuate metrics. --Epìdosis 13:25, 26 December 2015 (UTC)

•  Comment Just to be explicit, I'd call this "quantitative metrical pattern" which, if I'm reading you correctly, is the limited topic you're addressing here. I fear "metrical pattern" will elicit doomed attempts to describe stress, syllable-stress, tonal, and even free verse using your symbols for short, long, anceps, and caesura! Whereas (hopefully) "quantitative metrical pattern" will tell some editors that this property just isn't germane for these types of verse. Other notes (that I'm not an expert on): Do you intend that this property should indicate (A) the underlying meter of a work (or even a line), e.g. "this is written in dactylic hexameter" -- or (B) the rhythmic character of an individual realized line? (I suspect 1 property should not be used for both.) For example, if (A), then the whole Aeneid would have 1 value for this property -- but it would need to include additional symbols (e.g. ∪ ∪ with a single macron over them -- don't know how you'd actually do that). Also if (A) would it be appropriate to have distinct symbols for "anceps" and "brevis in longo"? for required, preferred, allowed, and forbidden caesurae? Whereas if (B) each line would have its own value, 1 of dozens possible, but each position would be certainly defined (e.g. a final syllable would be well and truly either a long or short, despite it occupying a "brevis in longo" position). Finally, my sense is that, even though this appears to be optimized for Greek/Latin verse, this system, once worked out, would probably succeed with other quantitative prosodies, e.g. Sanskrit, Persian, Arabic. Cheers. Phil wink (talk) 06:28, 28 December 2015 (UTC)

@Phil wink: OK for "quantitative metrical pattern". Then, I meant (A), the underlying meter of a work. About additional symbols I found an useful catalogue here. For caesurae, do you have any suggestions? --Epìdosis 18:20, 29 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

In case of NMHH film rating (P2363), this certificate number is featured on movie posters and home media covers along with the rating itself, and would help finding the film's record in the .xlsx given as source on the property page. MPA film rating (P1657) has a similar number which is listed on filmratings.com and IMDb. Most content rating systems have a similar reference certificate number. Máté (talk) 06:56, 15 December 2015 (UTC)

Discussion

•  Comment Should be, say, "rating certificate ID", as the examples include letters. Also, perhaps we need a separate property for each issuing body, so that we can use formatter URLs? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:02, 15 December 2015 (UTC)

  MPAA calls its own ID "certificate #" that is why I chose the name, but I'm happy either way. (NMHH also calls its own "nyilvántartási szám [registry number]" but it's like production and serial numbers, those also contain letters, don't they?) As for the formatter URLs—it may be a good idea to have separate ones, if there really are content rating bodies where you can access the decisions by an URL containing the certificate number, but in the case of these two specific examples, it is not so (in case of NMHH it makes it easier to find the decision in the spreadsheet, but you can't link to it). The main use is being able to differentiate among multiple ratings for the same item (when it's revised, or when there are several cuts/releases).

  For FSK film rating (P1981)'s Prüfnummer it may work though, but we'd also need the yymm:

  ⟨ The Man from U.N.C.L.E. (Q14488725)    ⟩ FSK film rating (P1981) ⟨ FSK 12 (Q20644796)    ⟩

  → 153302/K and 153302/V.

  Máté (talk) 19:56, 15 December 2015 (UTC)

  @Pigsonthewing: So, what say you? I changed the name, but on this limited sample (these are all the film rating properties we have right now) it doesn't seem to be useful to split it to multiply qualifiers since URL formatting is not an option, even for FSK it could only be computed from this qualifier and point in time (P585) (which could be added as another compulsory qualifier to these properties, btw). – Máté (talk) 21:30, 30 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

At the moment, the Crotos tool can show paintings that include depictions of particular things, noted by the P180 statement -- eg here are some paintings with items that include depicts (P180) = house cat (Q146) : Crotos.

With this property, a similar tool would be able to show just the cats, or just the clocks, or just the examples of whatever particular detail we were interested in, rather than the whole image.

Some examples:

• Idleness (Q19953492) : image (P18) = File:Godward_Idleness_1900.jpg
  • depicts (P180) = house cat (Q146) : qualifier → "pct:65,81,35,15"

    → https://tools.wmflabs.org/zoomviewer/proxy.php?iiif=Godward_Idleness_1900.jpg/pct:65,81,35,15/,240/0/default.jpg

• The Fruit and Vegetable Costermonger (Q19274279) : image (P18) = File:Moillon, Louise - The Fruit and Vegetable Costermonger - 1631.jpg
  • depicts (P180) = house cat (Q146) : qualifier → "pct:83.5,54,20,12"

    → https://tools.wmflabs.org/zoomviewer/proxy.php?iiif=Moillon,_Louise_-_The_Fruit_and_Vegetable_Costermonger_-_1631.jpg/pct:83.5,54,20,12/,240/0/default.jpg

• Still Life of Fish and Cat (Q19318318) : image (P18) = File:Clara Peeters - Still life with fish and cat.jpg
  • depicts (P180) = house cat (Q146) : qualifier → "pct:57,39,45,53"

    → https://tools.wmflabs.org/zoomviewer/proxy.php?iiif=Clara_Peeters_-_Still_life_with_fish_and_cat.jpg/pct:57,39,45,53/,240/0/default.jpg

• Entry into Noah's Ark (Q18809786) : image (P18) = File:Jan van Kessel (I) 005.jpg
  • depicts (P180) = house cat (Q146) : qualifier → "pct:26.5,33,6,7"

    → https://tools.wmflabs.org/zoomviewer/proxy.php?iiif=Jan_van_Kessel_(I)_005.jpg/pct:26.5,33,6,7/,240/0/default.jpg

More details about the IIIF syntax used in the URLs (an international open standard being developed primarily by libraries around the world) can be found at http://iiif.io/api/image/2.0/

The proposed syntax for the property is intended to be identical to the {region} part of the IIIF URL, so pct:x,y,w,h specifies x-offset (from left), y-offset (down from top), width w, and height h of the crop region (as a percentage of the whole image).

The percentage format is particularly useful here, as it makes the property independent of the actual image file used: if the image is later replaced by a different photograph that is a different size, the percentages should be unchanged, so long as both images only show the painted area of the painting (ie not the frame). This should also make the property re-usable, including by users who may have different preferred images of the same painting.

It could be quite a treasure hunt to find all the details we have recorded for all the paintings we have items for -- but it makes the P180 statements much more precise and valuable, if we can indicate exactly what is the specific part of the canvas that we are identifing as item Qnnnn. Jheald (talk) 23:51, 15 December 2015 (UTC)

Discussion

•  Support in principle, but why do we need to store the "pct:" prefix? Also, would there be any advantage in holding four, separate, numerical values? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:53, 16 December 2015 (UTC)
  • I think "pct:" is useful, because when people read the wikidata item page it makes the numbers more self-explanatory, underlying that they are proportional to the overall size, and that they are percentages out of 100 -- neither of which would necessarily be so obvious without the "pct:". Note also that, in the IIIF standard, if "pct:" is omitted in the {region} part of the URL then the values are interpreted as pixel counts -- something that we would wish to avoid, as it would tie us too closely to one specific scan on Commons, rather than a general statement about the painting as a whole. I think that including the "pct:" helps make more explicit the choice we would making. It doesn't seem to me that we're so hard up for storage space that we should worry too much about four extra characters.
    As to the second point, I think that because what the property is describing is something that makes sense as a distinctive thing in its own right, namely a region of a larger painting, it makes sense to keep the full specification of that region together as a single value of a single qualifier, rather than breaking it apart across multiple different statements. (It also means that if e.g. a canvas contains images of two cats, the positions of these can then be given with two simple region statements, rather than having to untangle which of 8 different co-ordinate statements belonged to which cat). Most of the time, the all-in-one string format will actually be an advantage, because it can be slotted straight into a IIIF URL. There may be some analyses where one might want the individual numbers -- eg if one wanted to filter to only extract details that take up more than 15% of the painted area. This could be done in SPARQL (though it might be a little slow), using the STRBEFORE and STRAFTER string operators to successively extract the parts of the string before and after each comma. Jheald (talk) 16:09, 16 December 2015 (UTC)
    • I don't think there's any precedent for including definitions for humans, ("pct" as "percent") in values, nor do I think it would be wise to introduce one. As for pixels vs percent, that can be covered adequately in the property definition (and formatter URL if any). I do find you argument on my second point convincing. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:32, 16 December 2015 (UTC)
•  Support the principle also - could be useful also for P18 on Q5, when the image is a group portrait (or 2-5 people) to indicate which one is the item ;) — don't see the need for pct: indication either --Hsarrazin (talk) 11:42, 28 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Discussion

TV.com is a huge database comparable to IMDb which is used extensively in several Wikipedias as a source and for external links, so have properties for it in Wikidata would make linking more efficient.

How many properties we should have is up for discussion. As you can see, the ones I've proposed for show, episode and seasons all use the same formatter URL, so they could quite easily be merged into one property. And if we want just one property, we could do that by including the "show"/"movie"/etc part of the URL (so the allowed values would be something like (show|movies|people)/[a-z\d\-/]+), but I personally don't favour that idea as it might get a bit messy. But input would be appreciated. Jon Harald Søby (talk) 11:25, 18 December 2015 (UTC)

•  Comment regarding the issue of how many properties we need, I think Rotten Tomatoes ID (P1258) is very similar and it works quite well. - Máté (talk) 17:27, 18 December 2015 (UTC)

Documentation

[create Create a translatable help page (preferably in English) for this property to be included here]

Motivation

winner (P1346) is often used as qualifier for award received (P166). See for example this query: Query: claim[166:106301 and claim[31:(tree[11424][][279])]]. We need a counterpart qualifier to winner (P1346) for nominated for (P1411). For the moment I'm using criterion used (P1013) (a proposal of User:Jura1), see this query Query: claim[1411:106301 and claim[31:(tree[11424][][279])]]. But as User:Andreasmperu pointed out this property doesn't fit well. We need a new one. Once we have this new property I'd change the wrong use of criterion used (P1013). Since this is my first property proposal feel free to correct or enhance the table above. --Jobu0101 (talk) 08:23, 28 December 2015 (UTC)

Discussion

•  Support As I pointed out in my motivation I'd love to have this new property to make "nominated for" statements more explicit. --Jobu0101 (talk) 08:26, 28 December 2015 (UTC)
•  Support Either this proposal should be implemented or winner (P1346) should be expanded to be also for nominees. Mbch331 (talk) 09:12, 28 December 2015 (UTC)
•  Comment Maybe we can use more generic "to": Ex. nominated for (P1411) Academy Award for Best Supporting Actress (Q106301) "to" Uma Thurman (Q125017) and winner (P1346) Academy Award for Best Supporting Actress (Q106301) "to" Uma Thurman (Q125017) --User:ValterVB

 Support I'm fine with that solution, too. Actually, I think it is reasonable to use one property for both cases. But I wouldn't rename winner (P1346) (what User:Mbch331 proposed) because that property is not only used as quantifier. I think the correct way is User:ValterVB's solution to introduce a new qualifier only property to. --Jobu0101 (talk) 09:52, 28 December 2015 (UTC)