Property talk:P793
Documentation
significant or notable events associated with the subject
| Description | significant events associated with the subject. Use only when no more specific date property exists. See the list of proposed significant events. | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Represents | key event (Q2245405) | ||||||||||||
| Data type | Item | ||||||||||||
| Domain | According to this template:
all domains
According to statements in the property:
When possible, data should only be stored as statementsentity (Q35120) | ||||||||||||
| Allowed values | According to this template:
occurrence (Q1190554) (occurrence) or event (Q1656682) (organized meeting)
According to statements in the property:
When possible, data should only be stored as statements | ||||||||||||
| Usage notes | Must be qualified with appropriate date and context properties. | ||||||||||||
| Example | Dennewitz (Q882375) → Battle of Dennewitz (Q647827) Friedland (Q4492725) → ship launching (Q596643) Vladimir Putin (Q7747) → first inauguration of Vladimir Putin (Q24957710) | ||||||||||||
| Tracking: usage | Category:Pages using Wikidata property P793 (Q20990058) | ||||||||||||
| See also | significant person (P3342), commissioned by (P88), owned by (P127), closest approach (P6354), feast day (P841), significant place (P7153), date of resignation (P9667), created during (P10408), notable work (P800) | ||||||||||||
| Lists |
| ||||||||||||
| Proposal discussion | Proposal discussion | ||||||||||||
| Current uses |
| ||||||||||||
| Search for values |
List of violations of this constraint: Database reports/Constraint violations/P793#Value type Q1190554, Q14136353, Q24336466, Q58415929, Q171558, Q1656682, Q751989, Q49703, Q1914636, Q4071928, Q1172486, Q16513426, Q185451, Q30111082, SPARQL
Replacement property:
Replacement values: (Help)
List of violations of this constraint: Database reports/Constraint violations/P793#Type Q35120, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P793#Scope, SPARQL
List of violations of this constraint: Database reports/Constraint violations/P793#Entity types
Replacement property:
Replacement values: (Help)
List of violations of this constraint: Database reports/Constraint violations/P793#none of, SPARQL
Replacement property: business model (P7936)
Replacement values: (Help)
List of violations of this constraint: Database reports/Constraint violations/P793#none of, SPARQL
|
Value frequency of first names in the Netherlands, 2010 (Q21644845) will be automatically replaced to value frequency of first names in the Netherlands, 2010 (Q21644845) and moved to attested in (P5323) property. Testing: TODO list |
|
|
Value most frequent first names at birth in Rotterdam (1811-1913) (Q21142040) will be automatically replaced to value most frequent first names at birth in Rotterdam (1811-1913) (Q21142040) and moved to attested in (P5323) property. Testing: TODO list |
|
|
Value frequency of first names in Israel, 2014 (Q39131224) will be automatically replaced to value frequency of first names in Israel, 2014 (Q39131224) and moved to attested in (P5323) property. Testing: TODO list |
|
|
Value Holocaust survivor (Q12409870) will be automatically replaced to value Holocaust survivor (Q12409870) and moved to subject has role (P2868) property. Testing: TODO list |
|
|
Value oldest human (Q254917) will be automatically replaced to value oldest human (Q254917) and moved to subject has role (P2868) property. Testing: TODO list |
|
|
Value list of oldest persons of France (Q3038357) will be automatically replaced to value oldest person in France (Q107344155) and moved to subject has role (P2868) property. Testing: TODO list |
|
|
Value oldest person in France (Q107344155) will be automatically replaced to value oldest person in France (Q107344155) and moved to subject has role (P2868) property. Testing: TODO list |
|
|
Value centenarian (Q2944360) will be automatically replaced to value centenarian (Q2944360) and moved to subject has role (P2868) property. Testing: TODO list |
|
|
Value alleged centenarian (Q107460864) will be automatically replaced to value alleged centenarian (Q107460864) and moved to subject has role (P2868) property. Testing: TODO list |
|
|
Value supercentenarian (Q1200828) will be automatically replaced to value supercentenarian (Q1200828) and moved to subject has role (P2868) property. Testing: TODO list |
|
|
Value alleged supercentenarian (Q106991708) will be automatically replaced to value alleged supercentenarian (Q106991708) and moved to subject has role (P2868) property. Testing: TODO list |
External use
[edit]
How do we use this property?
[edit]This property can be used to create a timeline of key events associated with an item so it can be used for any item that has a lifetime sequence that might be expressed as a timeline.
- Use this property for events associated with one-off objects, like ships, buildings, works of art, motorways, railway lines, dams, and other large construction projects. Values such as Contract, Keel laying, Foundation, Topping out, Launch, completion, renovation, damage, closure, destruction.
- Use this property for events associated with mass produced objects like cars, mobile phones, airplanes, software, video games. Values such as prototype, initial sale, design change, final sale, end of support.
- Use this for books (literary works), movies, albums which are works of art but with multiple examplars. Values such as Recording, publication, Premiere, Golden discs, etc.
- Use this property for a scientific or academic or political theory or paradigm - heliocentrism, evolution, expanding universe, salvation by faith alone, abolition of slavery, legalisation of homosexuality, prohibition of alcohol, Tea party movement. Values such as first publication, conferences held, laws passed, nobel prize won.
- Use this property for organisations. Values such as foundation, milestones (a thousand members, a million members, turnover reaches a million dollars etc.), new branches, new product areas, new headquarters building, bankruptcy, takeover.
- Use this property for clothing items, fads, or fashion trends with value "heyday" to indicate the subject's period of peak popularity or influence when that differs from its first appearance (inception).
This property links to items. These may be generic items for a class of events. These items should have the statement subclass of (P279)=key event (Q2245405) or subclasses of this such as key event (ships) (Q14904124).
Alternatively this property can be used to link to items for specific events related to the subject, as a way of linking these items in a chronological sequence or geographical extent.
Preferred alternate specialized properties
[edit]- time
- inception (P571)
- time of discovery or invention (P575)
- service entry (P729)
- service retirement (P730)
- date of disappearance (P746)
- dissolved, abolished or demolished date (P576)
- date of burial or cremation (P4602)
- date of first performance (P1191) (for performing art productions (in front of a live audience))
date of baptism (P1636)
- location
- place of birth (P19)
- place of death (P20)
- place of burial (P119)
- work location (P937)
- location of first performance (P4647) (for performing art productions (in front of a live audience))
- other
- canonization status (P411), qualifier point in time
Discussion
[edit]We need an explanation about how to use this property and in which field we can apply this. Snipre (talk) 08:14, 18 August 2013 (UTC)
- I have added a first draft of the explanation above. Filceolaire (talk) 11:01, 18 August 2013 (UTC)
- I propose to use start time (P580) instead of point in time (P585) in order to keep the data extraction process as simple as possible: this allows the extraction of events which last more than one day. By convention if the event lasts only one day the end date can be omitted. Snipre (talk) 09:01, 18 August 2013 (UTC)
- I disagree. Start date' with no 'end date' usually means the item is still ongoing. I think we should use 'Point in time' for events that happen at one time. When someone does a graphical timeline they will want different symbols anyway (star for one off; bar for event with duration) so the data needs to make it clear which is which. Filceolaire (talk) 11:21, 18 August 2013 (UTC)
- Actually, "point in time" doesn't make sense. The DateType, based at least on the data that it spits out, will handle down to the second level (and likely lower?). There is very rarely a "key event" which lasts for only one second. --Izno (talk) 22:21, 20 August 2013 (UTC)
- It can also be as vague as just the year. When they have sorted the user interface it should be possible to just specify the century, the millenium or any uncertainty we want to specify. Filceolaire (talk) 23:18, 20 August 2013 (UTC)
Production or distribution ?
[edit]Use production (Q739302) or product distribution (Q867147) ?
(*) But i think product distribution (Q867147) is more correct ! LucaBiondi (talk) 12:28, 24 August 2013 (UTC)
- Heu, production is linked with distribution: you can't distribute if you don't produce and the small due to stocks is never considered. For software we can discuss about the use of production: we can use operation in that case. But at the end we really need an unique term for all items because each field use a specific term we won't be able to extract the information in wikipedia. Snipre (talk) 12:54, 24 August 2013 (UTC)
- I agree with you, we need an unique term. I'll use production (Q739302) but in the case of the cars the meaning is the date of the start or the end of the marketing. LucaBiondi (talk) 17:39, 24 August 2013 (UTC).
More clarifications on rules
[edit]Following these rules, the key events e.g. for World Trade Center (Q11235) currently are only half-correct. Some follow these rules, e.g. groundbreaking ceremony (Q1068633), while September 11 attacks (Q10806) should be changed so it uses cause of destruction (P770), and for something like 1993 World Trade Center bombing (Q11240) there would be no place at all, even though this event is closely linked to the building. More generally, it's hard to link a specific item if we have one (e.g. there are several Wikipedia article about the construction of building X, but how to link it here?). And e.g. if we would allow a value nuclear accident (Q1620824), how to link Fukushima Daiichi nuclear disaster (Q171178) to Fukushima Daiichi Nuclear Power Plant (Q114295) (currently done using a statement is subject of (P805) qualifier, which looks a bit unnatural to me)? --YMS (talk) 10:26, 3 January 2014 (UTC)
- 1. the way Fukushima Daiichi Nuclear Power Plant (Q114295) links to Fukushima Daiichi nuclear disaster (Q171178) is, I believe, the right way to go:
- because Fukushima Daiichi nuclear disaster (Q171178) describes the relation between the plant and its nuclear accident, precisely what is specified in P805 property documentation. It is compact and flexible.
- 2. I am not too enthusiastic about using significant event (P793) for the construction, but it seems it's the most flexible scheme since the construction needs a start date and an end date, so no "construction date" property would do. However, whatever property is used to track the construction event, any number of items detailing the construction of that building can be associated through qualifier statement is subject of (P805) on the same "construction" statement.
- 3. I agree with @YMS: on World Trade Center (Q11235) : both significant event (P793) 1993 World Trade Center bombing (Q11240) and September 11 attacks (Q10806) should be rather specified as statement is subject of (P805) attached to, say, terrorist attack (Q15236208) and suicide attack (Q217327) (or massacre (Q3199915) or building collapse) respectively.
- 4. Finally the reverse relation (from the event item to the object undergoing to that event) has no clear property. I know that statement is subject of (P805) should not be used for that, but there is no "object" property. depicts (P180) is the best approximation, I believe. Suggestions welcome.
- LaddΩ chat ;) 03:13, 19 March 2014 (UTC)
- Why not using the Fukushima Daiichi nuclear disaster (Q171178) item for the key event and setting ? TomT0m (talk) 13:16, 22 March 2014 (UTC)
- @TomT0m: It could be done that way too, but people who set up the rules listed above elected to have a list of generic event types, rather than specific event description items. I guess it was necessary to agree on some scheme. (Note that this was before instance of (P31) was widespread.) LaddΩ chat ;) 22:18, 24 March 2014 (UTC)
- Maybe we should change that, this imply less complexity for the user. It's a bot work, and it would be a test to know if we can change anything in Wikidata at that point. TomT0m (talk) 10:16, 25 March 2014 (UTC)
- I think the framework described by Laddo makes sense. Creating items for all key events for all items does not seem very convenient to me. --Zolo (talk) 14:09, 25 March 2014 (UTC)
- Maybe we should change that, this imply less complexity for the user. It's a bot work, and it would be a test to know if we can change anything in Wikidata at that point. TomT0m (talk) 10:16, 25 March 2014 (UTC)
- @TomT0m: It could be done that way too, but people who set up the rules listed above elected to have a list of generic event types, rather than specific event description items. I guess it was necessary to agree on some scheme. (Note that this was before instance of (P31) was widespread.) LaddΩ chat ;) 22:18, 24 March 2014 (UTC)
- Why not using the Fukushima Daiichi nuclear disaster (Q171178) item for the key event and setting ? TomT0m (talk) 13:16, 22 March 2014 (UTC)
- depicts (P180) shouldn't be used for that, it has another domain. --Marsupium (talk) 15:03, 18 July 2014 (UTC)
Properties instead of classes of events?
[edit]I'm missing point how properties can do something that items cannot. Yes, small events unlikely to have a separate page at Wikipedia, so we have to create item for them.
Quite opposite, we cannot build hierarchies of properties as we can for pyramids of events.
I cannot see reason why narrow properties were picked here. d1g (talk) 15:00, 1 May 2017 (UTC)
- Simply to avoid explosion of items: just take the number of persons having an item in WD, then multiply that number by 4 or 5 and see the number of potential new items (for every person you have at least 2 events, the birth and the death). Snipre (talk) 16:02, 1 May 2017 (UTC)
- Why do we need more than 4-5 items as values of P793? P793=birth(PQ585=1900);death(PQ585=2000)? d1g (talk) 17:32, 1 May 2017 (UTC)
- In P136 we he have "sculptural genre" (Q18783400), "literary genre" (Q223393) and "musical genre" (Q18783400) classes, next link is about exact genre. We don't have links beyond "rock" (Q11399) class, so we can stop at "death" IMO. d1g (talk) 08:45, 2 May 2017 (UTC)
Some geographic events are periodical
[edit]"point in time" is not a reasonable qualifier if they repeat 10-100/year. d1g (talk) 14:52, 30 September 2017 (UTC)
- Could you please provide an example? --Pasleim (talk) 18:34, 30 September 2017 (UTC)
Is the "allowed qualifiers" constraint doing any good?
[edit]Almost any qualifier could reasonably apply to a P793 statement; what is the value in trying to capture them all? Swpb (talk) 13:30, 28 March 2018 (UTC)
- With each property if you expect to use some qualifiers than it is better to have final list so the people writing tools that interpret this data know what to expect. If needed more qualifiers can be added. --Jarekt (talk) 13:56, 28 March 2018 (UTC)
Strange (mis)use of "of (P642)" qualifier within significant event (P793) property
[edit]Look at Mona Lisa (Q12418) there is a statement there about significant event (P793)art theft (Q1756454)
I wrote the above message at Wikidata:Project chat with only Marsupium agreeing. I copied it here in hopes that we can find some sort of fix to the issue. Maybe we need "by", "old owner" and "new owner" qualifiers? --Jarekt (talk) 14:01, 28 March 2018 (UTC)
- @Jarekt: I think new properties are indeed the best option. I think the could also be used as statement properties, for example in theft of Mona Lisa (Q61266859). They would be similar to CIDOC-CRM's P22 transferred title to (acquired title through) and P23 transferred title from (surrendered title through). --Marsupium (talk) 21:29, 22 June 2019 (UTC)
Mandatory qualifier constraint necessary?
[edit]I saw that one can add this property without giving a date or period of time the event occured. Shouldn't there be a required qualifier constraint (Q21510856) so that either start time (P580) and end time (P582) or point in time (P585) are required qualifiers? I guess the problem with this would be that the mandatory qualifier constraint means that all of the listed qualifiers have to be given but in this case either the first two qualifiers or the last is/are necessary. It seems that there is no "one-of qualifier constraint" available on Wikidata. I haven't followed the project discussions intensively so I don't know wether such a constraint is still planned or not and if yes why it is not (yet) possible. If it is this topic here can be closed.--Leit (talk) 14:20, 30 May 2018 (UTC)
- Some events used as value already have a date on the item itself, so adding one in a qualifier isn't really needed.
--- Jura 18:06, 30 May 2018 (UTC)
"Point in time" mandatory?
[edit]Please have a look at St. Judas Thaddäus (Heisterbacherrott) (Q15129444). point in time (P585) is not neccessary because the more precise qualifiers start time (P580) and end time (P582) are already given. So why is point in time (P585) now a mandatory qualifier constraint for this property? I guess it should be mandatory to state either a point in time or a time interval (see above) but not both.--Leit (talk) 16:59, 12 February 2019 (UTC)
- I changed it myself.--Leit (talk) 20:21, 15 February 2019 (UTC)
- Agree! --Marsupium (talk) 18:11, 8 March 2019 (UTC)
Use in fashion
[edit]I've been using "significant event" > "heyday" to indicate the period when an item or style was popular or fashionable. These items are almost always subclasses, not instances, and now they get constraint violations because "significant event" cannot be applied to a subclass. How should we resolve this? - PKM (talk) 22:29, 20 April 2019 (UTC)
- I'm just going to delete it. Surely it's pretty common for subclass items to have significant events (e.g., products.) Ghouston (talk) 03:18, 26 June 2019 (UTC)
Retirement of a person
[edit]The "none of" constraint for value retirement (Q946865) doesn't leave me any way to indicate the date when a person retired. Was this constraint intended to prevent conflicts with service retirement (P730), or am I missing something? - PKM (talk) 00:11, 12 December 2019 (UTC)
- It was added by a bot [1], hard to know why. Ghouston (talk) 02:43, 12 December 2019 (UTC)
New qualifiers gained territory from (P7903) and gave up territory to (P7904)
[edit]See Property_talk:P7903#Area change about the new qualifiers for this property. --- Jura 15:29, 14 February 2020 (UTC)
Replaced by replica
[edit]Is there an event class for a placement of replica / imitation / copy of original entity (e. g. public artwork or monument) which was stolen (or moved to safe place)? It's quite common practice, but I cannot find any class, which suits this event. --Xth-Floor (talk) 19:20, 12 April 2021 (UTC)
Use for date events? Use for date modeled and date carved?
[edit]I'm looking into using this property as a qualifier on the inception property for date types or events like date carved, modeled, casted, etc. for works of art. I'm starting this topic to make sure this would be an appropriate way to use the significant event property.
It looks like this property is sometimes used like a "type" qualifier for date properties, as long as the "type" is an event. The examples table for artworks include the use of significant event as qualifier on date properties with the value acquisition (which is unexpectedly specific to museums: i.e., what if someone wanted to use this for something acquired by an archive or library?), but not publication date or production date, which are their own properties. "Production date" seems to exclude anything that's not film/audio drama, so a decorative arts object, which is an artwork but may have been "mass" produced would use significant event as a qualifier on a date property with the value of Production?
I'm guessing that rather than hope for specific "date carved," "date modeled," and similar dates as properties, or even hoping for a specific "date event" or "date type" qualifier, that using significant event to capture this information would be appropriate and preferred?
For example, this sculpture was modeled around 1872, but carved 1876: Poor Cupid. This is not an uncommon distinction made for sculptures. A mold could be created years before it's cast, as another example, and might even be cast posthumously. There are likely too many of these types of events to anticipate, so having a flexible way to include different date types or date events when the need arises. Sonoet2 (talk) 18:54, 3 February 2022 (UTC)
- @Sonoet2: Normally I think significant event (P793) should be used as a main statement, rather than a qualifier. So significant event (P793) = modeling (Q3317838) with a qualifier for point in time (P585), rather than the other way round.
- The (current) 3.6% of uses that do use P793 as a qualifier are pretty non-standard, so should maybe not be expanded further. (Ideally they should be replaced with something more standard if possible). Jheald (talk) 11:29, 31 July 2022 (UTC)
- @Jheald That makes sense. I'd probably still have both dates listed as inception dates, else these might be left out of date related queries, but will follow your suggestion of removing the significant event (P793) qualifiers to main statements with point in time (P585) as a qualifier. Thank you! Sonoet2 (talk) 21:04, 14 December 2022 (UTC)
Most common uses of P793 for buildings / architectural structures
[edit]I was looking for some more significant events for buildings, beyond the table able
Here's a query https://w.wiki/5XDH to try to find the most common current uses of P793 for buildings / architectural structures (sampled from 5000 random uses of P793)
We should maybe standardise some of these (sometimes we seem one item to say the same thing); and add some more to the table above
- eg redevelopment (Q1441983) for adaptive reuse (Q2086116) of a building into apartments ? (Or should a specific item be created for just this?) I see there is also renovation for repurposing (Q56289407) used a few times.
- (eg as on Q17552077#P793, Q26490294#P793 -- though does use of "redevelopment" here sound too much like they were demolished, rather than adaptively reused?)
- expansion (Q19841649) could maybe also be flagged up more prominently, for building enlargement / extension.
The table that is above here of recommended uses of significant event (P793) for buildings could maybe also be usefully copied to and extended at Wikidata:WikiProject Built heritage/Data structure
- @Jheald: the hard question here is: is it the same thing? redevelopment (Q1441983) says "new construction" while adaptive reuse (Q2086116) says "reuse", it feels like that the work are heavier in the first case, no? Like if a new level or an extension is built on top of a building I would use the first but if it's only minor reconstruction inside a building I would use the second (or renovation for repurposing (Q56289407)). I don't see a clear cut and I'm fear that when people used these values, it was not clear for them either. Cheers, VIGNERON (talk) 11:34, 31 July 2022 (UTC)
- @VIGNERON: Thanks for your speedy response. For me, a new level on a building should be expansion (Q19841649) (as eg on the Water Board Office, New River Head (Q17552077) building in the '30s). As for what happened in the '80s/'90s that such a radical change seems a bit more than renovation for repurposing (Q56289407) to me suggests. But these are quite common events for old buildings, so we should think how best to model them clearly and well. Jheald (talk) 11:47, 31 July 2022 (UTC)
- For what it's worth, here's a query https://w.wiki/5XFp for how redevelopment (Q1441983) is currently being used with significant event (P793) -- mostly to indicate a 'major remodelling', I think, rather than wholescale demolition of a site and new-build for a different purpose. Jheald (talk) 14:41, 31 July 2022 (UTC)
- @VIGNERON: Thanks for your speedy response. For me, a new level on a building should be expansion (Q19841649) (as eg on the Water Board Office, New River Head (Q17552077) building in the '30s). As for what happened in the '80s/'90s that such a radical change seems a bit more than renovation for repurposing (Q56289407) to me suggests. But these are quite common events for old buildings, so we should think how best to model them clearly and well. Jheald (talk) 11:47, 31 July 2022 (UTC)
- As another case-example for consideration, how would people model the various events in the development of Hill of Tarvit (Q11838965) ? Jheald (talk) 11:42, 31 July 2022 (UTC)
Demolition vs Destruction
[edit]For buildings (and art works) demolition (Q331483) and destruction (Q17781833) are separate event classes in the table. Wouldn't it be better to include demolition (Q331483) as qualifier cause of destruction (P770) of destruction (Q17781833)? --Arch2all (talk) 12:11, 15 August 2022 (UTC)
- I'd say yes, generally there are too many ways something can be destroyed (eg for ships, wrecking, breaking, sinking, scuttling, bombardment), but having them all as qualifiers of {{Q|17781833) makes queries easier. Vicarage (talk) 17:47, 20 August 2022 (UTC)
(Q760072)
[edit]could someone help me to include Q760072 Oursana (talk) 23:12, 11 September 2023 (UTC)
- What is wrong with https://www.wikidata.org/w/index.php?title=Property_talk:P793&diff=1972659185&oldid=1832725022&diffmode=source ? - Valentina.Anitnelav (talk) 10:18, 12 September 2023 (UTC)
Use on Commons files
[edit]@Strakhov: You added the constraint parameter to allow usage on Wikibase MediaInfo entities, i.e. Commons files. Could you please add some Wikidata property example for media (P6685) statements to illustrate what you thought of? I saw this edit (by PMG), and it doesn’t feel right for me (I think depicts (P180) would be more appropriate). —Tacsipacsi (talk) 20:56, 31 December 2023 (UTC)
- Tacsipacsi: This search offers 4 792 490 results and I'm pretty sure most of them feel... pretty much the same as the edition you pointed out ("event related to the file", as in [2]). If that's not OK then there is a lot of work to do migrating values, and some of them would certainly not be OK with P180 (this one for example?). Regards. strakhov (talk) 21:15, 31 December 2023 (UTC)
Use in FC Barcelona (Q7156)
[edit]Could someone complete the values of this property in FC Barcelona (Q7156)? Masoud.h1368 (talk) 20:49, 22 May 2024 (UTC)