Wikidata:Property proposal/frame element of

frame element of

Originally proposed at Wikidata:Property proposal/Generic

   Not done

Description	MISSING
Represents	frame element (Q115792611)
Data type	Item
Domain	item
Example 1	dog (Q144)frame element ofdog walking (Q38438)
Example 2	dog walker (Q43277185)frame element ofdog walking (Q38438)
Example 3	collar (Q1985273)frame element ofdog walking (Q38438)
Example 4	walking (Q6537379)frame element ofdog walking (Q38438)
Example 5	pleasantness (Q47455763)frame element ofdog walking (Q38438)
Planned use	I plan to begin a Wikidata project in which I construct a database of frames for Akkadian, a low-resource language. This will represent a linked open data version of a database structurally similar to Berkeley's FrameNet for English.

Motivation

I propose introducing a family of properties which allow the description of frame semantics on Wikidata, roughly following the schema established by the Berkeley MetaNet project for English (https://metaphor.icsi.berkeley.edu/pub/en/index.php/Category:Frame), which in turn roughly follows the schema of FrameNet. Many of the proposed properties can be externally linked to the MetaNet project or to FrameNet. The reason I turn to MetaNet is because that project's setup is specifically geared towards conceptual metaphors, which is also my interest. The concept of a frame element is similar to MetaNet's 'role', which is one of the most fundamental properties in frame semantics. In the MetaNet schema a role describes an actor or cause in a scene, such as a waiter in a restaurant or the wind in a storm. Frame elements generalize roles (Q117747915) to include actions and states, which go alongside roles in a gestalt-like fashion (meaning one cannot be completely defined independently of the other). Thus for the frame WALKING THE DOG, important frame elements include: DOG, DOG OWNER, WALKING, EXERCISE. The property of 'has frame element' is different from that of subframe or 'subcase', where one frame is a constituent element of another (e.g. DRIVING TO WORK may have the subframe STARTING THE CAR).

I make these proposals because I wish to start a project involving building a database of frames for a low-resource language (Akkadian), which currently has no representation involving frame semantics on the internet. Although there are web projects for frame semantics involving languages like English (e.g. FrameNet, MetaNet), much of the data of these projects cannot be readily imported for other languages due to the cultural idiosyncracies behind some of their more complex frames. Hence the need to develop property types specifically within Wikidata.

Currently the only other property proposals in Wikidata involving frame semantics are for FrameNet Frame ID and FrameNet Lexical Unit ID. I propose to go beyond this with a minimal but functional set of properties describing general frames and their components.

These proposed properties are immediately relevant to the set of Akkadian (and Sumerian) lexemes being developed on Wikidata by Adam Anderson and Timo Homburg out of data from Oracc (an online repository of lemmatized Akkadian and Sumerian texts - http://oracc.museum.upenn.edu/). An example of such a lexeme is 'abala' (https://www.wikidata.org/wiki/Lexeme:L709438). With the addition of the proposed frame semantic properties, these lexemes would acquire added relevance to natural language processing projects involving deep semantic parsing.

Discussion

•  Question Based on §Motivation it sounds like frame semantics (or at least your proposed implementation of it in Wikidata) lies conceptually somewhere between lexicographical data (it’s more semantically structured than those) and statements over items (it’s more language-specific than those). Would that be an accurate enough characterization? ―BlaueBlüte (talk) 20:36, 9 February 2023 (UTC)

  Hello,

  I apologize for the delay in responding. I thought I would get automatic updates about Wikidata to my main email account, but this seems not to be the case.

  Basically, you are correct. The frame implementation should not as a matter of definitions be strictly tied to a particular language (many frames are arguably human universals), even as many of the more elaborate ones are. In particular, most projects aiming to build a database of frames originate in a particular language or set of languages, with one of their elements being the lexical items or constructions in the language that evoke the frame.

  With regard to statements (if I understand the issue correctly), one conceptual difference between them and frames is that frames are technically gestalts. While one could (for data encoding purposes, say) express as a set of triple-like statements (DOG is a frame element of WALKING DOG frame, etc.), this may obscure the fact that the frame is what links everything together and in fact is the constituting context out of which all the elements become distinguished. In terms of implementation in Wikidata we would take the frame item as the basic one, connecting it to various role times via the properties I suggested. Statements would be the triple-like expression of those connections. Sinleqeunnini (talk) 17:22, 13 February 2023 (UTC)

•  Oppose @Sinleqeunnini These relationships should be described in the opposite direction (dog walking -> collar) because collars can be used for more things other than dog walking. If they were described this way, I would probably use has part(s) (P527) to relate dog walking and collar, though a more-specific property could be proposed given that we are lacking some properties for specific Wikidata:Types of part-whole relations, which this use case might cover. Lectrician1 (talk) 05:49, 20 March 2023 (UTC)

  Hello,

  Actually, I do not see why this would be a large problem. It is true that collars can be elements of different frames, but that simply means linking collar to those separate frames. In addition, there needs to be the direction I gave because of the need to handle metonymy (referencing collar in place of another element in the frame or the entire frame) as well as the parallel relationship of subframe -> parent frame. Sinleqeunnini (talk) 20:17, 26 March 2023 (UTC)

  This is a problem because we recommend that the property direction is in the direction that results in the fewest statements per item and is on the most "relevant" item.

  Maybe metonymy should still be possible through a SPARQL query? Idk explain it to me more if it's really needed. Lectrician1 (talk) 13:12, 27 March 2023 (UTC)

  Hello again,

  I proposed the reverse property (has frame element) which should address the issue of directionality. On the other hand, I wonder if it is relevant that when constructing a number of frames it is often easier or more helpful to pick a certain role or action (i.e. frame element) which can function within a number of different frames, and link that role to the frames all on one page, rather than specifying in each of the frame definitions that they link to a single role. Sinleqeunnini (talk) 19:09, 16 April 2023 (UTC)

  @Lectrician1 Hello. Can you please check if the above property proposal is more satisfactory? Sinleqeunnini (talk) 19:51, 16 May 2023 (UTC)

  @Sinleqeunnini I don't know why you switched it back to "frame element of" from "has frame element"? I would not support. Lectrician1 (talk) 18:45, 17 May 2023 (UTC)

•  Not done, no consensus of proposed property at this time based on the above discussion. Regards, ZI Jony ^(Talk) 12:33, 24 January 2024 (UTC)