Wikidata:Property proposal/event role

From Wikidata
Jump to navigation Jump to search

event role

[edit]

Originally proposed at Wikidata:Property proposal/Generic

   Withdrawn
Descriptionitem that describes a role in an event class
Data typeItem
Domainoccurrence (Q1190554)
Example 1communication (Q11024)event roleQ_communicator_in_communication
Example 2communication (Q11024)event roleQ_content_in_communication
Example 3communication (Q11024)event roleQ_hearer_in_communication
Example 4eating (Q213449)event roleeater (Q20984678)
Example 5eating (Q213449)event rolefood (Q2095)
Sourceinitially based on PropBank, but extensible as needed
Planned useadd to (possibly newly created) items describing occurrences/actions
Expected completenessalways incomplete (Q21873886)
See alsopredicate for (P9970), has semantic argument (P9971)


Based on the discussion below, this proposal has been replaced by "has semantic role"

Motivation

[edit]

All events and actions have semantic core roles - "eating" has the "eater" and the "eaten", "throwing" has the "thrower", the "target" and the "projectile". These roles are not optional. Every act of "eating" has an "eater" and the "eaten" independently of how and in which language it is expressed. Most of the existing items for actions do not mention these roles. See our project Events and Role Frames for a more detailed description and discussion. There are several property proposals currently under discussion: “agent of action”, “object of action”, “frame element” to partially remedy this problem. In our opinion, these proposals, while going in the right direction are limited (we discuss their limitations in our project pages). Instead, we propose a more general solution consistent with PropBank, the largest repository of structured event and action descriptions (over 11,000 role sets).

In our proposal, an event can have several "event role" statements each pointing to a item that describes the role in greater detail. Such items will be subclasses of Q_event_role and will be specific to every event-role combination, e.g., Q_eater_in_eating or Q_eaten_in_eating. In some cases, there are existing items that can be used as event roles. For example, eater (Q20984678) can be used as Q_eater_in_eating and food (Q2095) as Q_eaten_in_eating (although there are some problems in using these items that are discussed in our project Events and Role Frames). But in many cases the existing items that describe event roles do not currently exist and need to be created. The event role items use another proposed property "selectional preference" to specify the kinds of items that can play this role, see the selectional preference proposal. The proposed new items will connect back to the event via the "role in event" property, proposed separately.

It is important to note that the proposed property should be applied only to action and event classes, not instances. The event role items describe the instances that can play the role. To connect an actual instance of an event with an instance of a role we need another property and a qualifier: "event argument" and "argument type". These are described in related proposals.

To summarize, we distinguish between "event role" for event classes and "event argument" for event instances. The former point to an item describing the role, the latter to the actual item that plays the role in a specific event.

This is one of the five proposed properties that should be considered together: "event role", role in event, selectional preference, "event argument", and "argument type".

Mahirtwofivesix (talk), on behalf of Anatole Gershman 21:23, 28 November 2023 (UTC)[reply]

The project ontology people https://www.wikidata.org/wiki/Wikidata:WikiProject_Ontology should be notified. Unfortunately the project is too big to ping. I have added a section on https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Ontology mentioning this proposal. Peter F. Patel-Schneider (talk) 13:40, 19 April 2024 (UTC)[reply]

Discussion

[edit]
Reply: Can you provide translations of the concepts you used as examples? Sorry, I was not able to understand your argument. It seems you are suggesting that the events roles should be language dependent, at the lexeme level, am I right? If so, the point is it that proposal could be more aligned with the property https://www.wikidata.org/wiki/Property:P9971 as in https://www.wikidata.org/wiki/Lexeme:L3230#S1 Arademaker (talk) 14:05, 28 February 2024 (UTC)[reply]
@Arademaker It was a question rather than an argument. There is no way to translate the verbs in question to English, but they are used in a similar way to the English expression “value sale,” to describe a sale of discounted goods. For a good to be "valued" in this sense is to be made purchasable at a fixed cost.
In any case, since asking that question, I think it is possible and necessary for event items to be agnostic to transivity and verb valency since in some languages this can vary between individual speakers describing the same event. عُثمان (talk) 16:13, 17 March 2024 (UTC)[reply]
Reply: You are right, some of the event classes have existing items describing some of the event roles. I modified the proposal to reflect this. We have to be careful, though, some of the seemingly fitting candidates for an event role concept such as receiver (Q1339255) are intended for something else, "an information theory term" in this example.
You also suggest using has part(s) (P527) instead of the proposed "event role". The property has part(s) (P527) is defined as "object is a part of this subject" synonymous to "composed of". Examples include United States Congress (Q11268)has part(s) (P527)United States Senate (Q66096). While this property seems sufficiently general to cover event roles, a better solution may be to have the "event role" property as a more specific subclass of has part(s) (P527). This needs to be discussed further. --Anatole Gershman (talk) 17:27, 8 December 2023 (UTC)[reply]
@Swpb: thoughts on the above reply (and other replies to your concerns regarding the other proposals)? Mahir256 (talk) 21:15, 11 January 2024 (UTC)[reply]
  •  Oppose The first examples are not involving valid items. The status quo of eating (Q213449) practiced by (P3095) eater (Q20984678) provides the same information but is moer specific. A property that's about expressing relationships that can be already expressed in Wikidata but expressing them in a less informative way is not good. ChristianKl17:01, 22 March 2024 (UTC)[reply]
    eating (Q213449) is one of a few event types where the event roles are specified using the existing properties. Currently, Wikidata uses a variety of properties to represent event roles, including some fairly general ones such as practiced by (P3095), participant (P710), uses (P2283) and many event-specific ones such as perpetrator (P8031) and victim(s) (P8032). Currently, Wikidata property related to events (Q22964785) has 61 instances which may or may not include all of the properties used for event roles. It seems that such properties were added as needed without an overall schema. Many event types such as lecture (Q603773) or music competition (Q1955280) do not mention any roles at all. Since adding properties to Wikidata requires extensive discussion, it does not seem reasonable to use properties to represent a potentially open-ended set of event roles. For example, an event representing a chemical reaction may have several specialized roles for various ingredients. We may not want to add new properties for such roles. It is also highly unlikely that Wikidata users would agree on a finite property ontology to represent all event roles. We proposed to solve this problem by adding a single property "event role" whose object is a Q item describing the role. For many event types such role items do not exist and have to be created. Anatole Gershman (talk) 01:41, 26 March 2024 (UTC)[reply]
    I don't think we want to overpopulate or duplicate 'role Qnodes', many of which already exist (e.g., eater, Q20984678, runner, Q12803959, etc.) but we need a way to describe and organize these Qnodes as stakeholders in a verb/event (the subject of eating Q213449, the subject of running, Q105674). The idea is to treat these roles systematically, adding more of them whenever appropriate to describe an event. Take 'public election' Q40231, it is useful to know that there will be an electorate and a political candidate. Knowing that a political candidate is a role in a public election can be useful when reasoning about the T-Box of the ontology.
    An organic way to label and connect existing -and new- Qnodes as roles of an event would give us a mechanism to reason about events in a more systematic manner. It doesn't affect the semantics of the roles that already exist and give us a framework to decide which other roles should be added. For example 'presidential election' (Q858439) has an 'office contested' role, but not a 'candidate' role. However the '2020 US Presidential Election' (Q22923830) has a 'successful candidate', which is a subproperty of 'candidate' (P726). This role of 'candidate' would be very useful to have in the 'public election' Qnode directly. Rosariou (talk) 19:17, 11 April 2024 (UTC)[reply]
    I strongly agree that tying into subproperties is better and fits better into Wikidata than the current proposal. Peter F. Patel-Schneider (talk) 13:20, 19 April 2024 (UTC)[reply]
@Arbnos: Why do you consider it important to for connectivity when connections can already be made? ChristianKl17:21, 22 March 2024 (UTC)[reply]
We want to make the connection of event participants to events much more consistent, so that it will be easy to find participants even if you don't know what they are typically called, and easy to extract the information automatically for all events if needed. Does the make sense? MarthaStonePalmer (talk) 20:09, 1 April 2024 (UTC)[reply]
@ChristianKl: thoughts on the replies to your comments above from Anatole, Rosariou, and Martha? Mahir256 (talk) 19:30, 17 April 2024 (UTC)[reply]
In Wikidata we generally want to describe relationships as specific as possible. This property is about reducing data quality by letting data be entered in a less specified way.
The suggestion that adding two different ways to enter the information will increase consistency suggests misunderstanding how modeling plays out in practice. If you have to different ways than you have less consistency within Wikidata because different users are going to use different models.
If you want a way to automatically query such relations you could add something like practiced by (P3095) instance of (P31) "Wikidata event role property". I'm not sure that this would be the best way to model it, but it would be the way to batch different properties together.
presidential election (Q858439) properties for this type (P1963) candidate (P726) is a way to express that all presidential elections have candidates in our current ontology. The fact that you come up with examples that our existing ontology handles perfectly fine suggest that it would be better to learn how our ontology works than trying to change it without understanding it. ChristianKl20:38, 17 April 2024 (UTC)[reply]
Yes, we do seem to be learning more about Wikidata every week, and we completely agree that we want any additions we make to synchronize well with what is already there. Rosario had suggested that we use subproperty (Q112037424) to show where something that is already there is more specific than what we want to add. practiced by (P3095) is an excellent example of a more specific version of what we have been thinking of as "event-role". So, if event-role got added as a property, we would also create a sub property relation between them. However, as it is currently defined practiced by seems to primarily be for human agents of human activities, so it is good where it applies, but it doesn't really cover earthquakes as agents of destruction, for instance. And earthquakes can have many effects, such as collapsing buildings, in addition to the landslides, tsunamis and soil liquefaction that are currently listed under has effect (P1542), another excellent property. We don't want to replace practiced by but simply create a more general structure that it would be connected to in a rational way, that will make it easier to add similar kinds of things more systematically, while providing appropriate links to things that are already there. We've been rethinking our original proposal, based on your comments as well as others, and will post our new suggestions soon. MarthaStonePalmer (talk) 22:42, 17 April 2024 (UTC)[reply]
Does this mean that the proposal will be amended so that there is a generic property and then specific roles for events would be subproperties of this generic property, reusing existing properties whereever possible? Peter F. Patel-Schneider (talk) 13:31, 19 April 2024 (UTC)[reply]
Yes, where there are existing properties being used to identify semantic roles, we would create a subproperty of (P1647) relation. I'll give an example below. MarthaStonePalmer (talk) 19:57, 7 May 2024 (UTC)[reply]
I'm unsure how you would use a item like subproperty (Q112037424) here. What could be used is a construction with subproperty of (P1647). Practically, SPARQL however doesn't make it easy to search through all subproperties. The query has the same complexity as one using instance of (P31) to group all event role properties together.
practiced by (P3095)'s definition from the property proposal explicitely uses the term "agent" instead of person or human. So it's useable for nonhuman agents as well. I agree that an earthquake isn't an agent. We have has cause (P828) and has immediate cause (P1478) which could be used when an earthquake is the cause.
Ontology-wise, it's also worth noting that eating (Q213449) is a process (Q3249551) but not an event (Q1656682) or occurrence (Q1190554) (the same goes for communication (Q11024)). I would prefer consistant naming so "process role" would be more fitting than "event role". Process is a word out of Basic Formal Ontology (https://ontobee.org/ontology/BFO?iri=http://purl.obolibrary.org/obo/BFO_0000015). What's your motivation for using the term "event"? ChristianKl19:52, 20 April 2024 (UTC)[reply]
ChristianKI, you are quite right. I have been being sloppy in two ways, first in using "event" rather than "eventuality", which would indeed include processes and states as well as events. "eventuality-role", however, is such a mouthful, that now we are thinking of just calling "semantic-role" rather than "event-role." How would that be? You are equally right, that I had the wrong item. It is not the Qnode subproperty, but rather subproperty of (P1647), which Rosario had suggested. We should have been more precise. MarthaStonePalmer (talk) 20:01, 7 May 2024 (UTC)[reply]
  •  Oppose unless the entire proposal on events is modified to better fit in with what is currently in place in Wikidata. Peter F. Patel-Schneider (talk) 13:44, 19 April 2024 (UTC)[reply]
    We are working on a revision of our proposal which we hope to have soon, that will still be based on adding many semantic roles from PropBank. It will suggest that several properties, such as "practiced by (P3095) and "uses (P2283)", have a "subproperty of (P1467)" relation with "semantic role (Pxxxx). For instance, as when used with boxing:
    boxing (Q32112)
    -- uses (P2283)
    -- boxing glove (Q895679)
    -- uses (P2283)
    -- boxing ring (Q2290113)
    However, we would like to add a little more information here, to distinguish the role played by boxing glove with the role played by boxing ring. Hence, perhaps something like this:
    boxing (Q32112)
    -- uses (P2283)
    -- boxing glove (Q895679)
    -- has characteristic (P1552)
    -- instrument (Qxxx)
    We're considering whether it would be useful to replace "uses" with "location" for boxing ring, and also have a location subproperty of (P1467) semantic role. But which location? "location (P276)" seems quite general but maybe "work location (P937)" is more precise? It is already a subproperty of "significant place" which seems relevant. Clearly we need a much better understanding of how these properties are typically used. This is not something we can do by ourselves, but would indeed need to be a community effort. Your comments are welcome. MarthaStonePalmer (talk) 20:33, 7 May 2024 (UTC)[reply]