Wikidata:Property proposal/Compatible with

compatible with[edit]

Originally proposed at Wikidata:Property proposal/Generic

Done: compatible with (P8956) (Talk and documentation)

Description	this work, product, object or standard can interact with another work, product, object or standard
Data type	Item
Domain	item
Example 1	Replicant (Q7314062) → GT-I9300 (Q83637336) (Replicant only supports about 10 devices, if it starts supporting too much devices, this would have to be inversed (device compatible with Replicant))
Example 2	libreboot (Q20085696) → ThinkPad X200 (Q51954707) (Libreboot supports only very few devices)
Example 3	exynos4412-i9300.dts (Q90612899) (which has published in (P1433) Linux kernel (Q14579)) → GT-I9300 (Q83637336) (Linux is compatible with a lot of ARM computers, but each ARM computer is compatible with very few operating systems (typically only GNU/Linux))
Example 4	sigrok (Q14589876) → IEEE-488 (Q1135192) (Sigrok is compatible with a few standards, but standards like GPIB could be compatible with too much devices and software)
Example 5	Linux kernel (Q14579) → Serial ATA (Q188639) (Linux is compatible with a few standards, but standards can be compatible with many OS / software)
Example 6	Linux kernel (Q14579) → Advanced Host Controller Interface (Q379598) (Linux is compatible with a few standards, but standards can be compatible with many OS / software)
Example 7	Linux kernel (Q14579) → Advanced Configuration and Power Interface (Q379523) (Linux is compatible with a few standards, but standards can be compatible with many OS / software)
Example 8	Linux kernel (Q14579) → Internet protocol suite (Q81414) (Linux is compatible with a few standards, but standards can be compatible with many OS / software)
Example 9	GNU Compiler Collection (Q178940) → C++11 (Q1061570) (GCC is compatible with a few standards, but standards can be compatible with many OS / software)
Example 10	GeForce 900 series (Q16927918) → nouveau (Q310474) ("Many GPUs" "part of" "GPU family" "compatible with" "Driver", so we have very few driver ~10 or 20 that points to 1 kernel or very few kernels (many to one))
Planned use	Convert the Replicant, Libreboot and libsamsung-ipc to use that property. Add dts for devices supported by Replicant, and retrieve it in a tool.
Expected completeness	eventually complete (Q21873974)
See also	platform (P400), operating system (P306), readable file format (P1072), writable file format (P1073), intended public (P2360)

Motivation[edit]

The idea is to have the ability to describe when hardware, software, protocols, etc are compatible with each other.

For instance if I want to tell that the GT-I9300 (Q83637336) variant of the Samsung Galaxy SIII Replicant 6.0 0003 or vice versa I could use such property.

It is different from the platform (P400) property as a given program might be compatible with different platforms (GNU/Linux, Various Microsoft Windows versions, FreeBSD, etc) and uses libusb to interact with various hardware it's compatible with.

sigrok (Q14589876) runs on GNU/Linux, Mac OSX, Windows, FreeBSD, OpenBSD, NetBSD, Android and supports several oscilloscopes and logic analyzers. The OS it runs on can be expressed by the platform (P400) property but the hardware it supports cannot.

libsamsung-ipc (Q83639531) is a library that runs on Android and GNU/Linux which supports several modems of several smartphones which use the samsung-ipc protocol. The modems cannot be described as platform either.

In some cases qualifiers will have to be used to give more context to this "Compatible with" property:

The compatible software might run on the device itself or on a host computer to interact with the device:
- The Talos II mainboard has a BMC (Baseboard Management Controller) which runs GNU/Linux on its ARM processor(s) while GNU/Linux also runs on the main CPU which uses the PowerPC architecture. So here we need to know, for a given software, if it runs on the BMC and supports the BMC hardware that way, or if it runs on the host processor and supports the BMC by talking to it.
- Some modems have GNU/Linux in some of their cores. The Quectel Osmocom project wiki has some more details on them. As a result you have software support for the modem protocol in Linux for the host and in userspace drivers in stacks like Ofono, but also for the modem SOC where the code is supposed to run on the modem itself. There is even upstream Linux support for the later.
In case of protocol the compatibility could be at different levels. For instance you could be compatible with USB interface, or the USB mass storage, but then both have different standards or part of the standard that describe that. – The preceding unsigned comment was added by GNUtoo (talk • contribs).

Discussion[edit]

Support Seems useful. 轻语者 (talk) 00:29, 1 May 2020 (UTC)[reply]
Comment We should use symmetric constraint (Q21510862) for this property. --Tinker Bell ★ ♥ 01:40, 2 May 2020 (UTC)[reply]

Should I change it in this proposal, or do I need to wait for more comments before submitting a new proposal? GNUtoo (talk) 19:37, 3 May 2020 (UTC)[reply]

@GNUtoo: No, this means that, for example, if Replicant (Q7314062)<compatible with>GT-I9300 (Q83637336), then GT-I9300 (Q83637336)<compatible with>Replicant (Q7314062). If the property is created, this will be marked in the property as <property>property constraint (P2302)symmetric constraint (Q21510862). --Tinker Bell ★ ♥ 03:52, 11 May 2020 (UTC)[reply]

Comment the scope seems a bit vague, e.g. wouldn't the items for Linus and Windows end up linking to almost anything? --- Jura 14:42, 12 May 2020 (UTC)[reply]

It could in theory, however I don't see this as an issue, as people still need to follow common sense, and to link what is noteworthy and/or useful. For now there is also operating system (P306) for just being compatible with a specific operating system like Android, GNU/Linux or Windows. platform (P400) can also be used for platforms like Gaming consoles. However I don't see how to express how a given driver (which can run on multiple operating systems for instance) could be compatible with a given hardware component, hence the need for a more generic property. GNUtoo (talk) 20:00, 12 May 2020 (UTC)[reply]

The fact that the property (will) use by design a symmetric constraint (Q21510862) also enables people to only link things one way: If a given driver supports way to many devices and that it's actually useful to tell that a device is supported by this driver, you could simply link things on the device element page and not on the driver page. GNUtoo (talk) 20:04, 12 May 2020 (UTC)[reply]

Personally, I think a symmetric constraint makes things even worse. Would the OS property be sufficient? --- Jura 05:25, 14 May 2020 (UTC)[reply]

Using operating system (P306) doesn't work: You cannot tell that a specific oscilloscope is compatible with sigrok (Q14589876) because sigrok (Q14589876) isn't an operating system. You also cannot tell that exynos4412-i9300.dts (Q90612899) is compatible with GT-I9300 (Q83637336) because exynos4412-i9300.dts (Q90612899) isn't an operating system either. This is precisely why I proposed this property: because after looking for hours and hours I found no way to express things like that. sigrok (Q14589876) and IEEE-488 (Q1135192) are not platform either. readable file format (P1072) and writable file format (P1073) don't work either for sigrok (Q14589876) and IEEE-488 (Q1135192) as none are file. And abusing intended public (P2360) as compatible be really missleading as hardware or protocol aren't people. GNUtoo (talk) 02:39, 15 May 2020 (UTC)[reply]

@GNUtoo: I removed the pings to nonexistent projects as the just clutter the discussion with a lot of error messages. ChristianKl ❪✉❫ 22:03, 11 June 2020 (UTC)[reply]

Thanks GNUtoo (talk) 20:58, 20 June 2020 (UTC)[reply]

Comment The completeness seems highly unrealistic. Always incomplete is the likely case. Ainali (talk) 21:12, 29 July 2020 (UTC)[reply]

That would work for me too. I'm unsure what completeness means exactly. As I understood it, in some cases a given software could explicitly only support certain hardware, and that list could be small and finite. For instance Replicant (Q7314062) version 6.0 0003 supported only 11 devices. There might be a bit more devices supported as some more Galaxy Nexus variant might work, but beside that, that's pretty much it. The number of variants is finite. It's just that I didn't have the time to look into which ones we're supposed to support (I'm involved in Replicant). For that version, the kernels are device specific, so the images won't work on a device that is not officially supported. Another example I have in mind is the ralim/ts100 soldering iron firmware that supports very few soldering irons. Rockbox (Q1143754), coreboot (Q286812), libreboot (Q20085696) also support a finite number of devices as part of the code is device specific and writing device specific code is required to add support for a new device, unless the hardware is mostly identical to one already supported, but here too, there will be a finite number of identical devices. But then it also depend on how you define compatibility completeness. For instance a modem can be compatible with Linux in the sense that Linux has a driver to interact with it, but that same modem might also be able to run an upstream Linux kernel. So from a narrow perspective you could make compatibility be complete, but from a broader perspective you don't want to map non relevant things. Note that in the case I just described (which really exists) you can easily differentiate between both by being more precise about the compatibility (for instance that device could be compatible with a dts which shows that the device can run Linux, or with the qualcomm modem driver). GNUtoo (talk) 11:06, 13 August 2020 (UTC)[reply]

Support I was trying to link a third party game controller with a game system today. This would help with that. Moebeus (talk) 21:13, 29 July 2020 (UTC)[reply]
Comment can we agree not to use it on Linux kernel (Q14579) and similar items? The inverse would be better for these. --- Jura 21:15, 10 August 2020 (UTC)[reply]

This makes sense, however I think we could make that broader, and agree on linking many element to one instead of one to many. GNUtoo (talk) 11:06, 13 August 2020 (UTC)[reply]

Can you update the samples above to reflect this? It still has several "Linux kernel (Q14579) → ..." samples. --- Jura 09:08, 10 December 2020 (UTC)[reply]

Question I like the idea, but how would you manage cases like Linux, or Windows, compatible with thousands of different hardware models? NMaia (talk) 10:31, 1 September 2020 (UTC)[reply]

The way to deal with a lot of devices being compatible with like "The Linux kernel" would be to have a many to one relationship: For instance the Beaglebone Green is compatible with the Linux kernel. So to encode that the Beagle bone green would have "compatible with" "The Linux kernel" but "The Linux kernel" will not point to the Beaglebone Green. This is to have pages without too much links. Here it will be up to the people making these links to understand if structurally the Linux kernel or the Beaglebone item should have the link. For hardware like a GPU, they could be compatible with a driver (like nouveau, radeon, amdgpu, etc) that is part of the Linux kernel for instance. So there are many ways to prevent having items with too much compatible with properties. GNUtoo (talk) 08:22, 10 December 2020 (UTC)[reply]