Property talk:P1433
Documentation
larger work that a given work was published in, like a book, journal or music album
| Represents | publishing (Q3972943) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Data type | Item | ||||||||||||
| Domain | work (Q386724) or author (Q482980) | ||||||||||||
| Example | To a Creole Lady (Q3576923) → Les Fleurs du mal (Q216578) L’Aérostation pendant le siège de Paris (Q15715588) → Revue des Deux Mondes (Q1569226) Sette piani (Q3478941) → The Seven Messengers (Q2375534) | ||||||||||||
| Commons example |
| ||||||||||||
| Tracking: usage | Category:Pages using Wikidata property P1433 (Q20990017) | ||||||||||||
| See also | part of (P361), title of broader work (P6333), place of publication (P291), collection (P195) | ||||||||||||
| Lists | |||||||||||||
| Proposal discussion | Proposal discussion | ||||||||||||
| Current uses |
|
List of violations of this constraint: Database reports/Constraint violations/P1433#Type Q386724, Q482980, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1433#Value type Q386724, Q17489659, Q17084016, Q19824398, Q192283, Q4801521, Q1713, Q2001305, Q107655869, Q6881511, Q1331793, Q35127, Q3331189, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1433#Conflicts with P31, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1433#allowed qualifiers, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1433#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1433#Entity types
Replacement property:
Replacement values: (Help)
List of violations of this constraint: Database reports/Constraint violations/P1433#none of, SPARQL
Replacement property:
Replacement values: (Help)
List of violations of this constraint: Database reports/Constraint violations/P1433#none of, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P1433#Conflicts with P31, SPARQL
Replacement property: content deliverer (P3274)
Replacement values: (Help)
List of violations of this constraint: Database reports/Constraint violations/P1433#none of, SPARQL
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Constraints[edit]
Discussion[edit]
Usage note[edit]
Till July 2014 the more general term part of (P361) was in use. See also: Help:Sources. --Kolja21 (talk) 09:58, 27 July 2014 (UTC)
Gegenpart / inverse part[edit]
@VIGNERON: Wie lautet der Gegenpart (contraste?) zu dieser Eigenschaft? Beispiel:
- Nouveau: Nevsky Prospekt (Q448977) published in (P1433): Petersburg Tales (Q289387)
- Vieux:
Nevsky Prospekt (Q448977) part of (P361): Petersburg Tales (Q289387) - Nouveau: ...
- Vieux: Petersburg Tales (Q289387) has part(s) (P527): Nevsky Prospekt (Q448977)
--Recherchedienst (talk) 15:18, 1 August 2014 (UTC)
- Same question, see Wikidata talk:WikiProject Books/2014#Need for inverse of Property:P1433. --Kolja21 (talk) 12:01, 6 August 2014 (UTC)
- @Recherchedienst, Kolja21: Oo, sorry I missed this discussion. Yeah we definitely need a inverse property. Cdlt, VIGNERON (talk) 12:06, 21 May 2016 (UTC)
multi-part article[edit]
There is a question at Wikidata:Forum (German-equivalent to WD:PC) how to add an article which consists of multiple parts. An example item would be Daseinskampf und gegenseitige Hilfe in der Entwicklung (Q19154093). At the moment the qualifier series ordinal (P1545) is used to indicate the parts, but it is not allowed according to the constraints on this page. Any ideas, or experience? —MisterSynergy (talk) 17:27, 19 October 2016 (UTC)
- The message on WD:PC contains more information so I'll copy/paste it here :
author TomT0m / talk page 08:10, 21 October 2016 (UTC)At Wikidata:Forum (German equivalent of WD:PC) a question came up how to use published in (P1433) in an item about a scientific article which was published in two parts (both parts appeared in the same journal, same volume, but subsequent issues). The item in question is Daseinskampf und gegenseitige Hilfe in der Entwicklung (Q19154093). Please give input at Property talk:P1433#multi-part article to make this information permanently available for P1433 users. Thanks! —MisterSynergy (talk) 06:01, 21 October 2016 (UTC)
@MisterSynergy: This looks like some edition/work problem. There is also a whole/part problem : the article has been published in two parts. Here is a proposition Daseinskampf und gegenseitige Hilfe in der Entwicklung (Q19154093) is the work item. There could also be an edition item first edition of Daseinskampf und gegenseitige. This item has two parts and/or is a series of article => then you get the "ordering" notion as a series is ordered. In the end, after analysis, this should be managed the same way any series of publications that makes a whole work are handled. Each of the subarticles are then published in the corresponding scientific journal issue. author TomT0m / talk page 08:20, 21 October 2016 (UTC)
- Thanks for your reply! However, I don’t fully understand it
… Some questions:
- Did you suggest to add two additional (“part”) items for the two parts, which are connected to Daseinskampf und gegenseitige Hilfe in der Entwicklung (Q19154093) with part of (P361)/has part(s) (P527) and which then take the published in (P1433) claims?
- I don’t see the edition problem. Scientific articles typically do not have editions (they are published once, but don’t receive “updates” via editions). I don’t think there well ever be a second edition of this article available.
- “this should be managed the same way any series of publications that makes a whole work are handled” — is there an example or description available? I was not able to find one.
- Regards! —MisterSynergy (talk) 08:30, 21 October 2016 (UTC)
- first point: Yep something like that. A (maybe not required) refinement (see point 2) would be to create another item for the first and only edition here, which takes the has part claims. author TomT0m / talk page 10:05, 21 October 2016 (UTC)
- second one: edition problem : this not always the case. First there is naturally a lot of versions of the paper, not all of them are published, but some are : preprints - to avoid copyright issue - workshop earlier version of the work, extended versions to publish in prestigious journals (see the question in https://academia.stackexchange.com/questions/12524/how-extended-must-my-extended-paper-be for example ) - corrections (see for example http://dx.doi.org/10.1112%2Fplms%2Fs2-43.6.544 ) ... so if you dig a little this is. But the necessity to always have an edition item is controversial and potentially not well accepted by WikiProject Books or people from Wikisource.
- third: management of series of work : I was not able to find one. that's entirely correct. We're progressing on a case by case basis on that front. An example however of a TV series however : The Wire (Q478360)
.I'd be happy if someone launches a RfC or something to figure this out as series of work are pretty common and I'd definitely see the values if series of books, comics, TV series and so on have clear and consistent guidelines. However such processes are likely to fail in my experience but maybe it's my fault :). author TomT0m / talk page 10:05, 21 October 2016 (UTC)
- (After edit conflict) Okay, this sounds good, and I see why edition items could be useful (although I have no opinion on the question whether we should have them for all scientific articles, or just for those which have more than one edition). For me as an occasional user in this field it would be useful if there was kind of a guideline in a suitable WikiProject how to deal with these problems – and how to query for properly related items. RfCs are probably not the best method to set that up, I’d rather recommend to work with interested and experienced users in the WikiProject. —MisterSynergy (talk) 10:20, 21 October 2016 (UTC)
Something else : it appears quite correctly that the management of such a model can be heavy for people (including myself) sometimes, so that the either the enforcement of good practices once they are decided is to be helped with powerful tools or project like WikiProject Reasoning - Indeed if we decide that there is an article work for each article it could be useless to explicitly create them if not needed ... The same thing occurs if we decide that qualifiers of a reference established that there is an edition IRL that does not have an item in Wikidata ... I think technical solution to manage some implicit items would be a great help to make things easy for people as well as well-structured. author TomT0m / talk page 10:11, 21 October 2016 (UTC)
- Why creating complexity ? Just create two items, one for each part. Then to link both items use followed by (P156). Snipre (talk) 13:08, 21 October 2016 (UTC)
- This solution would simply reflect the technical fact that the article was split during initial publication. I don’t know the reason for this splitting, but I could imaging several ones (part two was not prepared early enough, whole article was too long end the editor refused to print in its entirety, whatever…). However, the two parts together shape one article, so from the content side it seems reasonable to have one item for the entire work, regardless of possible “sub-items” for the parts. —MisterSynergy (talk) 13:45, 21 October 2016 (UTC)
challenge mandated property (P2306), propose removal[edit]
I would like to challenge that we should be mandating property:P2306. There are multiple uses of P1433 for the entries in the biographical dictionaries and these entries have no specific title, so creating a title seems illogical. Similarly where it is used to identify part of a newspaper component, eg. a death notice, the snippet is part of the paper without specific reference. I would prefer if a title is required that it be on the actual item rather than as a label to the subpart of this property. Apart from the fact that it is added work without clear benefit.
I propose that we remove "item requires statement constraint -> property: title" — billinghurst sDrewth 00:59, 10 October 2017 (UTC)
- As of today "Violations count: 108341" shouts at us. — billinghurst sDrewth 01:01, 10 October 2017 (UTC)
- At this point of time I have removed the mandatory aspect and put it as an acceptable qualifier. — billinghurst sDrewth 05:50, 15 October 2017 (UTC)
SourceMD generated peculiar result[edit]
Can someone help me determine why published in (P1433) = Geologic map of Alaska (Q57841811) for items, e.g. Bathymetric contour map, surface area and capacity table, and bathymetric difference map for Clearwater Lake near Piedmont, Missouri, 2017 (Q59846243)? I thought maybe there was a problem in CrossRef, but I don't understand that resource AT ALL. This "published in" result appears in quite a few items that should have published in (P1433) = Scientific Investigations Map (Q59330615). I can probably figure out a Quick Statements way to replace the errors, but I'm also concerned it will continue to happen. Thank you. Trilotat (talk) 16:14, 25 May 2019 (UTC)
Do not use for countries![edit]
many contributors seem to believe this property is supposed to be used for countries rather than larger works
SELECT ?work ?workLabel ?country ?countryLabel WHERE {
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
?work wdt:P1433 ?country.
?country wdt:P31 wd:Q6256.
}
--Loominade (talk) 09:32, 9 July 2020 (UTC)
allowed entity types constraint[edit]
@Eihel: Hi, by looking to the structured data for Commons files I noticed a warning "Potential issue: allowed entity types constraint: The property published in should not be used on this type of entity, the only valid entity type is Wikibase item.", so I came here and I saw you added recently this constraint.
Exemple of where it can be used in Commons: c:File:Astrocladus coniferus (10.5852-ejt.2019.538) Figure 2.png (look at the tab "Structured data"
I wonder if it is possible to remove this constraint or to add an exception to constraint? Christian Ferrer (talk) 16:12, 19 October 2020 (UTC)
- Hello Christian Ferrer
Done Merci de votre signalement. Désormais, property scope constraint (Q53869507) et allowed-entity-types constraint (Q52004125) s'appliquent à toutes les propriétés (voir la tâche sur Phabricator ci-dessus). Votre lien sur votre modification sur Commons semble être logique, donc la contrainte doit être adaptée sur WD. Cette contrainte ne peut être retirée, sinon cela génère une autre violation. Mais la contrainte générant cette violation ne peut logiquement pas contenir d'exception, il suffit de l'adapter avec Wikibase MediaInfo (Q59712033) comme valeur. La prochaine fois lorsque une violation de ce type survient sur Commons, vous pourrez modifier la propriété en conséquence. En réalité, la nécessité de Q53869507 et Q52004125 est récente et vous n'apercevez pas de violation sur les autres « données structurées » sur Commons. C'est simplement parce que les autres propriétés n'ont pas encore ces 2 contraintes, exemple copyright license (P275) aussi présent sur c:File:Astrocladus_coniferus_(10.5852-ejt.2019.538)_Figure_2.png. Cordialement. —Eihel (talk) 02:01, 20 October 2020 (UTC)
_ —Eihel (talk) 04:34, 20 October 2020 (UTC)
- Ok merci beaucoup. Christian Ferrer (talk) 04:23, 20 October 2020 (UTC)
Music present in videogames.[edit]
If a song, that wasn't originally made for a videogame, is present in a videogame, does it count as the song being published in (P1433) the game? As an example: Several songs, including Atlas (Q3628246) and Left Bank Two (Q6516807), are present in the videogame franchise LittleBigPlanet (Q6579517). The songs weren't originally made for the games. As the songs are a part of the larger work that is LitteBigPlanet, I believe it makes sense fo the songs to have LittleBigPlanet (Q6579517) as a value of published in (P1433). (Note: The songs are collectible items in the first game, but can be transferred to later mainline games in the series, so I count the songs as a part of the series instead of any specific game.) OrnateAccount (talk) 17:14, 27 March 2022 (UTC)
- I have asked @Moebeus: about this @OrnateAccount:--Trade (talk) 22:09, 9 April 2022 (UTC)
- I think this would be a cool thing to model, personally I would love to see this information for tv series. I would be opposed to using "published in" as that will quickly get insane for very popular songs/tracks that are used a lot across different media, but a dedicated property on the video game/tv series episode could be great. There's lots of websites dedicated to this, https://www.tunefind.com , what-song.com , etc.
- One problem I can think of right away: how would we avoid duplicating information when a tv or video game soundtrack has gotten a proper release as a soundtrack album ? Something to think about. Moebeus (talk) 22:31, 9 April 2022 (UTC)
- Side note: for original music created specifically for an event, game, film, tv show, etc. we now have music created for (P9899) Moebeus (talk) 22:34, 9 April 2022 (UTC)
Discussion on connecting reference properties to CS1 in the Wikidata template[edit]
You are invited to join the discussion at Wikipedia:Module talk:Wd § References mapping. {{u|Sdkb}} talk 20:51, 7 June 2023 (UTC)
"language of work or name is not a valid qualifier for published in"[edit]
I think that this is inappropriate restraint Pienso que se trata de una restricción inadecuada. Muchas revistas científicas publican artículos en distintos idiomas, informar el idioma en que aparece un artículo es un dato de interés.JLVwiki (talk) 10:54, 30 January 2024 (UTC)
Published in periodicals with website forbidden[edit]
I'm concerned about some of the property constraints here, namely ones like these:
| property constraint (P2302) |
| ||||||||||||||||||||||||||||||||||||||||
| add value | |||||||||||||||||||||||||||||||||||||||||
_Figure_2.png){kind=link}
These constraints appear to have been added by Trade. I presume that the intent of these constraints is to provide precision to references on Wikidata to clarify when articles are accessed via a website rather than a printed periodical. I can appreciate this goal to some extent. However, it is not at all inappropriate to cite the actual printed periodical on Wikidata, and currently this presents a constraint violation. This constraint violation can be seen at Q125569297#P6872, which cites a printed edition of The Guardian from 1961 found at https://www.newspapers.com/newspage/259783367/ .
I propose that the existing constraints of this type be removed. Furthermore, I don't think widespread automatic replacement is possible. To achieve the goals of these constraints, I can only recommend editing the item descriptions to encourage future editors to differentiate between the website and the printed periodical. Daask (talk) 19:24, 23 April 2024 (UTC)
- Automatic replacing the statements added by "Autofill Details" would make most sense Trade (talk) 19:37, 23 April 2024 (UTC)
- @Trade: If Wikidata:Tools/CiteTool is producing the wrong data, I would think that the best solution is to fix the tool rather than cleaning up after it. In any case, my primary concern is that the property constraints here should be removed. Daask (talk) 22:57, 23 April 2024 (UTC)
- All Properties
- Properties with wikibase-item-datatype
- Properties used on 10000000+ items
- Properties with constraints on type
- Properties with conflicts with constraints
- Properties with qualifiers constraints
- Properties with scope constraints
- Properties with entity type constraints
- Properties with none-of constraints
- Reference properties