Wikidata:Property proposal/has part (string value)

has part (monolingual text)

Originally proposed at Wikidata:Property proposal/Creative work

   Not done

Description	monolingual text value for the title of a part of a work that doesn't have its own item
Data type	Monolingual text
Domain	creative work (Q17537576)
Allowed values	text
Example 1	Symphony No. 5 (Q188709) has part (monolingual text) Allegro con brio series ordinal (P1545) 1
Example 2	Symphony No. 5 (Q188709) has part (monolingual text) Andante con moto series ordinal (P1545) 2
Example 3	Symphony No. 5 (Q188709) has part (monolingual text) Scherzo. Allegro series ordinal (P1545) 3
Example 4	Symphony No. 5 (Q188709) has part (monolingual text) Allegro series ordinal (P1545) 4
Example 5	Three Places in New England (Q3022405) has part (monolingual text) The "St. Gaudens" in Boston Common (Col. Shaw and his Colored Regiment) series ordinal (P1545) 1
Example 6	Three Places in New England (Q3022405) has part (monolingual text) Putnam’s Camp, Redding, Connecticut series ordinal (P1545) 2
Example 7	Three Places in New England (Q3022405) has part (monolingual text) The Housatonic at Stockbridge series ordinal (P1545) 3
Example 8	Tacoma Stories (Q104593306) has part (monolingual text) Your Life Should Have Meaning on the Day You Die series ordinal (P1545) 1
Example 9	Tacoma Stories (Q104593306) has part (monolingual text) A Goat's Breath Carol series ordinal (P1545) 2
Example 10	Tacoma Stories (Q104593306) has part (monolingual text) Home Delivery series ordinal (P1545) 3
Example 11	Tacoma Stories (Q104593306) has part (monolingual text) The Man Who Looks at the Floor series ordinal (P1545) 4
Example 12	Tacoma Stories (Q104593306) has part (monolingual text) The Day of the Reckoning of Names series ordinal (P1545) 5
Example 13	Tacoma Stories (Q104593306) has part (monolingual text) The Dangerous Gift of Beauty series ordinal (P1545) 6
Example 14	Tacoma Stories (Q104593306) has part (monolingual text) Let's Meet Saturday and Have a Picnic series ordinal (P1545) 7
Example 15	Tacoma Stories (Q104593306) has part (monolingual text) Anyone Can Master Grief But He Who Has It series ordinal (P1545) 8
Example 16	Tacoma Stories (Q104593306) has part (monolingual text) The Dancing Cobra series ordinal (P1545) 9
Example 17	Tacoma Stories (Q104593306) has part (monolingual text) The Woman series ordinal (P1545) 10
Example 18	Tacoma Stories (Q104593306) has part (monolingual text) eHarmony Date @ Chez Panisse series ordinal (P1545) 11
Example 19	Tacoma Stories (Q104593306) has part (monolingual text) The Strange Detective series ordinal (P1545) 12
Example 20	Tacoma Stories (Q104593306) has part (monolingual text) Sarco-gophus series ordinal (P1545) 13
Example 21	Tacoma Stories (Q104593306) has part (monolingual text) Out for a Drink series ordinal (P1545) 14
Planned use	Will edit items for musical works as needed
Expected completeness	always incomplete (Q21873886)
See also	has part(s) (P527): part of this subject; inverse property of "part of" (P361). See also "has parts of the class" (P2670). has part(s) of the class (P2670): the subject has one or more parts of the object class

Motivation

There is no way in Wikidata to list the movements or parts of a musical or other work without creating separate items for each part. While that may be useful for some works, it is laborious, and of dubious value for many works. For many works, just being able to list the parts as text strings would be sufficient. UWashPrincipalCataloger (talk) 00:48, 31 December 2020 (UTC)

Discussion

•  Oppose as a generic has part(s) (P527) as in most cases such a link warrants a new item, but a  Conditional support, when the label would be movement/work consists of or something similar. --CamelCaseNick (talk) 04:47, 31 December 2020 (UTC)

  I do not think this should be limited to musical works, which is why it was proposed as "has part". The property would be equally applicable to tables of contents of books, for example, where separate Q items were deemed unnecessary for chapter titles or the individual works in a compilation. In the cataloging code RDA used widely around the world, chapters and movements are both considered parts of a work, so that is the terminology I proposed. UWashPrincipalCataloger (talk) 16:53, 31 December 2020 (UTC)

  @UWashPrincipalCataloger: Me neither, but you know that has part(s) (P527) is not limited to creative works? I oppose the use of this property outside of art. Therefore, I suggest a different label. --CamelCaseNick (talk) 17:42, 31 December 2020 (UTC)

  I'm not wedded to the proposed property label if there's another one that is just as good or better. I want the property, the label can be whatever is best. I don't think it should be limited to musical works though, so I don't support "movement title" or something like that. Perhaps "consists of parts" or "part of work" or "has work part" or something along those likes? UWashPrincipalCataloger (talk) 04:39, 2 January 2021 (UTC)

•  Support Strongly, as this is a major issue for musical works whose individual parts may or (especially) may not warrant a separate item. There are thousands of symphonies, many of which contain movement which have no title but are indicated by their tempo marking, "Allegro." It is impractical to have hundreds of items with the same label. For those works that contained named parts, it's important to be able to search/find those parts even if they are not items. This applies especially to cyclical works, for example Q765966 which is comprised of 24 separate songs - but the current item has no way to contain/concatenate the individual parts. - Kosboot (talk) 11:57, 31 December 2020 (UTC)

• • @kosboot: «this is a major issue for musical works whose individual parts may or (especially) may not warrant a separate item» Why? Should all parts of a musical work have an item per #3 of WD:N? --★ → Airon 90 15:26, 31 December 2020 (UTC)

If the work is notable, then its parts are worth noting. I'm unable to think of any exceptions. - Kosboot (talk) 15:40, 31 December 2020 (UTC)

@Kosboot: I don’t follow. If the parts are worth noting (I agree!), do they not warrant separate items, per notability criterion 3 (structural need) as Airon90 said? --Lucas Werkmeister (talk) 17:44, 31 December 2020 (UTC)

•  Support As much as I favor creating QItems for notable parts, I recognize that's not always practical/feasible. This property, whatever label it ends up with, could help with that. Moebeus (talk) 12:37, 31 December 2020 (UTC)

WikiProject Music has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. - Kosboot (talk) 14:41, 31 December 2020 (UTC)

•  Comment I think has part(s) of the class (P2670) is better suited for this than has part(s) (P527) (or this proposal) when no item is available.--- Jura 15:35, 31 December 2020 (UTC)
  • The object of has part(s) of the class (P2670) must be a Q item, so that does not succeed in fulfilling the need for a string-only property. UWashPrincipalCataloger (talk) 18:26, 31 December 2020 (UTC)
    • The title can be added as a qualifier. Obviously, if you don't know what type the parts are, you can't do that. OTH, if even the type is unknown, we probably don't want the data either, as it would be unstructured free text. --- Jura 18:18, 31 December 2020 (UTC)

•  Weak oppose I think creating items for the parts is cleaner. For parts of musical works, I would expect most parts to have, at least, tempo marking (P1558), tonality (P826), and MusicBrainz work ID (P435) – should I therefore expect this new property to always have at least three qualifiers (when used on musical works)? --Lucas Werkmeister (talk) 16:48, 31 December 2020 (UTC)

•  Strong oppose, more specifically, for the proposed data type “string” – almost all of the 21(!) given examples look like “monolingual text” would be better. --Lucas Werkmeister (talk) 16:48, 31 December 2020 (UTC)
  • Happy to change the data type to “monolingual text” if that is the consensus. UWashPrincipalCataloger (talk) 16:55, 31 December 2020 (UTC)
    • Alright :) --Lucas Werkmeister (talk) 10:46, 1 January 2021 (UTC)

•  Support, Just need to change datatype to monolingual text, and the proposal is going to be good.--CrystallineLeMonde (talk) 20:56, 31 December 2020 (UTC)

I've changed the property name, description, and datatype to monolingual text. UWashPrincipalCataloger (talk) 23:55, 31 December 2020 (UTC)

•  Oppose per the opposition provided on Wikidata:Property_proposal/cites_work_string and Wikidata:Property_proposal/candidate_name_string, suggesting the alternative of using "unknown value" with qualifier object named as (P1932) if you must indicate the name of a part with a string. @Tinker Bell, Yair rand, Pasleim, Jeb, Rdmpage, Jheald: from the aforementioned failed proposals. Mahir256 (talk) 00:18, 1 January 2021 (UTC)
•  Oppose per Mahir256. --Tinker Bell ★ ♥ 02:45, 1 January 2021 (UTC)
•  Comment I agree as the preceding comments note that "unknown value" with a qualifier is the standard way to handle this in Wikidata right now ("author name string" is "the exception that proves the rule" I think). However, object named as (P1932) is string value, so if monolingual string is needed perhaps title (P1476) is the right qualifier? Or something else? ArthurPSmith (talk) 19:19, 1 January 2021 (UTC)
•  Comment I’ve created three demo items on Test Wikidata to show the different approaches being discussed here (as I perceive them), using Symphony No. 5 (Q188709) as the example: Q213974 uses a new property as proposed here; Q213975 uses has part(s) (P527) with unknown value Help, as suggested by Mahir256 (edit: though I used title (P1476) instead of object named as (P1932)); and Q213976 uses has part(s) (P527) with dedicated items. --Lucas Werkmeister (talk) 09:02, 2 January 2021 (UTC)

Thanks Lucas. There's no doubt that option Q213976 is the most ideal. But seeing just how few actual musical works this has been done for is a good indication that it is very laborious and of dubious value in many cases. Am I the only one who thinks that Q213975 is unnecessarily complicated and also strange looking? If it isn't possible or simply too much work for too little gain to create separate items for each part, then it seems to me that Q213974 is the simpler and more straightforward way to record the parts of a work. The vast majority of editors are more likely to understand this method than Q213975. UWashPrincipalCataloger (talk) 22:48, 2 January 2021 (UTC)

•  Comment see Q7373836#P2670 for a sample with has part(s) of the class (P2670). An attempt with has part(s) (P527) at Q1256992#P527 somehow suggests something is missing: the type of feature or the items for each. --- Jura 18:04, 3 January 2021 (UTC)

•  Strong oppose as all examples in the proposal worth an item. No need to create a property for (monolingual) string --★ → Airon 90 22:33, 3 January 2021 (UTC)
•  Oppose per Mahir256 --Premeditated (talk) 13:54, 4 January 2021 (UTC)
•  Oppose @UWashPrincipalCataloger: Adam, While I appreciate that your motivation mentions "laborious". That is indeed where the value is provided with Wikidata's knowledge graph and relations that can be made or had. I have always preferred "Things not Strings", and can imagine some fun and useful value (not dubious) derived from such queries that could look at "parts of a work" and filter them based an lots of criteria per interesting domain. Listing things for human consumption is admirable, but those listings can be created by querying for facts ("parts of a work as items") and then exposed in richer UI's like Reasonator, Listeria, etc. For instance, it would be really cool to query how many Story collections have chapters, sections, parts with the text "Detective". But beyond that, there's the basics of "There's a lot to say about any Part of any Thing, just ask a child to ask the questions". Example: "Tacoma Stories, The Strange Detective": narrative location (P840) = Point Defiance Park (Q7208006) and I could go on and on and on about just that part "The Strange Detective". Do the labor, and create items. Thanks. (And what you and others probably need is really better tools and UI's to drastically reduce the labor here throughout Wikidata. Lucas could probably make some cool ones if given the time) -- Thadguidry (talk) 17:59, 4 January 2021 (UTC)
•  Not done, no consensus to create --DannyS712 (talk) 18:06, 17 February 2021 (UTC)