Wikidata

Wikidata:Property proposal/not compatible with

< Wikidata:Property proposal

not compatible with

edit

Originally proposed at Wikidata:Property proposal/Generic

   Not done
Descriptionthis work, product, object or standard cannot interact with another work, product, object or standard
Data typeItem
Domainitem
Example 1s-boot 4.0 for the GT-I9300 (Q110800808) (The bootloader shipped on the GT-I9300 (Q83637336) ) is incompatible with the Linux kernel (Q14579) (reference: https://redmine.replicant.us/projects/replicant/wiki/BootloadersIncompatibleWithLinux#Devices-with-the-Exynos-4412, https://www.openwall.com/lists/kernel-hardening/2019/06/14/9)
Example 2Inside Replicant (Q7314062), inside software version identifier (P348) (to track when support for GT-N5110 (Q86248315) was added):
Example 3For listing incompatibility with UEFI secure boot:
  • GNU Guix System (Q19597382) <incompatible with> Secure Boot (Q28669307)
  • In Parabola GNU/Linux-libre (Q3308694) <incompatible with> Secure Boot (Q28669307)
  • In Trisquel (Q1588573) in software version identifier (P348) in "10.0" <incompatible with> Secure Boot (Q28669307)
    • Example 4GT-N5110 (Q86248315) (or the WiFi chip it use, to be added in has part(s) (P527)) <incompatible with> IEEE 802.11ac (Q1188495)
    Example 5Core2 Duo P8600 (Q51963118) <incompatible with> <Entry about vt-d (to be added)>
    Example 6Core2 Duo P8600 (Q51963118) <incompatible with> Advanced Vector Extensions (Q17600)
    Planned useDocumenting nonfree bootloaders incompatibilities: we can already tell a that Linux kernel (Q14579) has some support for the GT-I9300 (Q83637336) through the exynos4412-i9300.dts (Q90612899) device tree (Q16960371) but we can't tell that the stock bootloader can't boot Linux because it's incompatible with it. Since it's not up to Linux to fix it, and that that bootloader can only be fixed by Samsung (it can't be modified by users as it is signed) and that's extremely unlikely to happen (the Galaxy SIII is not sold new anymore since many years now) we need a way to express the incompatibility to avoid users of Wikidata be misslead into thinking that one can simply boot an official Linux kernel and expect it to work on that smartphone.
    Expected completenesseventually complete (Q21873974)
    See alsocompatible with (P8956), platform (P400), operating system (P306), readable file format (P1072), writable file format (P1073), intended public (P2360)

    Motivation

    edit

    I already started documenting hardware and software compatibilities with compatible with (P8956), but we also need the opposite property (not compatible with) to handle some problematic situations.

    For instance there is some support for the GT-I9300 (Q83637336) in the Linux kernel (Q14579) through the exynos4412-i9300.dts (Q90612899) and various drivers to support its hardware, but users can't boot the Linux kernel (Q14579) on that smartphone.

    This is because this smartphone is shipped with a bootloader (Q836795) that is incompatible with the Linux kernel (Q14579). And this bootloader can't be modified by users because the GT-I9300 (Q83637336) only runs software signed by Samsung at boot. So if users were to modify that bootloader, this device won't boot. And the Linux kernel (Q14579) can't accept patches to add support for this bootloader because ARM bootloaders are expected to be compatible with a booting standards and this one isn't.

    More generally it could be used to express incompatibilities that can't be fixed, for instance some hardware chip that is incompatible with a protocol, or for cases where users would expect hardware or software to be compatible with other hardware and software but where it is not compatible (due to hardware limitations for instance).

    GNUtoo (talk) 08:45, 3 February 2022 (UTC)[reply]

    Discussion

    edit

      Oppose @GNUtoo I'm doubting the notability of bootloaders on Wikidata. If you add non-bootloader examples I may reconsider. Lectrician1 (talk) 02:36, 13 December 2022 (UTC)[reply]

    More broadly it also allows to track when compatibility stops in a given project. For instance if Linux removes support for a driver, an architecture, or that GCC removes the support for CGJ, etc, then you can track that with "not compatible with" and a specific version of the software. It also works with nonfree software when for instance Firedox drops the support for Windows XP, etc. GNUtoo (talk) 23:43, 2 January 2023 (UTC)[reply]
    It can also track what a given project chose not to implement for a reason or another. For instance it could track a free software TPM implementation that is not compatible with the TPM standard because it lacks an update mechanism. It could track TLS libraries that refused to implement some older standards for security reasons, or software not compatible with Wayland or Xorg, or even nonfree software that broke compatibility on purpose to do some vendor locking. GNUtoo (talk) 17:22, 3 January 2023 (UTC)[reply]
    @GNUtoo Like I said, if you add non-bootloader examples to show these relationships you are describing actually exist, I may reconsider. Lectrician1 (talk) 21:18, 4 January 2023 (UTC)[reply]
    I didn't understand that I could modify the proposal above. I've now done that. GNUtoo (talk) 01:16, 18 January 2023 (UTC)[reply]

    Okay, so first concern is: where do we draw the line as to when we should add "incompatible with"? If there is no line, then you open the possibility to people adding "incompatible with" to every tech item out there with every standard. We don't need that data bloat...

    It looks like Advanced Vector Extensions (Q17600) was available only on Sandy Lake processors and onward. It's probably best to then just add compatible with (P8956) to all the processors that are compatible with it and not add it to the ones that are not. Lectrician1 (talk) 18:14, 19 January 2023 (UTC)[reply]

    For the first concern, if I remember well, what was decided for compatible-with was to try to avoid having too much statements on a page as much as possible. So for instance privileging many to one relationship instead of one to many. There might also be other ways as well to limit that, though I need to think about it. GNUtoo (talk) 12:59, 24 January 2023 (UTC)[reply]
    As for Advanced Vector Extensions (Q17600) the issue is how to encode the information inside the Wikidata. If there isn't any information it could be that either the processor doesn't support Advanced Vector Extensions (Q17600) or that nobody mentioned that it supports Advanced Vector Extensions (Q17600). In that case the statement could be broader, like it could apply to Intel Core 2 Duo (Q4036548) for instance. Another question here would be if it's the right property to mention the lack of support of a given instruction set (P1068) or not. For instance maybe some <does-not-support-instruction set> Advanced Vector Extensions (Q17600) would be better for this case? GNUtoo (talk) 12:59, 24 January 2023 (UTC)[reply]
    @GNUtoo
    If there isn't any information it could be that either the processor doesn't support Advanced Vector Extensions (Q17600) or that nobody mentioned that it supports Advanced Vector Extensions (Q17600).
    If an item does does not have a statement, then one should assume that such a statement should not apply to it. We can't have a Wikidata where everything an item does not have is documented. That would be insane. If you want to say that "all the data about a topic is correct and complete" well then add that data. If a processor supports AVE, then say it does. If it doesn't, then don't.
    In that case the statement could be broader, like it could apply to Core 2 Duo (Q4036548) for instance.
    Maybe, but Intel Core 2 Duo (Q4036548) is conflated right now. It looks like it is acting as both a series of processors and a class of processors. Clearly the processor data model isn't sorted out. Until it is by some WikiProject, that's when we can answer whether it "compatible with" should be placed on individual processors or classes of processors.
    For instance maybe some <does-not-support-instruction set> Advanced Vector Extensions (Q17600) would be better for this case?
    For the same reasoning above as to why we shouldn't have "does not have" properties, we shouldn't have this either. Lectrician1 (talk) 17:21, 24 January 2023 (UTC)[reply]
    As I understand, it really depends on the context. There are cases where people would assume compatibility. For instance if an RAM controller or a computer is compatible with DDR3 RAM modules, but that certain DDR3 modules are known not to work (it's the case with the ThinkPad X200 (Q51954707) for instance where the RAM modules need to have chips with of maximum 256MiB on it), it makes more sense to list what is not compatible rather than what is compatible because it makes no sense to list a huge number of RAM module when very few are not compatible. Often there are also quirks in hardware where things are supposed to be compatible but they are not because the standard wasn't respected (usually to lower costs, but sometimes for other reasons like with my TPM example). The context here is important too, because for instance for USB hubs, most manufacturers don't respect the standard, so here it would make sense to use compatible with to map if an USB hub can power off a port. GNUtoo (talk) 16:57, 27 January 2023 (UTC) edit1: Fix typo GNUtoo (talk) 17:03, 27 January 2023 (UTC)[reply]

      Oppose too many possible values BrokenSegue (talk) 00:16, 31 January 2023 (UTC)[reply]

    Note that the "too many possible values" is already the case for compatible with (P8956), yet compatible with (P8956) was accepted knowing that with the assumption that people will be reasonable with the usage of such properties and prefer many to one instead of one to many. GNUtoo (talk) 00:51, 8 February 2023 (UTC)[reply]
    •   Support. There is another good example for applying this property. It would be useful for modeling video games that are not compatible with Steam Deck (Q107542665). The use of the platform (P400) property is not appropriate here, but this property, on the contrary, is just perfect!
    Examples:
    Cyberpunk 2077 (Q3182559)
    compatible with
      Steam Deck edit
    has characteristic verified


    add value
    and
    The Last of Us Part I (Q113377532)
    not compatible with
      Steam Deck (Q107542665) edit
    has characteristic unsupported


    add value
    Regards Kirilloparma (talk) 02:48, 25 April 2023 (UTC)[reply]
    Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/not_compatible_with&oldid=1906335549"