Wikidata:Property proposal/has forks
has forks
editReturn to Wikidata:Property proposal/Computing
Under discussion
| Description | Notable software forks of this software |
|---|---|
| Represents | fork (Q332903) |
| Data type | Item |
| Example 1 | youtube-dl (Q28401317) has forks: yt-dlp (Q108454371) |
| Example 2 | Visual Studio Code (Q19841877) has forks: VSCodium (Q111967621) |
| Example 3 | OpenOffice.org (Q511977) has forks: LibreOffice (Q10135) |
| Example 4 | Firefox (Q698) has forks: LibreWolf (Q105623664) |
Motivation
editCurrently, which notable/used forks a software has and which software was originally forked from (and also when) is either not specified or using the based on property. A bot/script could populate this standardized property. I think it would be useful but many items for notable forks are still missing (there wasn't even one for VSCodium). For example, one could query for all notable forks created in some year or have a software's forks linked at a page about the respective software which can be useful e.g. to people using that software.
based on (Property:P144) is ambiguous and using instance of with an of qualifier is even less usable. I don't know if I can propose two properties at once but if so I'd also like to propose property is fork of and if not would like to propose that later on if nobody else does.
Previous discussion (1 reply).
--Prototyperspective (talk) 17:38, 1 October 2024 (UTC)
Discussion
edit
Conditional support I agree with @Dexxor: from the previous discussion that the inverse "is fork of" would be better for this data. -wd-Ryan (Talk/Edits) 00:26, 2 October 2024 (UTC)
- The thing is I think both are needed and useful. On a page about some software (it doesn't have to be a Wikipedia page), a way to view all forks of this software would often be useful and querying that data via the has forks property seems like the best way and it would then be also included in the respective Wikidata item. This is similar to e.g. the has parts and part of properties: it needs both except if the second item somehow gets this info added as well dynamically if it's added to the other (currently bots may do this for such dual properties). Prototyperspective (talk) 10:50, 2 October 2024 (UTC)
Oppose as "has fork"; would support as "is fork of" per Wd-Ryan. Mahir256 (talk) 17:03, 2 October 2024 (UTC)
- Why not both? Forks are useful information at the respective software just as much as the info what software a given software was forked from. Making a new query for every software on some page which forks it has may not be possible but one could also fetch the has forks values. Why is there an inverse for has part Property:P527 part of Property:P361? Same reasons apply here too. Prototyperspective (talk) 21:04, 2 October 2024 (UTC)
- Oppose for "has fork" per Mahir256's reasoning. If you look on the actual usages of has part(s) (P527) and part of (P361), there are many cases were we want to list claims in one direction and not in the other. If a software is a fork of another software we however would always want to list that information on the item for the software. The two are not used in a way where you can just add the reserve claims with a bot.
- The amount of triple's that a triple store can save is limited, so we would waste resources when we allow inverse properties in cases like this. If you copy over properties with a bot, dealing with data changes can get messy. ChristianKl ❪✉❫ 21:23, 7 October 2024 (UTC)
- Well I thought it was the other way around – that inverse properties are useful mainly when the data is relevant at both items. Here's examples for illustration: if one wanted to create some Wikidata list with Listeria of art production software or whatever each with a list of its forks then this data could not be retrieved if there's only the is fork of property in the respective forked software item. Likewise, if there is some Software-Wiki powered by Wikidata (if it's ever more complete on software), then it would need to have a separate query to fetch the forks of the given software (or multiple) instead of just pulling it from the Wikidata item. If Wikipedia shows forks of a software the article is about in some template (maybe the infobox but probably some other one) then it couldn't get that data except if one enables to query things like that instead of just properties of the article's WD item. etc Prototyperspective (talk) 23:33, 7 October 2024 (UTC)
- Hopefully people here see these examples and change their vote if they can't think of a plausible good rebuttal. There's many props that are used in both ways. Prototyperspective (talk) 09:47, 25 October 2024 (UTC)
- P527 and P361 are needed in both ways. Bouzinac 💬●✒️●💛 06:31, 13 October 2024 (UTC)
- Yes and has forks / fork of are also needed in both ways. Prototyperspective (talk) 09:28, 13 October 2024 (UTC)
- Well I thought it was the other way around – that inverse properties are useful mainly when the data is relevant at both items. Here's examples for illustration: if one wanted to create some Wikidata list with Listeria of art production software or whatever each with a list of its forks then this data could not be retrieved if there's only the is fork of property in the respective forked software item. Likewise, if there is some Software-Wiki powered by Wikidata (if it's ever more complete on software), then it would need to have a separate query to fetch the forks of the given software (or multiple) instead of just pulling it from the Wikidata item. If Wikipedia shows forks of a software the article is about in some template (maybe the infobox but probably some other one) then it couldn't get that data except if one enables to query things like that instead of just properties of the article's WD item. etc Prototyperspective (talk) 23:33, 7 October 2024 (UTC)
- The amount of triple's that a triple store can save is limited, so we would waste resources when we allow inverse properties in cases like this. If you copy over properties with a bot, dealing with data changes can get messy. ChristianKl ❪✉❫ 21:23, 7 October 2024 (UTC)