Property talk:P577
Documentation
- Start a query
- Current uses
- With precision and calendarmodel
- Statistics by class
- By century
- Date precision
- Calendar models
- List of qualifiers
- Count
date or point in time when a work was first published or released
| Description | publication date of the creative work (book, film, and so on) | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Represents | publication date (Q1361758) | ||||||||||||
| Data type | Point in time | ||||||||||||
| Domain | According to this template:
work (Q386724)
According to statements in the property:
When possible, data should only be stored as statementswork (Q386724), theory (Q17737), rule (Q1151067), group of works (Q17489659), version, edition or translation (Q3331189), fictional creative work (Q15306849), product (Q2424752), musical release (Q2031291), survey methodology (Q814232), item (Q121033050) or level (Q1046315) | ||||||||||||
| Allowed values | mw.text.lua:277: invalid value (nil) at index 1 in table for 'concat' | ||||||||||||
| Example | The standardisation of mineral group hierarchies: application to recent nomenclature proposals (Q19983493) → The Gold Rush (Q214723) → Polonaise-Fantaisie (Q3132823) → Soukenický cech v Příboře (Q48247091) → 1900s | ||||||||||||
| Robot and gadget jobs | DeltaBot does the following jobs: | ||||||||||||
| Tracking: same | no label (Q32100797) | ||||||||||||
| Tracking: differences | no label (Q32100793) | ||||||||||||
| Tracking: usage | Category:Pages using Wikidata property P577 (Q20990012) | ||||||||||||
| Tracking: local yes, WD no | no label (Q32070756) | ||||||||||||
| See also | publisher (P123), place of publication (P291) | ||||||||||||
| Lists |
| ||||||||||||
| Proposal discussion | Proposal discussion | ||||||||||||
| Current uses |
|
List of violations of this constraint: Database reports/Constraint violations/P577#Type Q386724, Q17737, Q1151067, Q17489659, Q3331189, Q15306849, Q2424752, Q2031291, Q814232, Q121033050, Q1046315, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P577#Conflicts with P31, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P577#allowed qualifiers, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P577#Range
List of violations of this constraint: Database reports/Constraint violations/P577#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P577#Entity types
List of violations of this constraint: Database reports/Constraint violations/P577#Conflicts with P31, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P577#Conflicts with P31, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P577#Conflicts with P31, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P577#Conflicts with P31, SPARQL
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Sheet music edit
I think this property should be used also for a date of publication of sheet music. --Pabouk (talk) 19:43, 1 June 2013 (UTC)
- I just proposed a more general property, applicable for more types of work than just books: Wikidata:Property_proposal/Creative_work#completed. But sheet music might considered as a book, I don't know. Anyway, my proposal would help for paintings/sculptures/etc. Nicolas1981 (talk) 09:16, 29 January 2014 (UTC)
- there is only one publication date for a work (song)
- sheet music is a tangible result of music publisher marketing their songwriter's works Tillywilly17 (talk) 00:09, 12 October 2021 (UTC)
Software edit
Can this be used for the (first?) release date of software? --Nemo 07:24, 4 May 2014 (UTC)
- As "software" is "subclass of" creative work, I would say so :) --Bthfan (talk) 13:04, 2 July 2014 (UTC)
film release date edit
Is there a possibility to add another release date for a film (example: first release on free tv; first release in another country, etc. -- 217.224.217.120 17:42, 14 January 2015 (UTC)
- Have a look at Lucy (Q15624215). --- Jura 18:13, 14 January 2015 (UTC)
Multiple Publication Dates (sub-works, volumes, etc) edit
What should one do when there are multiple publication dates for a work which represents multiple volumes or sub-sections? As concrete examples, consider the serialization of Great Expectations (Q219552) (from enwiki: "Serialized 1860-1; book form 1861", which I think would be represented as two Statements in wikidata, one for the complete book and the other for the serialization over a time period), or the ongoing pulication of The Art of Computer Programming (Q82438) (perhaps each volume should be a distinct Item?), or Kunstformen der Natur (Q1423459) (from enwiki: "Originally published in sets of ten between 1899 and 1904 and collectively in two volumes in 1904").
I think there are many cases of multiple publication where there can be multiple entries with qualification (eg, by "place of publication", or by edition), but sometimes that doesn't make sense. Perhaps the right thing to do is just take the first or last ("complete") date, but this is not complete. One option might be "start time" and "end time" qualifiers? Blnewbold (talk) 22:58, 25 January 2016 (UTC)
- a lot of books (in 2 or more volumes) have been published through a period of time, like "1866-1868"... currently, I add both, and qualify one with start time (Q24575110) and the other with end time (Q24575125). Not sure it's the best way... any thoughts @Billinghurst, VIGNERON: ? --Hsarrazin (talk) 10:28, 2 November 2017 (UTC)
- I would start with a comment about whether we are talking about an version, edition or translation (Q3331189) that is published over a span of time, or we are talking about a "work" that as a conceptual idea is published as of a date. Personally I feel that you would maybe need an instance of "serialised edition" (we may need to create the item) where I would then have specific and multiple publication dates, but that is my uneducated, unfinessed approach. If a work is volumes as in 63 vol. of biographies, I could see it argued that as each volume could have a separate (later) publication date, that the "parent work" could have a start and end date. — billinghurst sDrewth 11:09, 2 November 2017 (UTC)
- I've used start time (P580) and end time (P582), e.g. for the version, edition or translation (Q3331189) Dizionario mitologico, 1755-1758 Italian edition (Q54087754) as documented at Help:Dates#Qualifiers. I've added them to the allowed qualifiers constraint (Q21510851) now. --Marsupium (talk) 11:29, 25 May 2018 (UTC)
- I would start with a comment about whether we are talking about an version, edition or translation (Q3331189) that is published over a span of time, or we are talking about a "work" that as a conceptual idea is published as of a date. Personally I feel that you would maybe need an instance of "serialised edition" (we may need to create the item) where I would then have specific and multiple publication dates, but that is my uneducated, unfinessed approach. If a work is volumes as in 63 vol. of biographies, I could see it argued that as each volume could have a separate (later) publication date, that the "parent work" could have a start and end date. — billinghurst sDrewth 11:09, 2 November 2017 (UTC)
Add qualifiers "beginning" and "end" edit
Hi, I think we need to add qualifiers to this property: to specify, in case of a revue or journal, the beginning and the end of the publication. Regards, Yann (talk) 14:44, 11 June 2016 (UTC)
- I think we have inception (P571)/start time (P580) and dissolved, abolished or demolished date (P576)/end time (P582) instead. Paucabot (talk) 10:00, 10 September 2016 (UTC)
- Moreover, sometimes I need such qualifiers for inception (P571), because creation can be some long process. --Infovarius (talk) 17:58, 11 September 2016 (UTC)
- I've added the qualifiers start time (P580) and end time (P582) to the allowed qualifiers constraint (Q21510851) now as they are needed for multi-volumed works (and editions), cf. the section #Multiple Publication Dates (sub-works, volumes, etc) above. An example is Dizionario mitologico, 1755-1758 Italian edition (Q54087754). --Marsupium (talk) 11:31, 25 May 2018 (UTC)
- Moreover, sometimes I need such qualifiers for inception (P571), because creation can be some long process. --Infovarius (talk) 17:58, 11 September 2016 (UTC)
English description: Release date vs. publication date edit
@Sheldon.andre: I am going to revert the change from publication date to release date, since "release date" does not fit with current usage of the property in the context of scholarly publications, nor with the descriptions in other languages. I like the idea of calling this "release date", though, so I'm hereby inviting further opinions. The Source MetaData WikiProject does not exist. Please correct the name. --Daniel Mietchen (talk) 10:55, 15 August 2016 (UTC)
- Thanks. sheldon_andre (talk) 13:50, 15 August 2016 (UTC)
added qualifier edit
I have added sourcing circumstances (P1480) as an acceptable qualifier as there are works where there is no exact date of publication on the work, though its date is surmised through history and provenance. — billinghurst sDrewth 10:06, 2 November 2017 (UTC)
- thanks billinghurst, sourcing circumstances (P1480) should be an acceptable qualifier on all date type properties, since for old dates, it is never possible to get a certain date... :) --Hsarrazin (talk) 10:23, 2 November 2017 (UTC)
subproperty of begin date ? edit
Seems incorrect. U’ll remove. Please cry if that breaks something such that we can find a solution. author TomT0m / talk page 15:11, 2 March 2018 (UTC)
"Published in" as a qualifier edit
I added "published in" (P1433) as an property to the "allowed qualifiers constraint" (Q21510851) of "publication date" (P577), and it was reverted by Succu. I think that "published in" (P577) is a useful qualifier, just like "place of publication" (P291), which has been an allowed qualifier already. Succu, could you please explain your reverting? Thank you.--Neo-Jay (talk) 07:08, 16 June 2018 (UTC)
@Succu: I think that I understand why you reverted my edit. "Publication date" (P577) is the time when a work was first published or released. We do not need to differentiate a work's different first publication dates when it was "published in" (P1433) different larger works such as newspapers, books, or journals. Now I agree with you that P1433 should not be added as an allowed qualifier. Thank you. --Neo-Jay (talk) 07:31, 16 June 2018 (UTC)
Add version type (P548) to the allowed qualifiers edit
It would allow to indicate the first beta release and the first stable release--Malore (talk) 22:17, 14 July 2018 (UTC)
Add object named as (P1932) to the allowed constraints edit
Dates of publication may be expressed in Roman numerals or other systems, so object named as (P1932) should be added to the allowed constraints. --EncycloPetey (talk) 00:37, 19 July 2018 (UTC)
Add applies to part (P518) to the allowed qualifiers edit
This will occur, for example, for hymns where the publication of the lyrics often happens at a different time than the publication of the music. Calliopejen1 (talk) 05:11, 7 July 2019 (UTC)
Possible Constraints for date edit
Please take a look into this discussion--Alexmar983 (talk) 15:44, 27 February 2020 (UTC)
Constraint violation: range violation edit
What does this error mean in Harvest Template? I am trying to import release years f.e. into Q69490215. Queryzo (talk) 22:44, 16 May 2020 (UTC)
Editio princeps versus publication date edit
I think there is an inconsistent use of this property when talking about ancient or medieval manuscripts: does the date of publication refer to the original moment of creation by the scribe, or to the subsequent editorial publication of the manuscript in a scholarly journal? I think it is confusing, for example, to see items which have dates of publication 100BCE and 1900 at the same time.
Unless there is an already convenient wikidata property, I think we should refer to the original creation as "date of publication" and the subsequent scholarly printing as "editio princeps" and then use a different property for subsequent publications like P747 [1]. I [2] proposed this but want to cross-check with people using P577 already. --Valeriummaximum (talk) 21:26, 11 August 2020 (UTC)
Edition number edit
Hi all, why is edition number not allowed in the qualifiers as it is in all the other properties dealing with books? Volume is included but edition is not, that makes it difficult to be consistent. Thanks! Footlessmouse (talk) 21:46, 2 November 2020 (UTC)
Televisions series edit
Why was television series added to the constraints list? - X201 (talk) 08:28, 3 March 2021 (UTC)
- Television series are modelled with start time (P580) and end time (P582) for the broadcast/publication dates of the first and last episodes. publication date (P577) doesn't work well for series of works (television series, book series, etc.) where separate parts are published over a period of time. And while there are some series that get published in their entirety on the same date, it makes things more complicated using a different property only for those cases, instead of using that date as value for both start time (P580) and end time (P582). publication date (P577) can and should instead be used on the items for the indiviual episodes. --Kam Solusar (talk) 17:56, 3 March 2021 (UTC)
- Thanks for the explanation. Can I suggest removing "Air date" from the 'also known as' for this property? - X201 (talk) 09:11, 4 June 2021 (UTC)
undo not being reflected edit
This revision happened almost 16 hours ago, and I select "Publication date" from the options, but it is still rendering as "Abtin Yara _ Asheghm". Is it unreasonable to think that it should be caught up by now?--RaboKarbakian (talk) 20:29, 23 July 2021 (UTC)
publication date being used as "recording date" edit
https://www.wikidata.org/wiki/Q6091772
re song "It Had To Be You"
statement performer
Bob Dylan
statement is subject of It Had to Be You
publication date May 2016 <<<< this is recording date
has quality cover version
This song was published in 1924, and recorded many times since. I think hijacking "publication date" for "recording date" is bad idea
What do others think? There are several entries like this on this page btw I added real publication date 9 May 1924
.Tillywilly17 (talk) 03:08, 4 September 2021 (UTC)
Recording release date (Q108871058)
date an audio recording is released to public
- for consideration
inspiration:
film release (Q5449034)
date a film is released for viewing
Tillywilly17 (talk) 22:51, 11 October 2021 (UTC)
https://schema.org/releasedEvent
PropertyOn TypesDescriptionpublicationCreativeWork
A publication event associated with the item.released
EventCreativeWorkThe place and time the release was issued, expressed as a PublicationEvent.
anti-trust action needed edit
date or point in time when a work was first published or released
- first released
- first published
- air date
- pubdate
- date of first publication
- first publication
- airdate
- release date
- date published
- date released
- published
- dop
- year of publication
- initial release
- date of release
- date of publication
- released
- time of publication
- publication
- publication time
- launched
- launch date
- released in
- was published in
- be published in
- be published during
- was published during
- broadcast date
- first published
- date published
- pubdate
- date of first publication
- first publication
- published
- dop
- year of publication
- date of publication
- time of publication
- publication
- publication time
- was published in
- be published in
- be published during
- was published during
- first released Recording release date (Q108871058)
- release date Recording release date (Q108871058)
- date released Recording release date (Q108871058)
- initial release Recording release date (Q108871058)
- date of release Recording release date (Q108871058)
- released Recording release date (Q108871058)
- released in Recording release date (Q108871058)
- broadcast date
- air date
- airdate
- launched
- launch date
Constraint about unique best value edit
There was recently a mini-edit war about a best constraint value, cf. https://www.wikidata.org/w/index.php?title=Property:P577&diff=1641798875&oldid=1641478647
This is the result of a clash of domain usage.
As an introduction it’s worth noting that this property was first introduced for books / literary work. It’s customary on those domains to have a model « work / edition ». On Wikidata we have items about works, and items about editions.
It’s then been used for other arts domains, such as movies and/or video games. The distinction between works and edition is less used in those domain who often not follow the model used in the book industry or libraries.
The result is a clash : there may be several date of publication in video games items, whereas it’s usually forbidden in books.
There is several ways out, I think :
- statu-quo. No constraints
- Problems : the edition custom is not taken into account and clash of edition dates are not showed to users. This might entail that the « work / edition » model is broken by unaware users.
- we restore the constraints
- Problems with this solution is that we need to solve the issue for domains which does not follow the work/edition distinction.
- we create new properties for edition of movies, video games …
- Problems
- it become harder to compare the period of publication artworks whatever their kinds, is it worth it ? Maybe less consistency in how we model domains that are nevertheless very close, maybe harder to learn/query for users with interests in all the domains.
- Advantages
- tailored constraints that local community of interest could chose for themselves without discussing too much with others.
- align other domains with the book one and create edition items, for language/local edition/platform … in other domains
- seems unlikely that communities would agree, but deserved to be put on paper.
I for myself think we can adopt the solution 2 without (too much) problems. During the discussion on the edit comment of the « edit war » there has been several points mentioned, one is « there is several dates of first edition in video games ». I think this point is missing something : there is always a date of first edition, as it’s exactly the same in the book industry, and put it in the « best rank ». Simply take the place where the book has first edited, independently of the place. The values of the other places/countries/continents/languages edition can still be put, in normal rank, with qualifiers for the place if needed.
Another point has been raised : it’s not always easy to find a convention for the « date of first edition » for movies. Do we choose the first projection, in a festival ? the « première » of a movie ? It’s a matter of choice/convention.
@Mith, Poslovitch, Putnik: 
WikiProject Movies has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Notified participants of WikiProject Video games (please ping other projects if I forgot)
- See also : in french, a discussion on the bistro on the issue at hand. Some of the question above have been raised, it’s been suggested for stuff like the « première » to use a property like significant event (P793)
to include the dates in the item without using the « date of first edition » property. author TomT0m / talk page 14:33, 1 June 2022 (UTC)
- For video games, a single-best-value constraint (Q52060874) with separator (P4155) = place of publication (P291) and platform (P400) and distributed by (P750) might work. It also seems like the project ping had no effect. Dexxor (talk) 20:07, 1 June 2022 (UTC)
- @Dexxor That would entail that if you want to order works by their publication date, you would have to take care of the qualifiers to filter out duplicates, which would make the query complicated and kind of defeat the advantages of a unique value, imho. It’s as good as having several properties, maybe in worse. author TomT0m / talk page 20:26, 1 June 2022 (UTC)
- I was thinking about infoboxes that fetch the publication date from Wikidata. In that context, it makes sense to have multiple values returned. But I agree that setting the rank of the earliest date to preferred would be very useful for queries. So I will support solution 2 (restoring the constraints) if the movie domain agrees. —Dexxor (talk) 05:57, 2 June 2022 (UTC)
- It’s easy for infoboxes to retrieve all valid statements instead of only best ones, actually. author TomT0m / talk page 06:13, 2 June 2022 (UTC)
- I was thinking about infoboxes that fetch the publication date from Wikidata. In that context, it makes sense to have multiple values returned. But I agree that setting the rank of the earliest date to preferred would be very useful for queries. So I will support solution 2 (restoring the constraints) if the movie domain agrees. —Dexxor (talk) 05:57, 2 June 2022 (UTC)
- @Dexxor That would entail that if you want to order works by their publication date, you would have to take care of the qualifiers to filter out duplicates, which would make the query complicated and kind of defeat the advantages of a unique value, imho. It’s as good as having several properties, maybe in worse. author TomT0m / talk page 20:26, 1 June 2022 (UTC)
- For video games, a single-best-value constraint (Q52060874) with separator (P4155) = place of publication (P291) and platform (P400) and distributed by (P750) might work. It also seems like the project ping had no effect. Dexxor (talk) 20:07, 1 June 2022 (UTC)