Wikidata:Property proposal/value contains sense

value contains sense

Originally proposed at Wikidata:Property proposal/Generic

   Withdrawn

Description	qualifier to indicate the sense of a lexeme part of a monolingual text value
Data type	Sense
Domain	item
Example 1	Take My Hand (Q115917654) title (P1476) Take My Hand (English) edit value contains sense take (to reach for and hold with ones hand) value contains sense hand (extremity at the end of an arm or forelimb) 0 references add reference add value
Example 2	Harry Potter and the Philosopher's Stone (Q43361) title (P1476) Harry Potter and the Philosopher's Stone (British English) edit value contains sense stone (Body of mineral materials) 0 references add reference add value
Example 3	Immune: A Journey into the Mysterious System That Keeps You Alive (Q108043286) subtitle (P1680) A Journey into the Mysterious System That Keeps You Alive (English) edit value contains sense journey (task or trip with some difficulty or longer than expected amount of time than planned) 0 references add reference add value
Planned use	When I'm documenting the titles of works, particularly discographies or any other time I add a monolingual text statement.

Motivation

Helps specify the definitions of lexemes in monolingual text statements and can be utilized to find real-world examples of senses being used. Lectrician1 (talk) 16:17, 12 January 2023 (UTC)

Discussion

•  Oppose Until the proposal makes clear, beyond just examples, that this property is only meant to be used as a qualifier (it would be horrific if this was used as main statement referring to labels). Ainali (talk) 16:45, 12 January 2023 (UTC)

  I agree. @Lectrician1: please make it clear if you intend it only to be used as a qualifier. -- Rdrg109 (talk) 17:08, 12 January 2023 (UTC)

  @Ainali @Rdrg109 Done. Lectrician1 (talk) 17:11, 12 January 2023 (UTC)

•  Support as long as it is only intended to be used as a qualifier. We don't have a way to link values of Monolingual text properties to lexemes, this property accomplishes that goal. Note that we won't be able to use this property in text stored in qualifiers and references, since we can't add a qualifier to a qualifier or reference. For a solution to that issue, please read User:Rdrg109/1/27 (specifically this part (permalink)) where I explain a major feature request in Wikibase that would give us the most precision for linking a text to a sense. -- Rdrg109 (talk) 17:07, 12 January 2023 (UTC)
•  Support Interesting for translation. -wd-Ryan (Talk/Edits) 17:03, 16 January 2023 (UTC)
•  Weak oppose Do we really need to attach so many qualifiers on every monolingual text statements? Instead the sense can already include a few examples that sufficiently demonstrate its usage. Midleading (talk) 03:23, 24 January 2023 (UTC)

  @Midleading How else are we supposed to know the senses of monolingual text values? It's useful data to have. Lectrician1 (talk) 17:07, 24 January 2023 (UTC)

  Are you going to use this property soon? From a developer point of view this is not enough, we also need to store "value contains form", start position and end position. Apart from the problem that qualifiers can't be grouped like references, it is also very tedious to add manually or with bots. Without widespread usage, this property can't be used to train AI models. Very few human users would benefit from this either, people either already know the information, or could learn it through Wiktionary or other existing examples in Wikidata. Midleading (talk) 04:42, 25 January 2023 (UTC)

  @Midleading

  Are you going to use this property soon?

  I am. See planned use.

  From a developer point of view this is not enough, we also need to store "value contains form", start position and end position.

  I don't think we do... If we know the sense, well then we can get the lexeme and then just perform a simple search for the all the forms of that lexeme and check if it exists in the string. If it does, then we know the form. Of course, we run into the issue of what do we do if the same lexeme is present multiple times in the string. Then we can't be completely specific. However, those instances should be uncommon.

  Apart from the problem that qualifiers can't be grouped like references, it is also very tedious to add manually or with bots. Without widespread usage, this property can't be used to train AI models.

  Well it doesn't help that sense datatype properties don't have autocomplete yet which could help with usage. I plan on adding it every time I use a monolingual text property. I'm sure others might be interested if they see its usage as well. It could even gametized in the future to encourage more uses as well.

  Very few human users would benefit from this either, people either already know the information, or could learn it through Wiktionary or other existing examples in Wikidata.

  Well, like you said it can be used to train AI models which benefit humans. And like wd-Ryan said, it could help with translation as well. Lectrician1 (talk) 14:17, 25 January 2023 (UTC)

  It would be great if this property could be widely used. From my point of view this looks bloated as I only use the item namespace for things unrelated to lexicography, but other people could find it useful. The usage and quality control would be the hardest thing if the property is created. Among the 3 examples here there's already an error, journey (take a trip) is a verb, while the noun should used. Note that Lexeme:L1339 already contains examples with subject sense (P6072), which looks like what this property is supposed to be. Of course these are not reasons this property should not be created at all. I just think it is a bit too early now. People actually training AI models simply use Wikipedia and Wikisource, and Wikidata will never be a superior source of natural text than that. Midleading (talk) 15:07, 25 January 2023 (UTC)

  Ya oops lol. Fixed. Lectrician1 (talk) 22:48, 25 January 2023 (UTC)

•  Question I would imagine that particularly discographies contain lots of poetic titles with vague, ambiguous meanings, innuendos, etc. Probably there will be cases were the same part of a string could be said to ‘contain’ multiple, or not quite decidedly one of multiple, senses. And a string may have multiple parts. Would there also be no differentiation between those two kinds of multiples (just like there seems to be no practical way to differentiate the parts of a string according to order)? Not an objection; rather, this should perhaps be clarified in the documentation. ―BlaueBlüte (talk) 10:53, 30 January 2023 (UTC)
•  Comment I propose to have the label for this property read something like “string alludes to sense”. For one, that would clarify the intended usage (only on string values), and also allow for the fact that there will hardly ever be a clear-cut one-to-one relationship between a (part of a) string and the sense, and it would better accommodate non-literal references. With that (or similar),  Conditional support. This could be a useful property to query works by title similarity and such. ―BlaueBlüte (talk) 10:53, 30 January 2023 (UTC)

You know, this is basically mostly going to be non-referenced data which isn't good and as others pointed out could lead to bad data quality. Also, AIs should be able to do this type of inference reasonably well by now or later so really this sort of data is kinda useless. I also don't see many people using this property. For these reasons I'm withdrawing. Lectrician1 (talk) 19:18, 30 January 2023 (UTC)