Wikidata:Property proposal/Android application ID

Android application ID[edit]

Originally proposed at Wikidata:Property proposal/Generic

Not done

Description	identifier of an Android application
Represents	APK (Q596391)
Data type	String
Domain	mobile app (Q620615)
Allowed values	[a-zA-Z]\w(\.[a-zA-Z]\w)+
Example 1	Wikipedia (Q42119138) → org.wikipedia, org.wikipedia.beta, org.wikipedia.alpha
Example 2	Google Search (Q9366) → com.google.android.googlequicksearchbox
Example 3	TikTok (Q48938223) → com.zhiliaoapp.musically, com.ss.android.ugc.trill
Example 4	AdGuard (Q4033398) → com.adguard.android (not distributed on app stores, but available on the official website)
Source	https://developer.android.com/studio/build/configure-app-module#set-application-id
Expected completeness	always incomplete (Q21873886)
Implied notability	Wikidata property for an identifier that does not imply notability (Q62589320)
See also	Google Play Store app ID (P3418), F-Droid package (P3597), AppGallery app ID (P8940), Galaxy Store app ID (P10710), Bundle ID (P7429)
Distinct-values constraint	yes
Wikidata project	WikiProject Computer Science (Q6526225)

Motivation[edit]

There are many services distribute Android packages like Google Play, F-Droid, AppGallery or etc. However it is a little verbose adding the same value to each store's property. Also this property is useful for some apps that aren't published to app stores. Laftp0 (talk) 08:34, 7 October 2022 (UTC)[reply]

Here are formatters for some stores:

Discussion[edit]

wouldn't these be identical to in every android app store? -Loominade (talk) 10:49, 12 October 2022 (UTC)[reply]
I mean, why do we even have F-Droid package (P3597) and Google Play Store app ID (P3418) if they both contain the same id? -Loominade (talk) 10:53, 12 October 2022 (UTC)[reply]
Because these properties can be used to express that an app is available in a specific app store and these statements can easily be turned into links to the respective app stores. Just having a single "Android application ID" does not allow it to be reliably resolved to any app store, since you don't know in which app stores the app is available. Also note that apps sometimes have different identifiers in different app stores. --Push-f (talk) 06:17, 20 October 2022 (UTC)[reply]
You can define it via distributed by (P750) --★ → A ir on 90 15:48, 24 October 2022 (UTC)[reply]
Support BrokenSegue (talk) 03:50, 26 October 2022 (UTC)[reply]
Support --Dhx1 (talk) 13:56, 10 November 2022 (UTC)[reply]
WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
Oppose The motivation is not very convincing. Using the existing store-specific identifiers is certainly not unnecessarily verbose because it indicates in which store the app is available and the links are easily resolvable because the properties are external IDs with a formatter URL (P1630). While the proposed property could be qualified with distributed by (P750) such statements could not be as easily turned into links because formatter URL (P1630) cannot take qualifiers into account. I think it makes more sense to use store-specific properties. For apps not distributed via an app store an identifier is also quite useless ... in that case download URL (P4945) makes more sense. --Push-f (talk) 14:05, 10 November 2022 (UTC)[reply]
While I'm sympathetic towards having a store-neutral property for associating an app with an ID string (which I often see in my Android file system, without knowing which store I got the corresponding app from), this proposal needs more work to be useful. As Push-f points out, formatter URL (P1630) depends on obtaining its $1 parameter from the main value of the property it's attached to, and is thus different for each store.

I would suggest deferring this proposal until the problem described above is solved, or some other practical use of the identifier (that doesn't relate to stores) has been found. I'm not participating in the vote right now, however. SM5POR (talk) 16:07, 12 November 2022 (UTC)[reply]

It just strikes me how limited functionality the store-specific ID properties have. Each one has its own set of formatter URLs associated with the property itself, to be combined with an app-specific (but store-neutral) ID yielding pointers to different services, but yet this ID has to be specified individually for each store. I would have preferred a store-neutral main statement similar to catalog code (P528) (application ID) with all the stores or other registries using that ID listed as qualifiers (not distributed by (P750) but rather something like catalog (P972), identifying each store using an item instead of a unique per-store-property).

In the case of the same app being known by different identifiers at different stores, simply use two (or more) main statements as necessary, differing only by qualifier values (stores) listed.

In that way, you would be able to create items for new download stores, listings of support sites, user groups, associated software or data repositories etc without having to go through the formal process of property creation for each service using the same identifier as index key to its contents. SM5POR (talk) 16:13, 12 November 2022 (UTC)[reply]
Comment It should perhaps be noted that AppGallery app ID (P8940) does not use the Reverse domain name notation (Q7318226) but a numeric identifier, and there are so far very few Galaxy Store app ID (P10710) statements to consider for comparison. In some cases, the same store offers the same app under multiple identifiers, to distinguish between different country or language editions. There are maybe around 130 apps using different identifiers for different stores in a mutually exclusive manner. --SM5POR (talk) 14:50, 12 November 2022 (UTC)[reply]
By the way, why is this identifier property proposal limited to Android applications? The Reverse domain name notation (Q7318226) is used for identifiers also in other contexts such as Java libraries, Apple Uniform Type Identifier (Q2257511) and iOS apps (as indicated using Bundle ID (P7429)). If there is a registration authority (Q166140) defining the contents of this namespace (either in its entirety, or by delegation to sub-registries such as com.adobe or org.wikimedia), then that registry could be named in a catalog (P972) qualifier to the catalog code (P528) statement. SM5POR (talk) 16:20, 12 November 2022 (UTC)[reply]
@Loominade, SM5POR:, would you like to give your opinion? Regards, ZI Jony ^(Talk) 06:16, 25 January 2024 (UTC)[reply]
@ZI Jony:I barely remember even taking part in this discussion long ago, and much less what my key argumentswere, but thank you for notifying me. Could you please refresh my memory by pointing out explicitely which issue is still unresolved above, I have a hard time figuring it out myself, even as I reread my own words, and I imagine others may find it difficult too. As always, any communication is subject to the conditions of the recipient (in this case you). So please tell me, what do you want my opinion on? --SM5POR (talk) 10:52, 27 January 2024 (UTC)[reply]

* Support Extremely helpful, extremely constructive, and an extremely good property and property motivation for technology. Though, it is not for the all generic. Solaris5296 (talk) 00:44, 15 January 2024 (UTC)[reply]

Not done, no consensus of proposed property at this time based on the above discussion. Regards, ZI Jony ^(Talk) 13:06, 19 April 2024 (UTC)[reply]

Wikidata:Property proposal/Android application ID

Android application ID[edit]

Motivation[edit]

Discussion[edit]

Navigation menu

Search