Wikidata:Property proposal/abbreviation

non-acronym, non-initialism abbreviation edit

Originally proposed at Wikidata:Property proposal/Generic

Not done

Description	shortened form of word or phrase (i. e. shortened words in phrase), made by leaving some of letters and omitting others
Represents	abbreviation (Q102786)
Data type	Monolingual text
Domain	Automation of language templates like Template:Lang-en (Q6173452) and wikidata driven templates that use abbreviated forms of words (like vol., no. (issue), etc).
Allowed values	abbreviated text
Example 1	English (Q1860) → Eng. (English), англ. (Russian)
Example 2	volume (Q1238720) → vol. (English), т. (Russian)
Example 3	issue (Q28869365) → no. (English), вып. (Russian)
Example 4	Geneva (Q71) → Ж. (Russian)
Example 5	New York City (Q60) → N.Y. (English)
Example 6	east-southeast/ESE/E.S.E. (L750594) → E.S.E. (English)
Source	GOST R 7.0.12-2011 (in Russian), GOST 7.11-2004 (in Russian)
Planned use	for bibliographic entries in Wikipedia articles by Lua modules that format sources
See also	short name (P1813)

Motivation edit

I need it to abbreviate some words in different languages in the Wikidata driven language independent lua module that I created. The module fetches information about information source from Wikidata by its QID (or QIDS) and displays it according to the selected profile (currently only GOST is supported). I've tried to use short name, acronym, initialism, or abbreviation not unique (Q64699537) property, but my edits were reverted since it's a short form of a word or phrase but not an abbreviation. "English language" according to this property is "english" (Russian: английский) but not "eng." (Russian: англ.). Without the new property I cannot make my lua modules for citing purposes fully Wikidata driven. D6194c-1cc (talk) 16:38, 9 October 2022 (UTC)[reply]

Discussion edit

This should probably be a property of a lexeme, not an item, if we don't already have it? Lectrician1 (talk) 18:07, 10 October 2022 (UTC)[reply]
Probably I've chosen too wide context in my proposal. Currently I use those abbreviations in context of bibliography so they are topic-related. Ruwiki rules recommend to use GOST bibliography style which uses such abbreviations. So they could be different in another context. Should I rename this proposal to "Bibliography abbreviation"? D6194c-1cc (talk) 20:25, 10 October 2022 (UTC)[reply]
Also abbreviation context (e. g. bibliography) can be specified by qualifiers, but I do not know whether it is good idea or not. But if it is not related to a word but rather to a topic, then no context need to be specified like in issue (Q28869365), which is related only to periodical publications. D6194c-1cc (talk) 20:28, 10 October 2022 (UTC)[reply]

Is even entry in abbreviations table (P8703) not an option? This sounds like a problem with the users reverting your edits, who are definitely wrong here - a short name is an abbreviated name in most cases. In any case, I agree that this can be achieved with lexemes, if mainly because the people reverting your edits probably don't pay attention to them --عُثمان (talk) 07:53, 11 October 2022 (UTC)[reply]
Yes, it seems that entry in abbreviations table (P8703) is exactly what I need. Thanks! And it already supports different contexts. But why is its name so complicated ("entry in abbreviations table")? Why not just abbreviation? I tried to search that property in many ways but didn't find it. D6194c-1cc (talk) 16:41, 11 October 2022 (UTC)[reply]
Well, since abbreviations table must be part of a book, it will be used in a very narrow context, I can't use it if different languages. My idea was to create abbreviation property that could contain abbreviations for different languages in a specified context. In my case the context is bibliography. D6194c-1cc (talk) 16:06, 19 October 2022 (UTC)[reply]
I think it could be used in a broader context; for any referenceable work including bibliographies or any published table. It looks like aliases for abbreviation entry have been added to make it easier to find which is good. Often the description of a property can be more specific than it is intended for, this is something that could be adjusted. As we would need a reference to say that an abbreviation is used in bibliographies for example anyway, we could use this property to indicate a particularly notable or authorative source on bibliographic abbreviations for a language. I will try to find an example to do this with.

(Sorry for the late reply, I did not get notifications for these, maybe I need to change my settings for this.) عُثمان (talk) 16:13, 22 October 2022 (UTC)[reply]
I've already started using entry in abbreviations table (P8703) property in my lua module, and I still need more convenient way to do so. Currently I need to specify map (table) of entity ids by language in lua. Russian language has its own entity and other languages has another entities. I have chosen some good abbreviation sources. What I need is to specify a language for abbreviation entry and a context. I could probably reuse entry in abbreviations table (P8703) property without the creation of a new one, if I would have a way to specify context and language. Currently abbreviation table might have abbreviations in different languages (see [1]). So the type of value need to be monolingual text rather than just text. And another property must specify context, i. e. bibliography.

I think much easier would be to use abbreviation property as monolingual text with the context and information source rather than abbreviation table entry. D6194c-1cc (talk) 17:47, 22 October 2022 (UTC)[reply]
Well, I am stuck because entry in abbreviations table (P8703) is not a monolingual property (I can't filter it by language). It depends on the language of the abbreviation table, but GOST 7.11-2004 is multilingual. D6194c-1cc (talk) 16:40, 13 November 2022 (UTC)[reply]

I read some more about this property, it is related to abbreviations table, which is part of a book. Can it be used for a broader context? D6194c-1cc (talk) 16:52, 11 October 2022 (UTC)[reply]
Support mixing short labels and abbreviations together was a bad idea. Whenever there are cases where items should have both it's currently a mess. ChristianKl ❪✉❫ 20:47, 1 November 2022 (UTC)[reply]
Oppose I support this data model that utilizes Lexemes instead Wikidata:Property proposal/abbreviation of. Lectrician1 (talk) 16:50, 2 November 2022 (UTC)[reply]
- I don't think that would solve the proposer's use case, since we can't get things linking to an item using Lua, and I don't think lexemes are appropriate for all abbreviations (particularly for organisations, e.g. Grand Canyon University (Q4570025), Imperial College Boat Club (Q6006465), Huttwil-Eriswil railway line (Q1639332), Deutsches Skimuseum Planegg (Q76629100)). - Nikki (talk) 17:46, 2 November 2022 (UTC)[reply]
Why doesn't short name (P1813) work? Lectrician1 (talk) 18:47, 2 November 2022 (UTC)[reply]
@Lectrician1 The problem with short name (P1813) is that it mixes two different things together. If we take the example at the property page Orange County (Q5925) has two short names "Orange" and "OC". "United States" is a valid short name for "United States of America" as well that's distinct from the abbreviation. In some usecases you actually want to have "US" and not "United States" and want "OC" and not "Orange". A specialized abbrevation property would allow for this. ChristianKl ❪✉❫ 20:30, 2 November 2022 (UTC)[reply]
So you're saying we don't have a property for non-acronym abbreviations? Lectrician1 (talk) 20:44, 2 November 2022 (UTC)[reply]
I'm not sure what the best terms are to describe it but "Orange" and "OC" seem to me like entities that are different in the same way that "United States" and "US" are different and abbreviation seems to me like a fine name for the later. ChristianKl ❪✉❫ 13:43, 5 November 2022 (UTC)[reply]
@ChristianKl The only problem is that "New York" is technically an abbreviation for "New York City" so if the property is really mean to separate acronym abbreviations with non-acronym abbreviations, well then it should be named that way as "non-accronym abbreviation". That way we don't have people putting "New York" in this property and short name (P1813). Lectrician1 (talk) 17:58, 5 November 2022 (UTC)[reply]
But New York is not and abbreviation. It should be a short name. Non-acronym abbreviation for the New York would be N. Y. And acronym would be NY. Probably 3 different properties would be perfect solution, but currently short name (P1813) is a mix of short name, abbreviation and acronym. The property I proposed is non-acronym abbreviation. D6194c-1cc (talk) 09:49, 6 November 2022 (UTC)[reply]
@D6194c-1cc the question is whether everyone who reads "shortened form of word or phrase" understands that "New York" is no good value for "New York City". It's useful to think whether the description could be made more clear to reduce people misunderstanding the intent. ChristianKl ❪✉❫ 17:51, 7 November 2022 (UTC)[reply]
Well, dictionaries use New York City name as alias for New York and New York is the main name, so it is not the best example to discuss. If we consider Carl Sagan (Q410) as example, then shortened form would be Carl Sagan and he's full name is Carl Edward Sagan. Abbreviated form of his name would be C. Sagan or C. E. Sagan or Carl E. Sagan. D6194c-1cc (talk) 18:44, 7 November 2022 (UTC)[reply]

But New York is not and abbreviation.

"New York" is an abbreviation. See definition of abbreviation and difference between acronym here.

Non-acronym abbreviation for the New York would be N. Y. And acronym would be NY

Um no. "N. Y." is an acronym... Lectrician1 (talk) 20:39, 7 November 2022 (UTC)[reply]
An abbreviation is a short form of a word or phrase, made by leaving out some of the letters or by using only the first letter of each word.
The postal abbreviation for Kansas is KS.
—Collins dictionary

in American English:
3. a shortened form of a word or phrase, as N. Y. for New York, Mr. for Mister, lbfor pound, ctn for cotangent
—Collins dictionary
D6194c-1cc (talk) 22:00, 7 November 2022 (UTC)[reply]
a shortened form of a word or phrase.

still makes me think "New York" is a valid abbreviation for "New York City"

I don't think we're going to find our answer to whether shortened-non acronym phrases are considered abbreviations online, so I posted a Stack Exchange question. Lectrician1 (talk) 15:31, 9 November 2022 (UTC)[reply]
Since lexemes were mentions, I didn't find any possibility to use them. Lua module determines publication's language and its QID, then it looks up abbreviation (currently by entry in abbreviations table (P8703) property). It would probably work for many languages. Lexemes are language-dependent and in current realisation cannot be fetched from QIDs. I use wikidata entities as a simple translation method of a topic, but not a word. --D6194c-1cc (talk) 10:56, 11 November 2022 (UTC)[reply]

Oppose I just remembered my stance on properties that are monolingual text and my thought that we should totally use lexemes instead! Describing the relationship between a word or phrase and its abbreviation is entirely possible with derived from lexeme (P5191) and qualifier mode of derivation (P5886) abbreviation (Q102786). Linking it back to its definition can be done with item for this sense (P5137). Lectrician1 (talk) 17:06, 13 November 2022 (UTC)[reply]
Wikidata items doesn't have a property with a language-dependent list of lexemes from which items consist of. Moreover it needs language to be specified for every such a list. Proposing a new property for a list of lexemes is unsolvable problem at the moment. There is no data types that could hold an array of lexemes with specified language (monolingual lexeme array). Introducing such data type is a task for engine developers. Here is example for The Demon-Haunted World (Q2482106):
1. The Demon-Haunted World -> the (L2768), demon (L6550), haunted (L337269), world (L5203) (en).
2. Мир, полный демонов -> мир/міръ (L100000), полный демон (L144461).
3. ...
D6194c-1cc (talk) 19:25, 13 November 2022 (UTC)[reply]
That's why you run a SPARQL query to get the lexemes whose value for item for this sense (P5137) is the item. You don't need a property. Lectrician1 (talk) 23:47, 14 November 2022 (UTC)[reply]
The extension LinkedWiki (to run SPARQL queries) is probably not supported within Wikipedia. Lua modules can fetch Wikidata item and their properties values directly via mw.wikibase interface. Also retrieving data "from the back" would not be a good-performance solution. And item for this sense (P5137) is useless since mane Wikidata items have no associated lexemes. They consist from different lexemes, and the only way to specify lexemes for the item is array of arrays of lexemes. Every lexeme need to be abbreviated separately in case of lexemes, and this method doesn't cover context-specific abbreviations which probably can differ from context to context (see [2] for example). D6194c-1cc (talk) 07:10, 15 November 2022 (UTC)[reply]
The extension LinkedWiki (to run SPARQL queries) is probably not supported within Wikipedia. Lua modules can fetch Wikidata item and their properties values directly via mw.wikibase interface.

That's a Wikipedia problem then. That shouldn't impact how we model things on Wikidata.

Also retrieving data "from the back" would not be a good-performance solution.

Wikidata SPARQL Service handles thousands of queries every day. It can handle it.

And item for this sense (P5137) is useless since mane Wikidata items have no associated lexemes.

Well then you create lexemes for them.

They consist from different lexemes, and the only way to specify lexemes for the item is array of arrays of lexemes. Every lexeme need to be abbreviated separately in case of lexemes, and this method doesn't cover context-specific abbreviations which probably can differ from context to context

I don't understand this completely, can you elaborate? You can also create multiple abbreviation lexemes for the abbreviation of one lexeme. If you're concerned about using just one of them, then specify which one of them in your code. Lectrician1 (talk) 20:51, 15 November 2022 (UTC)[reply]
Support, but this should be allowed in lexemes as well. For example: east-southeast/ESE/E.S.E. (L750594). I'd like to be able to make a statement that E.S.E. and ESE are abbreviations of "east-southeast". (ESE is not an acronym because it is not pronounced as a word like Unesco is. See also https://www.merriam-webster.com/dictionary/ESE where ESE is labeled as an abbreviation.) As for New York being an abbreviation of New York City, um, no. The name of the city is New York, not New York City. New York City is just a commonly used name for the city to distinguish it from the state. New York is not the short name of New York City, New York City is a longer (or more accurately, variant) form of the City of New York. UWashPrincipalCataloger (talk) 23:50, 24 December 2022 (UTC)[reply]
Initialisms should also be excluded. Dictionaries use common term "abbreviation" for abbreviations, acronyms, and initialisms. I didn't find any that distinguish initialisms and acronyms from other abbreviations. Acronyms and initialisms should be in separate properties. D6194c-1cc (talk) 14:43, 25 December 2022 (UTC)[reply]
Oppose short name covers this with appropriate qualifiers if needed BrokenSegue (talk) 00:28, 31 January 2023 (UTC)[reply]
In that case short name could have 4 values for one language. The list will be huge. It doesn't make sense to combine short names, abbreviations, acronyms, and initialisms in single property. D6194c-1cc (talk) 10:12, 1 February 2023 (UTC)[reply]

Disagree Also, two different values with appropriate qualifiers might break some Wikipedia templates which don't expect multiple values for the same language. D6194c-1cc (talk) 13:47, 1 February 2023 (UTC)[reply]
Not done, no consensus of proposed property at this time based on the above discussion. Regards, ZI Jony ^(Talk) 05:59, 25 January 2024 (UTC)[reply]