Wikidata

Wikidata:Requests for comment/how to manage software versions

< Wikidata:Requests for comment


THIS RFC IS CLOSED. Please do NOT vote nor add comments.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
no consensus to change current pracitce --Pasleim (talk) 19:53, 3 March 2021 (UTC)[reply]

WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. WikiProject Ontology has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
@Ghouston, Dhx1:

Issue

edit

Currently, it's impossible to distinguish between major versions, minor versions, builds, etc. This is due to the fact that:

As a consequence, often software version identifier (P348) lists major version, minor versions, releases... all mixed together. Needless to say that I've never seen something like version type (P548) → minor version as a qualifier (it doesn't even exists an item like "minor version").

Proposal: treat software as we treat books

edit

First, create an item for every version (major, minor...) of every software.

In order to organize the hierarchy of items about books we have a common model (FRBR: Work → Expression/Manifestation → Exemplar) and so we need only two propertes to link Work with Expression/Manifestation (has edition or translation (P747) and its inverse edition or translation of (P629)) and Expression/Manifestation with Exemplar (exemplar of (P1574)). With software versions, such a common model doesn't exists (as far as I know). To represent all the various version numbering schemes (for example, MAJOR.MINOR.PATCH or MAJOR.MINOR.REVISION.BUILDNUMBER) adopted by softwares, I think we have two options:

  • create a property (and its inverse property) for every version type: we'll have "major version", "major version of", "minor version", "minor version of", "build", "build of", "release", "release of"... properties;
  • create only a "software version" property (different from software version identifier (P348) because with an item datatype) and its inverse "software version of" AND consistently use object of statement has role (P3831)version type (P548) qualifier.

Here are examples of the two options:

Option 1

edit

Create a "software version" property and use object of statement has role (P3831)version type (P548) as qualifier in order to indicate the version type. Optionally, create a "software version scheme" to verify that the version scheme is respected.

Microsoft Windows (Q1406)

edit
software version
Normal rank Windows 10 edit
version type major version
0 references
add reference
add value

Windows 10 (Q18168774)

edit
software version
Normal rank Windows 10 Version 1511 edit
version type minor version
0 references
add reference
add value

Windows 10 Version 1511 (Q22686609)

edit
software version
Normal rank Windows 10.0.10586.3 edit
version type build
0 references
add reference
add value

Option 2

edit

create "major version", "minor version", "build"... properties (all subproperties of "software version").

Microsoft Windows (Q1406)

edit
major version
Normal rank Windows 10 edit
0 references
add reference
add value

Windows 10 (Q18168774)

edit
minor version
Normal rank Windows 10 Version 1511 edit
0 references
add reference
add value

Windows 10 Version 1511 (Q22686609)

edit
build
Normal rank Windows 10.0.10586.3 edit
0 references
add reference
add value

WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.

Comments

edit
A third option would be to only record version data in the reverse direction - see Wikidata:Property proposal/software version of, and then I don't even think qualifiers are needed, can't we just indicate the version type via instance of (P31)?? ArthurPSmith (talk) 13:33, 22 May 2018 (UTC)[reply]
Can you expand a bit on why it's important to point to items rather than string values? Is it because we can model richer data? And does that mean that we'd be agreeing to eventually have one item for each version of each software product? Not that I object to that, just trying to understand where you're coming from. --Waldir (talk) 14:13, 22 May 2018 (UTC)[reply]
If you'll notice in the examples above, the proposal is to attach minor versions to the items for major versions, and so down the hierarchy, rather than having all major, minor, and other versions listed on the main item for the software. That requires items for the versions, not strings. I wouldn't expect we would have one item for each version of every software product, just as we don't have one item for each human or star or whatever. If there's no need for any additional information, the present use of software version identifier (P348) is probably fine. But it does allow attaching additional information (such as release date, download size and URL's, etc.) to the version in a natural way, with references, etc. ArthurPSmith (talk) 14:32, 22 May 2018 (UTC)[reply]
@Waldir:You're right, version type (P548) is better than object of statement has role (P3831).
@ArthurPSmith:I support your proposal about recording version data only in the reverse direction but books don't do it. Do you know why? A regards the option to indicate version type via instance of (P31), it's possible but I think it's better to have a specific property.--Malore (talk) 12:13, 27 May 2018 (UTC)[reply]
I substituted all the instances of object of statement has role (P3831) with version type (P548)--Malore (talk) 16:20, 8 June 2018 (UTC)[reply]
  •  Support migration, versions of softwares should also have their items. --117.14.250.142 05:36, 12 April 2019 (UTC)[reply]
  • I support the creation of items for versions of software. I agree that being able to model additional statements per version item is important for Wikidata. For example, different file formats are associated in different ways with versions of some software. YULdigitalpreservation (talk) 17:41, 29 May 2019 (UTC)[reply]
  •  Support Option 1. Because that will make the corresponding between the infobox and Wikidata with Lua better than option 2. It's also more tidy (if you ask me). - Premeditated (talk) 14:39, 11 July 2019 (UTC)[reply]
  • Strong  Oppose. It's unclear how you define version and revision and for what you want to create items. There are endless many different versioning schemes – the two you listed are only two of the more "conventionally" types of versioning, there are completely different schemes. Some projects use the date as version number (20190815) some use a compilation counter (3245646) or version-control-hashes (5eff689), the version-number of TeX is a number becoming closer and closer to Pi (current version is 3.14159265) Latex has currently the version "2ε Issue 29" and and and… There is simply no way to add hierarchy like major, minor, bug… without distorting the reality. Version-numbers can only be strings, all further description has to be saved qualifiers or other properties. So the only option if we want to create items for every version is to create items for literally every version and release of every software. Considering that there are projects with huge amounts of releases it's unclear to me how this should scale. JOSM (Q12877) has 15238 releases, Chromium (Q48524) has even more since they have a rolling release-model in which every modification of the software gets a version number. Furthermore all Infoboxes in all Wikipedias have to be rewritten, probably also the Lua modules have to be improved for this. All the Bots updating version-numbers have to be rewritten. So creating items for software versions is a huge project. I'm not saying that this should not be done. But I'm saying that we cannot do it today. We lack of the resources to do something like that! There are way to few people updating software versions and the bots that we have lack developers to improve them. Consider alone the software in Arch-Linux: there are ~300 outdated software-items (some outdated for quite some time!), even through I updated thousands of software versions by hand and improved github-wiki-bot to update thousands of items. We should not make us way more work, when we can't handle the current amount of work to do – especially since the benefits are very small and vague. We can already map 99% of the information with software version identifier (P348) and qualifiers like version type (P548). Let us instead start to fix the urgent problems with software versions on Wikidata:
-- MichaelSchoenitzer (talk) 00:33, 15 August 2019 (UTC)[reply]
  •  Support Option 1. Mainly because I prefer less properties with qualifiers over a lot of different properties. But I‘m not sure about creating items for every version. I think that just having the versions listed inside the main item should be enough in most cases --DaSch (talk) 06:47, 17 January 2020 (UTC)[reply]
  •  Oppose I agree with Michael. Too vague, high manpower cost. I believe the current model is good enough for now. --So9q (talk) 05:30, 22 March 2020 (UTC)[reply]
  •  Neutral: I understand Michael's worries but on the other hand the current situation must be improved somehow. See this example: Microsoft Edge (Q18698690)software engine (P408)EdgeHTML (Q19668903)software version identifier (P348)< 79. It's not possible at the moment to create a machine-readable documentation of when the rendering engine of Microsoft Edge was changed. -- Discostu (talk) 10:45, 30 March 2020 (UTC)[reply]
  •  Oppose In the particular case of Windows, Microsoft is not that clear about what is a major or minor release anymore, and in fact intends to phase out this notion of "Windows n", in a similar vein as Apple only making incremental updates to OS X. The classification of a release as "major" or "minor" should not be forced onto all software, as not all software uses that release scheme. For certain large companies like Microsoft which have a well-defined versioning scheme, we can create their own classification of versions as "major" or "minor". Windows Server 2012 R2 and Windows 8.1 in particular are ambiguous in this regard. Much better would be the ability to store the version history as a branched list of sorts, and either use a classification specific for a company or just let the consumer of the data decide.--Jasper Deng (talk) 01:46, 20 April 2020 (UTC)[reply]
    @Jasper Deng: This is at least impossible for the MediaWiki (Q83), where its versions can be new one-per-a week. --Liuxinyu970226 (talk) 03:15, 14 May 2020 (UTC)[reply]
    @Liuxinyu970226: I'm not sure what you mean here. MediaWiki's versioning scheme has been one of the most consistent I've ever seen.--Jasper Deng (talk) 03:48, 14 May 2020 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Requests_for_comment/how_to_manage_software_versions&oldid=1374628790"