Wikidata:Property proposal/software feature

From Wikidata
Jump to navigation Jump to search

has software feature[edit]

Originally proposed at Wikidata:Property proposal/Generic

   Withdrawn
DescriptionMISSING
Data typeItem
Domaininstance of software (Q7397) or appliance (Q1183543)
Allowed valuessoftware feature (Q4485156)
Example 1Google Search (Q9366) → autocomplete (Q749875)
Example 2Twitter (Q918) → mention (Q6817566)
Example 3www.openstreetmap.org (Q110251495) → private message (Q1844938)
Example 4iPod Shuffle 4G (Q114972466) → playlist (Q1569406)
See alsohas use (P366), introduced feature (P751), removed feature (P756), compatible with (P8956), supports programming language (P3985)

Motivation[edit]

Currently such relationships are mostly modeled in the reverse order with used by (P1535), e.g. mention (Q6817566)used by (P1535)GitHub (Q364). I would argue that this is semantically incorrect. A software feature is not used by the software but rather by the users of the software. A software has a feature so that users can use it.

has use (P366) is also sometimes used, e.g. Wikidata Query GUI (Q114902143)has use (P366)scatter plot (Q1045782). While that is better than uses (P2283) it's still a bit awkward. Yes a software that has a feature can be used for the feature but quite often features just improve the user experience (Q1047808) and are not the primary reason why you use a given service. Case in point Google Search (Q9366)has use (P366)autocomplete (Q749875) doesn't make sense: you use a search engine to find something not because you want to use autocompletion.

Also we already have properties to denote that a specific version of a software introduced or removed a feature (introduced feature (P751) & removed feature (P756)) so it only makes sense that we also have a property to denote the current features. Note that the proposed property could also be qualified like e.g. YouTube (Q866)has software featurenumber of dislikes (Q111633341)end time (P582)2021 November.

--Push-f (talk) 16:15, 28 October 2022 (UTC)[reply]

Discussion[edit]

While the label "software feature" probably applies to the vast majority of features to be listed using this property, I find the association with the software domain unnecessarily restrictive. How about calling it a "technical feature" instead, thereby covering also functionality implemented (in part or entirely) by other means than software, such as electric light (Q1326621) → dimmer (Q1162598), smartphone (Q22645) → GPS navigation device (Q1486497), photocopier (Q185369) → stapling (Q112805200), elevator (Q132911) → elevator music (Q1432201), or swimming pool (Q1501) → springboard (Q1543431)? Are there other properties to deal with the broader domain?

I suppose the new property would be a subproperty of has part(s) (P527), restricted to parts or functions that are optional in relation to the main purpose of the product or software item. Its use should be limited to physical devices incorporating the optional part, not extended to, say, "extras" provided with services or business practices.

Then I noticed that the (related) properties introduced feature (P751) and removed feature (P756) both seem to be mainly about software (looking at the examples given). Is that so, and would that somehow be a problem to extending the scope of your proposal to any kind of technical items? --SM5POR (talk) 08:23, 29 October 2022 (UTC)[reply]

Maybe some sloppy wording on my part there; by "physical devices incorporating the optional part" I mean to include also software or websites providing the optional functionality. In contrast, I do not include breakfast being served to hotel guests. SM5POR (talk) 08:42, 29 October 2022 (UTC)[reply]
I think for physical features has part(s) (P527) works just fine. For software it does not. Compare:
I think the first statement sounds fine but the second statement does not sound right. Mentions are surely part of the Twitter user experience but they're not necessarily a part of the Twitter service/software.
In the software domain "part" usually refers to software components and one software component can provide many features. I therefore don't think that the scope of my proposal should be broadened to physical features. --Push-f (talk) 09:14, 29 October 2022 (UTC)[reply]
I find myself convinced by your reasoning (esp. the distinction between the two properties with respect to software) and  Support your proposal as is while retracting my suggestion. Also, while sometimes (Q110143752) is a rather non-informative qualifier, it makes more sense to list features and parts of specific instances of physical items or software products, in which case has part(s) of the class (P2670) should be used rather than has part(s) (P527). In order to describe what software components result in what features (if you want that level of detail), has cause (P828) and/or has effect (P1542) could be used as qualifiers (say, YouTube (Q866)has software featuresubtitle (Q204028)has cause (P828)artificial neural network (Q192776) or something). SM5POR (talk) 12:21, 29 October 2022 (UTC)[reply]
  • @Push-f, SM5POR: I agree with SM5POR's initial comment about allowing the proposed property on non-software items but not the suggestion to make it a subproperty of has part(s) (P527). There is a difference between a part and a feature. For a car X, we could have Xhas featurecruise-control and Xhas partcruise control system, but not Xhas partcruise-control. (Another example is Xhas featurekeyless entry.) A feature is emergent from the parts of system but is not always a part itself. Sure, there are some parts that are also features, such as a sunroof or leather seats, but the sets of parts and features don't totally overlap.
— The Erinaceous One 🦔 08:51, 6 November 2022 (UTC)[reply]
  •  Comment I updated the proposed domain to also include instances of appliance (Q1183543) to allow for example iPod Shuffle 4G (Q114972466)has software featureplaylist (Q1569406). Because for many appliances we don't have dedicated data items for their firmware (and creating them would be kind of redundant since there often isn't much information about the firmware). --Push-f (talk) 09:17, 1 November 2022 (UTC)[reply]
  •  Oppose given lack of any description or analysis of how we will prevent hundreds of claims per item. ChristianKl ❪✉❫ 20:20, 1 November 2022 (UTC)[reply]
    WD:Notability applies as always. If a notable item indeed has hundreds of notable software features I do not see any reason why that should not be expressed in Wikidata. --Push-f (talk) 20:46, 1 November 2022 (UTC)[reply]
    To address Christian's concern I propose to use the constraint value requires statementdistinguishing feature for <software type> to only allow "meaningful" features, i.e. features you might want to query for. For example, you might want to query for "platform games that have a level editor" or "virtual keyboards with autocorrection". —Dexxor (talk) 07:57, 2 November 2022 (UTC)[reply]
    I do not think that introducing such restrictions makes sense because e.g. while copy (Q42282254) is probably not a distinguishing feature for text editors (since almost every text editor has that feature), we still want to be able to express statements such as vi (Q214743)has software featurecopy (Q42282254)object named as (P1932)yank.
  •  Comment The proposed name doesn't make it clear what the relation is. Is it <software>"has software feature"<a feature> or <feature>"software feature of"<software>. — The Erinaceous One 🦔 09:38, 2 November 2022 (UTC)[reply]
    Good point. I updated the proposed name accordingly. --Push-f (talk) 09:41, 2 November 2022 (UTC)[reply]
  •  Comment Why restrict this to only software features? I propose that we drop "software" from the label. This would allow its use on, say, cars or, in fact, any manufactured object. — The Erinaceous One 🦔 09:40, 2 November 2022 (UTC)[reply]
    The allowed values are very much intentionally restricted to instances of software feature (Q4485156) to avoid conflation/confusion between whether or not to use has part(s) (P527) or "has feature" for physical objects (see my discussion with SM5POR above).
    Note that "has software feature" can still be used with cars. A car can have a software feature. Yes technically it is the software of the car but I do not think that we want to create separate items for the firmware of every single device instance. Note that the proposed domain currently is "software (Q7397) or appliance (Q1183543)" and motor car (Q1420) is an instance of appliance (Q1183543) via the subclass of (P279) chain (motor vehicle (Q752870) → vehicle (Q42889) → machine (Q11019) → appliance (Q1183543)). --Push-f (talk) 10:43, 2 November 2022 (UTC)[reply]
    @Push-f: Thanks, I didn't see SM5POR's comment, before. I'll respond up there regarding making the property more general. It's worth noting, though, that including appliance (Q1183543) in the domain makes the domain quite broad. Among the subclasses are nozzle (Q250840), ramp (Q18003170), trap (Q665580), and potter's wheel (Q1128390). These all make sense for a has feature property but not for a has software feature property. — The Erinaceous One 🦔 08:28, 6 November 2022 (UTC)[reply]
    Yeah I know that appliance (Q1183543) is quite broad but we do not have an "appliances with software" class and even if we had it, it would be very difficult to draw the line because nowadays pretty much everything can have software. There could very much be a potter's wheel with voice control and Bluetooth. --Push-f (talk) 08:50, 6 November 2022 (UTC)[reply]
    I would say that's another reason to omit "software" from the proposed property label. — The Erinaceous One 🦔 09:54, 6 November 2022 (UTC)[reply]
    @The-erinaceous-one: I think there's a point in time where we need properties that are very specific for a purpose (e.g. "has software feature"). It is true that we could also use "has feature", but then that property could be perceived from different meanings and used for different purposes. The word "feature" has 5 definitions in Longman Dictionary [1] and 6 noun definitions in WordNet [2].
    I'd call the property "has feature" a "abstract property" or "generic property" because it is intended to be used in items from many classes. In my opinion, such properties are good for reducing the number of properties, but some of them also bring inconsistencies, because the domain in which they are used involve items in various fields and, therefore, creating accurate constraints, descriptions and labels require abstract reasoning.
    -- Rdrg109 (talk) 18:23, 4 November 2022 (UTC)[reply]
    I like your Xhas featurecruise-control example. I am however wary of using a generic label like "has feature" because "feature" can have many different meanings, as mentioned by Rdrg109 above, e.g. there are also facial features, e.g. should we also have Mickey Mouse (Q11934)has featurebig ears? I don't think so. Push-f (talk) 09:15, 6 November 2022 (UTC)[reply]
    Yes, you are right; using has feature would lead to a lot of different uses. We could partially prevent misuse by writing a clear description, but we all know that doesn't work all the time. I like your suggestion to use has technical feature' because it conveys that the property applies to features that are designed rather than natural. This would, arguably, exclude a few "features" such as leather seats in cars, but most interesting things like cruise-control, sunroofs, regenerative breaking, Android Carplay, would be included. — The Erinaceous One 🦔 09:53, 6 November 2022 (UTC)[reply]
    Besides clear descriptions, also consider the automated hints offered by carefully written mandatory constraints. SM5POR (talk) 10:38, 6 November 2022 (UTC)[reply]
    I agree about "feature" being a bit broad, especially when we go beyond software and discuss technology in general. How about "has function" or "has functionality"? This is to contrast "function" with "form"; while a protruding relief manufacturer's logo used as a decorative ornament could be a distinctive "feature" on the front of a car, it doesn't serve any technical function and thus wouldn't qualify here. Not sure about spoilers though, are they primarily added for aerodynamic or decorative purposes? I'd be happy to exclude them if there is any doubt about their function.
    I also agree that only distinctive functions should be mentioned, to avoid hundreds of statements. Every bicycle has breaks, no need to mention that. Same with a transponder in an airplane. But put a transponder on a bike, now that's distinctive! Of course, "property sometimes changes" as technology evolves; 40 years ago I didn't imagine I would eventually have satellite navigation on my bicycle... SM5POR (talk) 10:30, 6 November 2022 (UTC)[reply]
    Not every bicycle has breaks. Some fixed gear bikes don't have brakes.
    I like "has function". Could we have a constraint to prevent it from being accidentally misused for statements such as C standard library (Q300914)has functionputc (Q11240116)? Push-f (talk) 10:54, 6 November 2022 (UTC)[reply]
    When I say "every bicycle", I'm not talking in absolute terms, I'm talking about "typically", what's considered "normal". See does not have part (P3113) for a property to use when something otherwise expected is actually missing (especially the discussion leading up to its creation). When more than half of all bicycles have transponders, it's time to stop treating those transponders as distinctive for a bicycle.
    I haven't experimented with constraints a lot, but I imagine it might be possible to state that a claim Ahas functionX cannot coexist with, say, the claims Asubclass of (P279)B, Xsubclass of (P279)Y, Bmodel item (P5869)C, and Chas functionY. Or am I just way too optimistic now? SM5POR (talk) 11:58, 6 November 2022 (UTC)[reply]
    Changing the proposed property to "has function" would significantly change the meaning of it. The most relevant definition of "function" in Merriam-Webster is "the action for which a person or thing is specially fitted or used or for which a thing exists." So "has function" would model the essential actions of a item (carhas functiontransport), but not peripheral aspects (car Xhas functionsun roof doesn't make sense). Also note that the subject of "has function" makes most sense to be a verb whereas the subject of "has feature" would be a noun.
    Using has function as a label is also more prone to a lot of misuse. I've been monitoring instances of function (Q11348) and people frequently confuse it with position (Q4164871) — The Erinaceous One 🦔 22:16, 6 November 2022 (UTC)[reply]
    I no longer think that Xhas featurecruise control & Xhas partcruise control system is a good example because cruise control (Q507295) is defined to be a system (by Wikipedia as well as Wikidata).
    In general I think that "has feature" would overlap too much with "has part" because many parts are also a feature, and I see very little sense in creating separate data items for hundreds of parts/features when there is a 1:1 mapping and no distinction made by Wikipedia or the literature. So I think has part(s) (P527) works fine for cruise control, power steering, sun roof etc.
    I do agree that "has function" would very much overlap with has use (P366) semantically. I am starting to think that has use (P366) should be relabeled to "has main use" to match its description ("main use of the subject") and to introduce two new properties "has secondary function" and "does not have secondary function".
    Ad conflation with position (Q4164871): I think that would be reduced by the "secondary" in there, but for properties we also have better means of addressing accidental misuse via property constraints.
    I am gonna go ahead and write a new proposal ... I'd like to thank everybody for participating in the discussion here ... it has been incredibly insightful, and I think I can write a much better proposal now :)
    --Push-f (talk) 06:01, 7 November 2022 (UTC)[reply]
  •  Support big thanks for this proposal. I see others have already raised a few concerns and after reading the comments I see they have all been adressed to my satisfaction 😀So9q (talk) 07:16, 7 November 2022 (UTC)[reply]
  •  Withdrawn I withdraw this proposal in favor of my new proposal for a "has subfunction" property, addressing the justified concerns that the property should not be restricted to the software domain. --Push-f (talk) 08:22, 7 November 2022 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/software_feature&oldid=1767033146"