Wikidata:Property proposal/subfunction

has subfunction edit

Originally proposed at Wikidata:Property proposal/Generic

   Not done
Descriptionsubsidiary function of the subject (includes current and former functions). Only use this property if the function is distinguishing for instances of the parent class or you want to add further information about the statement via a qualifier.
Data typeItem
Domaininstances (items with instance of (P31) that do not have subclass of (P279))
Example 1iPod Shuffle 4G (Q114972466)has subfunctionplaylist (Q1569406)
Example 2vi (Q214743)has subfunctioncopy (Q42282254)object named as (P1932)yank
Example 3X (Q918)has subfunctionmention (Q6817566)start time (P580)May 2008
Example 4X (Q918)has subfunctionRSS (Q45432)end time (P582)March 5, 2013
See alsohas use (P366), has part(s) (P527)

does not have subfunction edit

Originally proposed at Wikidata:Property proposal/Generic

   Not done
Descriptionexpected subsidiary function that the item does not have and never had (for subfunctions that were removed use "has subfunction" qualified with end time (P582) instead)
Data typeItem
Domaininstances (items with instance of (P31) that do not have subclass of (P279))
Example 1iPod Shuffle 4G (Q114972466)does not have subfunctionfast forward (Q5437034)
Example 2vi (Q214743)does not have subfunctionredo (Q42282532)
Example 3YouTube (Q866)does not have subfunctiondownload (Q7126717)
See alsodoes not have part (P3113)

See #has subfunction for the motivation and discussion.

Motivation edit

We have has use (P366) to express the "main use of the subject". We currently however do not have a property to express a secondary use of a subject. The current lack of a fitting property leads to the misuse of various other properties, e.g:

I therefore propose to introduce two new properties "has subfunction" and "does not have subfunction" as described in this and the following section.

Please note that "has subfunction" should only be used in two cases:

  • 1) the subfunction is distinguishing for instances of the parent class, or
  • 2) further information about the statement is provided via a qualifier

To illustrate this with examples:

This restriction to distinguishing functions is intended to avoid the creation of hundreds of statements per item that do not really express anything interesting.

Please also note that like has use (P366) the proposed property "has subfunction" also includes former functions via the end time (P582) qualifier, for example:

Note that in such a case you should NOT additionally add a "does not have subfunction" statement with the same object. Instead the proposed #does not have subfunction property is solely intended to be used for functions that have never been present (but are likely to be expected from instances of the class). For example:

This proposal replaces my previous proposal to introduce a "has software feature" property because it has been rightfully argued that the property should not be restricted to software features.

--Push-f (talk) 08:27, 7 November 2022 (UTC)[reply]

Discussion edit

  Comment I don't see how your proposal addresses the Wikidata Query GUI (Q114902143) statements. The values listed aren't either primary or secondary "uses", they are output formats (or methods). The property therefore shouldn't be has use (P366) but either writable file format (P1073) (if the file format, or family of formats, is sufficiently well specified) or output device (P5196) (if the output is described in more general terms, such as table (Q496946)).

Maybe specify both, with the file format as a qualifier?

Wikidata Query GUI (Q114902143)output device (P5196)table (Q496946)writable file format (P1073)comma-separated values (Q935809)

That will however require adding "as qualifier" to the property scope constraint of writable file format (P1073).

Since all the usage examples for output device (P5196) seem to be about VR headsets, you may get the impression that it's about hardware only, but the value of that property isn't constrained to any particular type, and one of the more common values is computer file (Q82753). --SM5POR (talk) 11:13, 7 November 2022 (UTC)[reply]

I have expanded the scope of writable file format (P1073) to include use as a qualifier, as per my own suggestion above. SM5POR (talk) 14:46, 7 November 2022 (UTC)[reply]
Moment, I misread the statistics and there is apparently only one case of the output device (P5196) value being a computer file. Still I don't see why this property should be restricted to hardware devices, especially as a "method" isn't necessarily hardware, and two other values I found are "standard output" and "desktop environment" (but there is also "computer monitor" which hints at different notions being adopted by different editors).
If the application itself doesn't have a hardware interface, but interacts via a data stream, what purpose would output device (P5196) serve being applied to that application? SM5POR (talk) 15:57, 7 November 2022 (UTC)[reply]
I disagree with scatter plot (Q1045782) or map (Q4006) being output methods of Wikidata Query GUI (Q114902143) because you cannot actually download the plot or the map. These are rather what I'd call "display formats". WDQS calls them result views ... note that most of these allow for some interactivity, so I think "has subfunction" would actually work fine for them.
Please note that the downloadable formats are very much independent from the result views, so I'd object to Wikidata Query GUI (Q114902143)output device (P5196)table (Q496946)writable file format (P1073)comma-separated values (Q935809) and instead just state Wikidata Query GUI (Q114902143)writable file format (P1073)comma-separated values (Q935809).
--Push-f (talk) 09:00, 8 November 2022 (UTC)[reply]
As I understand output device (P5196), it's intended for "output devices and user interfaces". It has no value constraints, so that tells us nothing about the intentions, but the corresponding input device (P479) property has these alternatives listed in its value constraints, and I guess the two properties are meant to cover essentially the same domains (of course, hardware devices are often unidirectional and will then be limited to only one of the properties).
I don't see that output device (P5196) is in any way limited to either downloadable or on-screen data, but the precise interface mode could well be described using appropriate qualifiers. The reason I suggest grouping them under output device (P5196) is that an application may have multiple input and output streams or interfaces (in hardware or software), and simply listing all the encodings, file formats, languages and connectors as main statements on the application item will tell us nothing about which interface parameters pertain to the same data.
That is however another discussion which we can continue elsewhere. To address your suggestion to use "has subfunction", I understand that as being a much broader property, that includes not only user interfaces, input and output, but also internal things like calculations, security features, whatever. The I/O-related qualifiers will be rather useless (or perhaps ambiguous) when attached to an arbitrary "has subfunction" statement. And as the general recommendation on Wikidata is to use the most specific property available, I guess that output device (P5196) will "win" every time over "has subfunction" for anything output-related. SM5POR (talk) 19:32, 8 November 2022 (UTC)[reply]

  Comment To me, a "secondary use" is something you use for a particular purpose when you do not use it for its primary purpose, say, using old newspaper sheets to wrap around flowers. Do people actually use Twitter to access the "mention" function without tweeting anything at all?

But I agree that used by (P1535) is a poor fit for that feature/application relation. Are you sure part of (P361) wouldn't satisfy this particular need, at least in the interim until we find a similar situation that may inspire to a better idea? --SM5POR (talk) 11:53, 7 November 2022 (UTC)[reply]

To be honest I am not so sure about the label. "function" is certainly less ambiguous than "feature" and also does not have such a problematic overlap with "has part". And yes I am sure that has part(s) (P527) is unsuited in the software domain because I'd expect it to be used for software components, which certainly do not need to correspond to functions or features.
Using a thing for a purpose it was not intended for rather falls under "creative reuse" for me. I'd consider "secondary function" simply an intended function that is not the primary function. So yes you are unlikely to use something just for a secondary function because you are likely to use it for its primary function. An alternative label for "secondary function" could be "side function". --Push-f (talk) 18:10, 7 November 2022 (UTC)[reply]
I have updated the proposed property label from "has secondary function" to "has subfunction". Wiktionary defines subfunction as "A secondary or subsidiary function." I think subfunction is a better term because it suggests that there can be multiple subfunctions and that these subfunctions together aid/form the main function. --Push-f (talk) 01:58, 8 November 2022 (UTC)[reply]
I agree that "subfunction" is a better term than "secondary function" if you intend to describe a function that is part of a broader application but just implements a minor detail of it, such as mentions in a social forum; as you say, they aid the main function. Still I don't think it's necessary to relabel "has use" to "has main use", since most uses that don't qualify as "main uses" will hardly satisfy the notability criterion either. Would you bother to add newspaperhas side useflower wrapping or rockhas side usedoor stop to Wikidata? There may me exceptions, such as highwayhas side usefighter plane take-off and landing strip, but they will be greatly outnumbered by instances of "has use", and I would rather qualify that as highwayhas usefighter plane take-off and landing stripnature of statementsometimes. SM5POR (talk) 06:22, 8 November 2022 (UTC)[reply]
Good point, I have removed the suggestion to rename has use (P366) from my proposal. --Push-f (talk) 07:45, 8 November 2022 (UTC)[reply]
I'm confused by your many labels here, especially as you have just changed the label of this proposal from "has secondary function" to "has subfunction". Do you regard "secondary/side function" as synonymous to "creative reuse" or to "subfunction"? In my comment above I assumed the former, but if you don't interpret the words the same as I do, it may seem nonsensical... Anyway, if we are talking either flower wrapping or wartime airplane runways, I'd regard both as "creative reuses" or simply "side uses", and if I'm a florist or a fighter pilot, I'm actually quite unlikely to also read those newspapers or drive a car on that highway, respectively. Not sure if this is what you referred to, though. SM5POR (talk) 06:41, 8 November 2022 (UTC)[reply]
I'm sorry about the confusion caused by the renaming. You assumed correctly, though I do not regard them as synonymous just as overlapping. I understand how "secondary use" could be easily understood as "creative reuse", which is not what I intended ... but I think my renaming to "subfunction" solves this source of confusion ... thanks for pointing it out :) --Push-f (talk) 07:50, 8 November 2022 (UTC)[reply]
I actually think that making a "has feature" property would be a lot more useful and clear than a "subfunction" feature. "Subfunction" also has some mathematical and computer programming meanings that will make the current label confusing. — The Erinaceous One 🦔 06:42, 9 November 2022 (UTC)[reply]
I think "has feature" would be too easily confused with "has part", e.g. swimming pool (Q1501)has featurespringboard (Q1543431). And "feature" has many different meanings as well ... from cliff features, to facial features to pool features. Look at the Merriam-Webster entry ... it's way too ambiguous e.g. "a prominent part or characteristic". --Push-f (talk) 08:16, 9 November 2022 (UTC)[reply]
There is definitely an overlap with "has part" but I don't think that is a problem. A part can be a feature but doesn't have to be and feature can be a part but that is not necessarily. It seems like we are moving away from what we were initially trying to model (software features) and in doing so losing much of the clarity and utility of the proposed properties.
Regarding the multiple meanings of the word "feature", what if we use either "has product feature" (or "has technical feature")? That would remove the ambiguity regarding the other meanings of "feature" and make it clear that it only refers to man-made things. — The Erinaceous One 🦔 09:11, 9 November 2022 (UTC)[reply]
Open source software is generally not referred to as "product". And "technical feature" still has the same problematic overlap with "has part" because "feature" can mean "part" or "characteristic" e.g. iPod Shuffle 4G (Q114972466)has technical featureheadphone jack (Q114973405) ... that's a true statement but could just as well be modeled with has part(s) (P527). "has technical feature" could even be misused for the main use e.g. iPod Shuffle 4G (Q114972466)has technical featureplayback (Q115114207), which would also be a true statement but should be modeled with has use (P366) instead.
I really think that "subfunction" is vastly clearer. "has feature" should certainly be an alias to aid in the property discovery but it's unsuited to be the label (with or without the "technical" prefix).
--Push-f (talk) 04:44, 10 November 2022 (UTC)[reply]
  •   Weak oppose Idea is okay, but name is just not right. There is a well established term for what's being talked about. It's "feature". So "has feature" (or "has technical feature" if you want to be more specific) seems incredibly more intuitive than "subfunction", which implies a connection to a "has function" property, which does not exist, and this property is more distinct from "has use" than "has subfunction" implies. Circeus (talk) 16:56, 17 June 2023 (UTC)[reply]
    Agree, "has feature" would be a much more fitting name. Binarycat32 (talk) 22:39, 17 January 2024 (UTC)[reply]
  •   Not done, no consensus of proposed property at this time based on the above discussion. Regards, ZI Jony (Talk) 06:27, 25 January 2024 (UTC)[reply]