Property talk:P348

Active discussions

Documentation

software version identifier
numeric or nominal identifier of a version of a software program or file format, current or past
DescriptionVersion numbers of versions of the software. Qualify with version type (P548) and point in time (P585).
Representssoftware version (Q20826013)
Data typeString
Domain
According to this template: software (Q7397)
According to statements in the property:
software (Q7397), software component (Q20919931), file format (Q235557), programming language (Q9143), data set (Q1172284), website (Q35127), video game (Q7889), work (Q386724), public license (Q7257461) or technical standard (Q317623)
When possible, data should only be stored as statements
Allowed values
According to this template: [words] [comparator] digits[.digits[.digits]][letters] [build/rc/alpha/beta/-/ digits] [(text name)][*/+/ - version/ .. version],
According to statements in the property:
[\w\s]*(?<r>([=≤≠≥]|[<][=>]?|[>]=?|!=)?\s*(?<v>(\d+(?:\.\d+)*)(\w[\d\w]*(?:[-.:\s][\w\d]+)*)?((?:\s?\([\d\w]+(?:[-.:\s][\d\w]+)*\))*))\s?([*]|\s*[+])?|(?&v)(?:\.\.|\s-\s|–)(?&v))(?:\s*,\s*(?&r))*
When possible, data should only be stored as statements
ExampleBugzilla (Q55671) → 4.5.1
Avast Antivirus (Q1574) → 2014.9.0.2016.330
AWK (Q213970) → IEEE Std 1003.1-2008
AmigaOS (Q380526) → 4.1 Update 6
Java platform (Q1713118) → 7 Update 51
Plan 9 from Bell Labs (Q725779) → Fourth Edition
Windows Internet Explorer 8 (Q841259) → 8.0.6001.18702IC
Composer (Q15252222) → 1.0.0-alpha8
AIMP (Q293825) → 3.55 Build 1324
Erlang (Q334879) → R16B03
Kubuntu (Q11250) → 13.04 (Raring Ringtail)
Microsoft Office (Q11255) → 15.0.4551.1011
Microsoft Office (Q11255) → 2011 (14.3.9 SP3)
CrunchBang Linux (Q11983) → 11 20130506 (Waldorf)
MariaDB (Q787177) → 10.3.9
Internet Explorer 10 (Q819537) → 10.0.9200.16521 RTM
Pokémon Go (Q20966579) → 0.35.0
Firefox (Q698) → 52.2.1 ESR
Lua (Q207316) → > 5
Format and edit filter validationAbuse filter #61
Tracking: sameno label (Q32069410)
Tracking: differencesno label (Q32069376)
Tracking: usageCategory:Pages using Wikidata property P348 (Q20989971)
Tracking: local yes, WD noCategory:Software version not in Wikidata, but available on Wikipedia (Q26467729)
See alsotabular software version (P4669)
Lists
Proposal discussion[not applicable Proposal discussion]
Current uses
Total228,903
Main statement224,73598.2% of uses
Qualifier4,1111.8% of uses
Reference57<0.1% of uses
Search for values
[create Create a translatable help page (preferably in English) for this property to be included here]
  Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P348#type Q7397, Q20919931, Q235557, Q9143, Q1172284, Q35127, Q7889, Q386724, Q7257461, Q317623, SPARQL, SPARQL (new)
 
Format “[\w\s]*(?<r>([=≤≠≥]|[<][=>]?|[>]=?|!=)?\s*(?<v>(\d+(?:\.\d+)*)(\w[\d\w]*(?:[-.:\s][\w\d]+)*)?((?:\s?\([\d\w]+(?:[-.:\s][\d\w]+)*\))*))\s?([*]|\s*[+])?|(?&v)(?:\.\.|\s-\s|–)(?&v))(?:\s*,\s*(?&r))*: value must be formatted using this pattern (PCRE syntax). (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P348#Format, SPARQL, SPARQL (new)
 
Citation needed: the property must have at least one reference (Help)
Exceptions are possible as rare values may exist.
List of this constraint violations: Database reports/Constraint violations/P348#citation needed, SPARQL (new)
 
Format “.{1,200}: value must be formatted using this pattern (PCRE syntax). (Help)
List of this constraint violations: Database reports/Constraint violations/P348#Format, hourly updated report, SPARQL, SPARQL (new)
 
This property is being used by:

Please notify projects that use this property before big changes (renaming, deletion, merge with another property, etc.)

QualifiersEdit

I report this discussion on the project chat (Wikidata:Project_chat/Archive/2013/04#Property:P348 - Stable_version (software only)) regarding the qualifiers properties. --Viscontino talk 08:45, 5 April 2013 (UTC)

Qualifiers are available now, I think we could change the name of this property. The only things we need is a qualifier property (something like "state" or similar, a property which has a general use) and an item where we could link to. (I couldn't find an existing item for "stable version", they might be an item in other languages?) --#Reaper (talk) 13:16, 27 April 2013 (UTC)
I support this idear. Is their any current discussion about that, because the property name is still "stable version"? --Stiegenaufgang (talk) 16:55, 5 June 2014 (UTC)
  Done. John Vandenberg (talk) 02:01, 19 September 2014 (UTC)

German translationEdit

I think the German translation of this property should be updated, because it has a different meaning than the English one.

  • stabile Version → Version (englː version)
  • aktuell stabile Version der Software → stabile Version der Software (englː stable version of the software)

Stiegenaufgang (talk) 23:23, 15 November 2014 (UTC)

Constraint:QualifiersEdit

Recently I have added the constraint on qualifiers but there are some discrepancies (many qualifiers were added by me):

Matěj Suchánek (talk) 17:05, 22 December 2014 (UTC)

Delete old versions?Edit

Just to be clear: Should we delete statements with old, superseded versions? (Except if there are multiple development branches, like GnuPG 1.4.x and 2.x.) —DSGalaktos (talk) 14:11, 26 March 2015 (UTC)

Some links (I suppose Wikidata could handle more versions, using qualifiers and ranks): Wikidata:Bot requests/Archive/2013/04#Keeping last stable software version up to date, Wikidata:Requests for permissions/Bot/SamoaBot 8, Wikidata:Project chat/Archive/2013/04#Property:P348 - Stable version (software_only), Wikidata:Project chat/Archive/2014/12#Unintentional removal of statements in software version identifier (P348), Wikidata talk:Abuse filter#Version. Matěj Suchánek (talk) 16:43, 26 March 2015 (UTC)
So from the last two links I take it the statements are supposed to stay? —DSGalaktos (talk) 22:14, 26 March 2015 (UTC)
Yes :) ·addshore· talk to me! 00:05, 27 March 2015 (UTC)
Does this "Yes" answer the last question or the question in the heading? I guess it's a "yes" again ;) Brevity (talk) 20:40, 2 August 2016 (UTC)
There is a scalability problem with this. I'm thinking of "rapid release cycles", see w:History of Firefox, w:Firefox version history, w:Google Chrome version history… Even worse, some web applications are tagging new versions like, more than weekly (e.g. Laravel releases, and I guess we could easily find even more frequently released applications). Od1n (talk) 20:19, 6 March 2017 (UTC)

Overuse of this property for licensesEdit

I have seen this property in (mis-)use for licenses, i.e. Creative Commons Attribution-ShareAlike 2.0 Generic (Q19068220). I am not sure if it is a good idea to mix both, especially since this property explicitly states it is for software.

Maybe there should be a new property specifically for license versions. What do you think? --Wiki-Wuzzy (talk) 22:41, 15 April 2015 (UTC)

@Wiki-Wuzzy: Creative Commons Attribution-ShareAlike 2.0 Generic (Q19068220) software version identifier (P348) 2.0 should be replaced with Creative Commons Attribution-ShareAlike 2.0 Generic (Q19068220) edition number (P393) 2.0 Iwan.Aucamp (talk) 13:26, 22 May 2020 (UTC)

How to mark the latest stable version when older versions are keptEdit

Use three seashells small boxes on the left of the date to mark the latest version as "Preferred rank". Don't forget to mark the older version(s) as "Normal (or deprecated) rank". The RedBurn (ϕ) 11:21, 25 May 2015 (UTC)

Just a small follow-up question: Should the current version be marked as preferred and older versions as normal, or the current version as normal and the older versions as deprecated? --1-Byte (talk) 14:21, 1 February 2016 (UTC)
Is that the recommended way of doing that? The first try of changing the rank of an old version to “deprecated” yields a warning that says setting to deprecated is “also incorrect”. --AVRS (talk) 18:42, 28 March 2016 (UTC)

How to mark a version as unstableEdit

See P548 Talk: add a qualifier "type of version", which current possible values are "alpha version" and "beta version". The RedBurn (ϕ) 13:01, 25 May 2015 (UTC)

Be sure to add a qualifier "type of version" with value Q19972162 (stable version) to at least the latest stable version to make it possible to selectively retrieve it from a template. The RedBurn (ϕ) 16:27, 25 May 2015 (UTC)

Labels and descriptions are wrongEdit

For example, in Ukrainian, this property is labelled as "стабільна версія", with the description "остання стабільна версія програмного забезпечення". "стабільна" means "stable", "остання" means "last". Of course, people will continue to delete non-last and non-stable versions. — Vort (talk) 07:36, 4 December 2015 (UTC)

I just went through the label list and removed loads of outdated labels and descriptions that looked like they included “latest” or “stable”. Main edit, auxiliary edits. I probably broke some grammar, so it would be great if people actually speaking these languages could review the changes and fix problems. Also, I wasn’t able to fix Icelandic, because has edition or translation (P747) has a conflicting label. —Galaktos (talk) 10:20, 4 December 2015 (UTC)
Thanks. — Vort (talk) 13:37, 4 December 2015 (UTC)

Don't keep old versionsEdit

Regarding the software items I came across, none had a complete listing of versions (as eg compared to the list of releases on GitHub). Version lists just started with the version that was current when the item was created, and had "holes" in the list of newer/updated versions. Thus, the list of version numbers is irrelevant and misleading (eg you cannot compare counts/periodicity of version number updates across software items, which could be interesting facts). IMO, only the newest one(s) should be kept. --Brevity (talk) 20:20, 2 August 2016 (UTC)

Some articles have tables of versions, for which Wikidata could be referred to. --AVRS (talk) 21:21, 2 August 2016 (UTC)
Major versions should be kept to track development.
First version should be kept.
d1g (talk) 22:20, 9 September 2017 (UTC)
  • Entries are not deemed to be complete. We don't delete no longer current, but accurate statements. Just set the recent one as preferred. See Help:Ranks.
    --- Jura 08:53, 10 September 2017 (UTC)
We should be able to indicate ranges of version numbers, without having to list each version number exhaustively. Generally a version number like "10+" is enough for an open-ended range, or "10 - 12" for a closed range (which usually includes subversions of version 12 for the upper bound, like "12.1", Otherwise we have to use "<= 12", another solution being to indicate "10 - 12*" to include also subversions for the upper bound, in which case "10 - 12" would set the upper bound to "12" included in the range, but "12.1" excluded)
See the remark below about the need to specify multiple versions (this could deprecate the use of "edition" properties, given that each version or set of versions or version ranges can also be restricted by another "type of version" qualifier, indicating "release", "pre-release", ...; versions can also have one or more associated commercial names or numbers to designate the "editions", generally more generic and indicating editions or branches, or supported/subscribed/paid feature sets like "Pro edition", "Home edition"... or commercial/curtesy version names on Windows (95, 98, NT, 2000, XP, Server...), Android (sweetened goodies), or Mac OS (animal names), and many Linux distribs (such as feminine first names on Ubuntu), or heroes/legendary characters (as well there are frequently "code names" used in pre-releases: these code names also have no format, they act like additional tags as well, for example "Redstone 2" for Windows 10).
So "editions" are just to be treated as optional additional "tags" (without any required format, just like brand names) qualifying a precise version number or ranges of version numbers. : A software "edition" is in fact an assembly of multiple software components in a supported "features set", each component having its own version number (in many opensource projects, version numbers evolve constantly and unpredictably at any time; what open source project do is that they designate some branches with "milestone names", also used as qualifying "tags", with unlimited number of tags within the evolution of the software suite). Verdy p (talk) 02:40, 3 November 2018 (UTC)

Document versionsEdit

Can this be generalized to just "version" to allow for document versions? This is quite common with technical specifications, e.g., .ZIP File Format Specification, version 6.3.4 (Q26211547) is version 6.3.4 of ZIP (Q136218) (currently it seems to be abusing edition number (P393)) or Creative Commons Attribution-ShareAlike 2.0 Generic (Q19068220) is version 2.0 of Creative Commons Attribution-ShareAlike (Q6905942) (currently abusing this property unless this is generalized to encompass this usage). 50.53.1.33 21:19, 26 September 2016 (UTC)

  •   Support. Specifying the version for the standards is quite common practice both in Wikipedia and in Wikidata. We should rename the label to "version" (as already done in many languages) and expand the scope to documents. —putnik 22:21, 2 April 2018 (UTC)
  •   Support. This is allowed now for "data sets" (which include "files", in any format including "documents", but also "databases"), just like it was allowed for "file formats". Note that "data sets" could be as well treated as subclasses of "software components", which were already allowed (but data sets are not necessarily numeric and computerized). What is missing is to allow versions to "technical specifications" (including "standards", like Unicode, or ISO standards which are versioned by part number/year of publication); there's also a use of version numbers for books (but this is better covered by the "edition" property, even if now many books are also available online as files, i.e. datasets). This causes problems for "documents" because books are subclasses of documents, and documents are not necessarily computerized in a numeric format (the numeric version is most often derived as a non-unique facsimile, but this is not the original book itself). There are some uses of versions for other non-numeric kinds of intellectual or artistic works (I'm not sure that books or other published works can be assimilated as subclasses of "datasets"). There remains some exotic uses of version numbers for organizations that use them as part of their branding and communication (we've seen various exotic examples of "organization 2.0", for example sport clubs). Verdy p (talk) 10:36, 12 November 2018 (UTC)
  • @50.53.1.33, putnik, Verdy p:   Strong oppose While I think this should be generalized, this property is supposed to be used on an item to indicate that the item has a version with the property's value as identifier. For example Firefox (Q698) software version identifier (P348) 57.0.3. This does not mean Firefox's "version identifier" is 57.0.3, it means Firefox "has a version with the identifier" 57.0.3. In other words, this property should not be used on versions items, but on items which could conceptually have version items. So while I think we should rename this property, we should rename it to "has version with identifier". We can separately rename edition number (P393) (which is used correctly in .ZIP File Format Specification, version 6.3.4 (Q26211547) edition number (P393) 6.3.4) to "edition or version number" or "edition or version identifier", but we should not start using this property on versions to items themselves as that will just make things very confused. Iwan.Aucamp (talk) 13:39, 22 May 2020 (UTC)

<ping project should not be used in an indented reply> Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Ilya
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Daniel Mietchen
Jsamwrites
Tinker Bell
FabC
Jasc PL
putnik
Dhx1
Tris T7
Peb Aryan
lore.mazza004
Rc1959
Premeditated
Iwan.Aucamp
LiberatorG
Primhill.Computers
FWVH (passionné d'informatique et d'électronique)
94rain
So9q
Adrijaned
Sylvain Leroux
SM5POR
Haansn08
1-Byte
Luca.favorido
  Notified participants of WikiProject Informatics

Automatic updates by Github-wiki-botEdit

User:Github-wiki-bot automatically extracts stable releases and the release dates of Software from GitHub. – Simon04 (talk) 12:15, 4 August 2017 (UTC)

Property constraints regex may be wrongEdit

Please check Linux-libre (Q665683) to see how it is conflicting with real data. NMaia (talk) 11:51, 23 March 2018 (UTC)

This is solved. Verdy p (talk) 10:51, 12 November 2018 (UTC)

How do I specifiy and later as inEdit

Version requirement, e.g. version 1.23+ for Property:P1547? --[[kgh]] (talk) 23:28, 4 April 2018 (UTC)

This is solved now (see below comments about ranges and the new comma-separated list of versions/ranges) Verdy p (talk) 10:52, 12 November 2018 (UTC)

Adding version URL for softwareEdit

Lets say I'm adding a version for this game data:

https://starbounder.org/Version_1.3.3

The constrains for "software version" doesn't allow me to add the URL in the version number so it's easy to access the changes made in that specific version. Which is easily accessible with the link I gave before.

Can we add the "URL" category to the version software constrains?

As a workaround I'll be using "download link" but it's not entirely true as the link isn't that. --Frenchiveruti (talk) 16:22, 12 June 2018 (UTC)

Just add a qualifier to the property giving the version number, in order to specify separately a download URL for that version. The allowed qualifier for it is specified above! Verdy p (talk) 11:27, 12 November 2018 (UTC)
Note: URLs/URIs are not parsable, they are completely opaque, have no defined syntax beside the generic URL format, and so they don't necessarily contain the version number or software that they are related to. As well the same version number will frequently have multiple download URLs (which may be specified as additional qualifiers), meaning that these URLs cannot be used as distinctive identifiers: version numbers are suitable in "URNs", but definitely not as general URLs/URIs, they are indepedendant of the effective location(s), not just at specific URLs/URIs on the web, where a software/dataset/component may be found. Verdy p (talk) 11:34, 12 November 2018 (UTC)

Exact version numbersEdit

Until now it was only possible to specify an exact version number. But many softwares are in fact described in ranges of version numbers for compatibility. so the initial words (allowed in the value even if they are not translatable easily) can now also include classic mathematical operators: "<", "<=", "!=", ">=", ">", as well as "≤", "≠", "≥". There's no need of "=" which is implicit. A software may specify multiple versions: but I'm not sure how they can combine, unless we use a leading word ("and", "or") or operator ("&" "|"): this may be needed to specify multiple ranges. The alternative would be to allow separators like ", " for multiple version numbers (each one match with "="), but for version ranges it is not possible ("-" is already used in single version numbers), unless we also allow ".." or " - ". For example:

  • "5 - 6" or "5 .. 6" means all versions from "5*" to "6*
    if we split it into multiple properties: ">= 5", "& <= 6"
  • "10 - 12, 14+" means versions from "10*" to "12*" or "14*" and higher
    if we split it into multiple properties: ">= 10", "& <= 12", "| >= 14"; but the problem is that order of properties is not necessary stable in Wikidata (this is fine to split "or", i.e. unions of conditions, but then it is not for "and", i.e. conjonctions of conditions, due to the different associativity).

So I suggest deciding which separator we could use within a single property value, to mean a conjonction of conditions ("X and Y"):

  • I propose to specify ".." or " - " (or possibly using a long en dash " – ", still with surrounding spaces to avoid confusion with hyphens used without spaces within version numbers) for common ranges of version numbers. I think that ".." (possibly with surrounding spaces, but this is not required) causes less confusion for readers.
  • Also I propose deprecating the leading words allowed in the value (which are not internationalisable in this property, and cause various problems with Bidi, for example with Arabic or Hebrew words) in favor of mathematical operators (plus some separators like the comma for lists of values, or just using multiple separate properties, i.e. one for each value or range of values).
  • As well the semantics of ">= number" (or "number+") is clear, but the semantics of "<= number" should include match not just "number" but also all "number.subversion".
  • That's why "<" is proposed to avoid the ambiguity which exists with closed ranges like "10 - 12", which should also be equivalent to ">= 10" and "< 13" (and not "<= 12"), or with "- 12" (equivalent to "< 13" and not to "<= 12").
  • As well, the semantics of "!= 12" with software version numbers is {"< 12", "or >= 13"} (but not "> 12").
    Note: "!= 12" is semantically equivalent to "< 12, >= 13", or to "< 12, 13+" (but not "< 12, > 12" like in mathematical numbers, even if it may seem counter-intuitive).

This an open question: How do we compare (and order) version numbers with ranges that specify an upper bound?

  • Allowing the comma separator (as an equivalent for saying "or") cause no semantic problem at all: "10,11,14" means that the version number must be exactly "10", or "11", or "14".
  • There's no ambiguity problem when the range is open-ended (with no upper bound), as in "10, 12+".
  • The problem starts when we specify ranges (in the comma-separated list or in a single property specifying a single range), and a range has an upper bound, as in "10, 12 - 14" (the problem is on the interpretation of "14" which should be "< 15", but not "<= 14")
    Solution: "12 - 14" means ">=12" and "<=14" (the upper bound is exact), but "12 - 14*" means ">=12" and "<= 14*", i.e. the same as ">= 12" and "< 15" (upper bound is more fuzzy, "*" implies a prefix notation that allows including subversions) :
  • The interpretation of "12+" means ">= 12" and includes "12", "12.1", "12 Alpha2", "13" (the "+" really means open-ended)
  • The interpretation of "12*" means ">= 12", and "<13" and includes "12", "12.1", "12 Alpha2", but not "13" (the "*" means that the initial prefix before must match exactly, it's not open-ended). So "Windows 8*" would match "Windows 8" or "Windows 8.1" but not "Windows 10", while "Windows 8+" would match the three).

Verdy p (talk) 00:03, 3 November 2018 (UTC)

Here is a version of the regexp with additional newlines, whitespaces, and indentation for readability (non-significant here, must be removed in the final properties):
 [\w\s]*
 (?:                                  (# this matches one version number and attached labels, possibly half-open )
   ( [=≤≠≥] | [<][=>]? | [>]=? | != )?  (# version comparator )
   \s*
   ( \d+ (?: \.\d+ )* )                 (# main version number )
   [-.:\s]?(                            (# optional build number )
     \w[\d\w]* (?: [-.:\s][\w\d]+ )*
   )?
   \s?
   (\(
     [\d\w]+ (?: [-.:\s][\d\w]+ )*
   \))?
   ( [*] | \s*[+] )
 |                                    (# this matches a closed range of version numbers and attached labels )
   ( \d+ (?: \.\d+ )* )                 (# main version number )
   [-.:\s]?(                            (# optional build number )
     \w[\d\w]* (?: [-.:\s][\w\d]+ )*
   )?
   \s?(\(                               (# optional descriptive labels in parentheses )
     [\d\w]+ (?: [-.:\s][\d\w]+ )*
   \))?
   (?: \.\. | \s-\s | – )               (# closed range separator )
   ( \d+ (?: \.\d+ )* )                 (# main version number )
   [-.:\s]?(                            (# optional builds number )
     \w[\d\w]* (?: [-.:\s][\w\d]+ )*
   )?
   \s?(\(                               (# optional descriptive labels in parentheses )
     [\d\w]+ (?: [-.:\s][\d\w]+ )*
   \))*
 )
It's hard to fit in the 400-characters limit of a property value, so we cannot indicated a list of (versions or version ranges)... unless the installed version of PCRE supports "subroutines" (i.e. identical subrexps to which we give a short alias name and then reuse, which could reduce the total length).
Verdy p (talk) 21:34, 6 November 2018 (UTC)
In full agreement with you on this. Looks like the current regex is broken and needs reworking, however. Adelsheim (talk) 22:10, 7 November 2018 (UTC)
You don't suggest anything. I asked: can we use PCRE "subroutines" to reduce the 3 identical long lines above to a single one assigned to identier reusable in the 2 other occurences?
If I use "PCRE 5.1 subroutines" (see https://www.regular-expressions.info/subroutine.html or https://www.pcre.org/original/doc/html/pcrepattern.html#SEC23), and make the long subpattern into a subroutine (named "v" here), then this compacts to:
 [\w\s]*
 (?:                                  (# this matches one version number and attached labels, possibly half-open )
   ( [=≤≠≥] | [<][=>]? | [>]=? | != )?  (# version comparator )
   \s*
   (?<v>                                (# this subroutine match one version number and attached labels )
     ( \d+ (?: \.\d+ )* )                 (# main version number )
     [-.:\s]?(                            (# optional build number )
       \w[\d\w]* (?: [-.:\s][\w\d]+ )*
     )?
     \s?(\(                               (# optional descriptive labels in parentheses )
       [\d\w]+ (?: [-.:\s][\d\w]+ )*
     \))*
   )
   ( [*] | \s*[+] )?                      (# optional notation for half-open ranges )
 |                                    (# this matches a closed range of version numbers and attached labels )
   ((?&v))                              (# call subroutine to match the starting version number and attached labels )
   (?: \.\. | \s-\s | – )               (# closed range separator )
   ((?&v))                              (# call subroutine to match the ending version number and attached labels )
 )
This is much shorter! Note: a "subroutine" call (by name, or by absolute or relative number) is not a "backreference" to a "capture" because each "subroutine" can match distinct values (using the same subpattern defined in the subroutine) and because the value matched by the subroutine is not captured like normal parentheses: the call of a defined subroutine, or the definition of a subroutine creates only a non-capturing group. Also a PCRE subroutine never backtracks (unlike what Perl permits with its named backreferences, allowing Perl to match palindromes that PCRE cannot).
Note that (?: ... ) is also a non-capturing group: this saves memory and accelerates the matching for backtracking, it is more efficient than ( ... ) notably for repeated subgroups, but also for alternatives. And (?# ... ) is for non-significant comments (that are not matching or capturing anything).
Verdy p (talk) 04:48, 10 November 2018 (UTC)
I tested with subroutines: this works! This allows to specify lists of versions (by naming "r" the top level of parentheses above to form a list of version ranges) using the "PCRE 5.1" syntax for subroutines (i.e. defining them with (?<name> regexp) which performs a submatch, then reusing it with (?&name); note that the syntax for subroutines in regexps is a bit different in Perl and other regexp engines, and older versions of regexp engines may not have support for subroutines) :
 [\w\s]*
 (?<r>                                (# this subroutine matches one version or range )
   ( [=≤≠≥] | [<][=>]? | [>]=? | != )?  (# version comparator )
   \s*
   (?<v>                                (# this subroutine matches one version number and attached labels )
     ( \d+ (?: \.\d+ )* )                 (# main version number )
     (                                    (# optional build number )
       \w[\d\w]* (?: [-.:\s][\w\d]+ )*
     )?
     (
       (?:
         \s?\(                            (# optional descriptive labels in parentheses )
         [\d\w]+ (?: [-.:\s][\d\w]+ )*
         \)
       )*
     )
   )
   \s?( [*] | \s*[+] )?                   (# optional notation for half-open ranges )
 |                                    (# notation for closed ranges )
   (?&v)                                  (# call subroutine to match the starting version number and attached labels )
   (?: \.\. | \s-\s | – )                 (# closed range separator )
   (?&v)                                  (# call subroutine to match the ending version number and attached labels )
 )(?: \s*,\s* (?&r) )*                (# comma-separated list for other versions or ranges )
This now works with a comma-separated list of version numbers version ranges like for supported versions of Windows: "3.0, 3.1*, 95, 98, 95, 98, 98SE, 7, 8, 8.1, 10".
I just wonder if the initial words (before the comma-separated list) need to be repeated as "r" members of the list, or are implicit prefixes for all of them, so we can add "NT 4, Server 2000" in the list...). Verdy p (talk) 05:11, 10 November 2018 (UTC)
Note: there are other labeling schemes supported after the main version number (e.g. other keywords than just "build", complex notations of builds with dots/hyphens, and dates), now the regexp is also case-insensitive. I added embedded comments in the expanded PCRE syntax above (these comments and whitespaces are not needed in the property value: however this page better documents how the regexp is built). Verdy p (talk) 15:08, 22 May 2020 (UTC)

Point of time as qualifierEdit

It is a bit messy to recommend use both publication date (P577) and point in time (P585). I suggest to recommend only more precise and clear publication date (P577) and thus delete point in time (P585) from allowed qualifiers constraint (Q21510851) (and convert point in time (P585) to publication date (P577) by bot).--Jklamo (talk) 09:16, 12 February 2019 (UTC)

  • I agree, but for compatibility with existing data, "date" is still used and expected in many existing cases, even if it is ambiguous (we have various dates: dates of creation, dates of registration of rights, date of publication, date of discovery, date of start of support by a specific organization, date of end of support, date of deprecation, date of last licence terms, date of addition of additional licences, date of automatic access to the public domain, dates of porting to more systems, date of end of publication: no more licences accepted...). Verdy p (talk) 17:29, 26 September 2020 (UTC)

Please re-create this property as item propertyEdit

Because software versions should also have their items, not just strings. --117.13.95.116 06:02, 2 April 2019 (UTC)

+1 but we should indeed wait for Wikidata:Requests_for_comment/how_to_manage_software_versions consensus. --Liuxinyu970226 (talk) 11:03, 2 April 2019 (UTC)
It depends on! Some software versions are not worth to record each with its item, some are. We need both variants-- JakobVoss (talk) 20:30, 7 November 2019 (UTC)

Proposal: Clarify usage and generalizeEdit

ProposalsEdit

This property seems to be intended, from the examples, solely to indicate what versions of a specific item exists. So for example, correct usage would be Firefox (Q698) software version identifier (P348) 3.6. However it is also used quite often as Firefox 3.6 (Q2615631) software version identifier (P348) 3.6, even though it seems this is not what was intended.

There is no property proposal I am aware of so I think we need to figure out what we want from this property, but I think cannot be for Firefox 3.6 (Q2615631) software version identifier (P348) 3.6 and for Firefox (Q698) software version identifier (P348) 3.6, and I would say it should only be for Firefox (Q698) software version identifier (P348) 3.6.

I propose:

  1. We generalize the property to not just be for software
  2. We reaffirm that this property is to be used on items to indicate that the item has a version with the identifier (e.g. Firefox (Q698) software version identifier (P348) 3.6) and NOT as Firefox 3.6 (Q2615631) software version identifier (P348) 3.6.
  3. We change the label to "has version with identifier".
  4. We add usage instructions to make it clear how this should be used (i.e. not on version items but on items with versions)
  5. We constrain the property as best as possible to only allow Firefox (Q698) software version identifier (P348) 3.6) and NOT allow Firefox 3.6 (Q2615631) software version identifier (P348) 3.6.

@putnik, Verdy p: <ping project should not be used in an indented reply> Tobias1984
Emw
Zuphilip
Danrok
Bene*
콩가루
TomT0m
DrSauron
Ruud Koot
Andreasburmeister
Ilya
Toto256
MichaelSchoenitzer
Metamorforme42
Pixeldomain
User:YULdigitalpreservation
Dipsode87
Daniel Mietchen
Jsamwrites
Tinker Bell
FabC
Jasc PL
putnik
Dhx1
Tris T7
Peb Aryan
lore.mazza004
Rc1959
Premeditated
Iwan.Aucamp
LiberatorG
Primhill.Computers
FWVH (passionné d'informatique et d'électronique)
94rain
So9q
Adrijaned
Sylvain Leroux
SM5POR
Haansn08
1-Byte
Luca.favorido
  Notified participants of WikiProject Informatics <ping project should not be used in an indented reply> Tobias1984 (talk) TomT0m (talk) Genewiki123 (talk) Emw (talk) 03:09, 9 September 2014 (UTC) Ruud 16:15, 9 December 2014 (UTC) Emitraka (talk) 14:32, 14 October 2015 (UTC) Bovlb (talk) 19:10, 21 October 2015 (UTC) Peter F. Patel-Schneider (talk) 22:21, 23 October 2015 (UTC) ArthurPSmith (talk) 15:51, 5 November 2015 (UTC) Daniel Mietchen (talk) 20:53, 3 January 2016 (UTC) Harmonia Amanda (talk) 22:00, 27 February 2016 (UTC) Lechatpito (talk) Andrawaag (talk) 14:42, 13 April 2016 (UTC) ChristianKl (talk) 16:22, 6 July 2016 (UTC) Cmungall Cmungall (talk) 13:49, 8 July 2016 (UTC) Cord Wiljes (talk) 16:53, 28 September 2016 (UTC) DavRosen (talk) 23:07, 15 February 2017 (UTC) Vladimir Alexiev (talk) 07:01, 24 February 2017 (UTC) Pintoch (talk) 22:42, 5 March 2017 (UTC) Fuzheado (talk) 14:43, 15 May 2017 (UTC) YULdigitalpreservation (talk) 14:37, 14 June 2017 (UTC) PKM (talk) 00:24, 17 June 2017 (UTC) Fractaler (talk) 14:42, 17 June 2017 (UTC) Andreasmperu Diana de la Iglesia Jsamwrites (talk) Finn Årup Nielsen (fnielsen) (talk) 12:39, 24 August 2017 (UTC) Alessandro Piscopo (talk) 17:02, 4 September 2017 (UTC) Ptolusque 01:47, 14 September 2017 (UTC) Gamaliel (talk) --Horcrux (talk) 11:19, 12 November 2017 (UTC) MartinPoulter (talk) Bamyers99 (talk) 16:47, 18 March 2018 (UTC) Malore (talk) Wurstbruch (talk) 22:59, 4 April 2018 (UTC) Dcflyer (talk) 07:50, 9 September 2018 (UTC) Ettorerizza (talk) 11:00, 26 September 2018 (UTC) Ninokeys (talk) 00:05, 5 October 2018 (UTC) Buccalon (talk) 14:08, 10 October 2018 (UTC) Jneubert (talk) 06:02, 21 October 2018 (UTC) Yair rand (talk) 00:16, 24 October 2018 (UTC) Tris T7 (talk) ElanHR (talk) 22:05, 26 December 2018 (UTC) linuxo Gq86 Gabrielaltay Liamjamesperritt (talk) 08:44, 21 June 2019 (UTC) ZI Jony Ivanhercaz (Talk) 11:07, 15 July 2019 (UTC) Gaurav (talk) 22:39, 24 August 2019 (UTC) Meejies (talk) 04:38, 29 August 2019 (UTC) Iwan.Aucamp SilentSpike (talk) Tfrancart (talk) Luis.ramos.pst.ag Sylvain Leroux TiagoLubiana (talk) 15:12, 2 December 2019 (UTC) Albert Villanova del Moral (talk) 15:43, 6 February 2020 (UTC) Clifflandis (talk) 15:10, 18 February 2020 (UTC) --Tinker Bell 16:48, 23 March 2020 (UTC) SM5POR Mkbergman (talk) 19:17, 10 July 2020 (UTC) Toni 001 (talk) 11:03, 11 July 2020 (UTC) The-erinaceous-one (talk) 22:02, 31 August 2020 (UTC) Cdo256 (talk) 06:26, 8 September 2020 (UTC) Antoine2711 (talk) 17:22, 25 September 2020 (UTC) Rehman 07:15, 12 October 2020 (UTC) Susanna Giaccai (talk) 07:22, 22 October 2020 (UTC) Nomen ad hoc So9q (talk) 10:17, 4 January 2021 (UTC) Simon Cobb (User:Sic19 ; talk page) 18:29, 8 January 2021 (UTC)

  Notified participants of WikiProject Ontology

Iwan.Aucamp (talk) 13:58, 22 May 2020 (UTC)

@Iwan.Aucamp: don't spam multiple topics (seen already above). Your proposal here has nothing to do with the property constraint. You just want to restrict the use of this property for specific items created for "specific" versions, specifying the version as part of their label (so not parsable at all as it will get translated randomly): it's safer even in this case to specify a property for the version (or version range using the extended regexp syntax that supports it, and that I explained above, using simple ranges with " .. " or " - " or using "*" for matching all subversions with an upper bound excluded on the parent version, or using comparators that I also explained).
There are also other way to specify specific types of versions that an item may need to reference (e.g. an item may be created for adding new additional features of a software, or removing them, or for indicating deprecation or removal of support, or for adding specific security issues documented). But most software packages/products have a generic item listing its versions just by its list of version numbers (and some qualifiers when needed to distinguish them), and this works for almost all software packages except for specific branches for specific uses, with an independent life cycle even if it originated from a base branch, and where it is not known if these branches will ever be reintegrated into the main branch or will support"backporting" (e.g. security fixes applied in the main branch and only the few other supported branches). When the software is opensourced, generally all branches with their independent lifecycle are just a new kind of software which remains maintained by the community and not requiring any official support from the organization or developer building the main branch (and possibly evaluate the separate development of forked branches).
So I don't understand why you don't want items created for some version ranges to have their own version identifiers as properties. For me it makes no sense and this proposal is just not describing what happens in the real computing industry, that need, use, and deploy various branches of the same base software with their own features added or removed: you proposal is just to limit these possibilities, removing an essential freedom, as if all sofwares were unbreakable "bricks" without many components and various dependencies and possibly incompatibilies between optional or required features. When these incompabilities are with a "core" component, the branch can exclude some of them and resolve the incompatibilities in a different way, creating a new software with its own cycle even if it's part of the same "family". As well there are tons of abandoned branches everywhere, but that are kept as is as long as they work for the effective features that are needed in them. Verdy p (talk) 02:24, 9 September 2020 (UTC)
@Verdy p: I have no problem with item pertaining to specific versions such as Firefox 3.6 (Q2615631) having properties on them specifying their version. What I have a problem with is that this property is used both to indicate: (A) that an item has a version with the given identifier even though the item itself does not pertain to that version (e.g. Firefox (Q698) software version identifier (P348) 3.6) and (B) that an item pertains to a version with a given identifier (Firefox 3.6 (Q2615631) software version identifier (P348) 3.6). I think a better property for use to indicate that an item pertains to a given version would be edition number (P393), thus I would suggest that Firefox 3.6 (Q2615631) software version identifier (P348) 3.6 be replaced with Firefox 3.6 (Q2615631) edition number (P393) 3.6.
Following from this, if we go with what I propose .ZIP File Format Specification, version 6.3.4 (Q26211547) software version identifier (P348) 6.3.4 would be an incorrect use of this property and ZIP (Q136218) software version identifier (P348) 6.3.4 would be a more correct use of this property (though possibly not entirely correct either}).
Would you prefer this property for both cases (A) and (B), if so just vote accordingly below. I don't think ambiguity between (A) and (B) is beneficial and would prefer we constrain this to one or the other which is why I made the proposal. I think if you can raise phrase your objection with specific statements that should or should not be allowed it will make discussion easier. Iwan.Aucamp (talk) 16:26, 26 September 2020 (UTC)
I have no real preference, but if you want to absolutely make the dichotomy between instances and classes, I tend to prefer a more generic model where every object is also a class, that can be subdivided as needed. With it, we don't really represent a single version number but a range or selection of "compatible" version numbers which can be more or less precise depending on use.
Basically all software are specified within a range of compatibility specifications. Some specifications will be made later and implementations will be reclassified (subclassed) even if they still respect the initial specification for which there was a single version. This is not exceptional and in fact the most important part of human knowledge follows this paradigm, and trying to always make a dichotomy between classes and instances is not productful: instances are not needed, we just need a hierarchy of classes, even if they (most of them) are singletons (for now,; as we never know the future). The best model I can do is to make only a distinction between classes that can exist as objects for themselves: all their properties are definable, at least those that are necessary to make the class working as a black box (independantty of the subclasses seen as a variety of implementations). We can then create some specific subclasses which are "virtual" which are the only one that cannot be instanciated without specifying additional needed properties to distinguish them. We avoid like this the non-sense of "meta-classes", "meta-metaclasses", by allowing each object-class to have its own know properties, plus may be (only in virtual subclasses) some virtual properties which are not directly "instanciable" and distinguishable (comparable). This is only a hierarchy with two levels, there's no more instances and classes, only classes which are or are not comparable (on which no inference is possible except from the properties inherited from the parent class).
But here is it useful ? The current definition already allows setting a unique value when needed (restricting all derived subversions for which no derivation is then allowed, these are "final" classes). But in most cases, multiple values are possible and almost every version specifies a range of versions and almost all classes are still derivable without needing any duplicate entry for each one of its instances (in fact there are always many for any software that is published somewhere, otherwise it would not be usable by anyone else outside his own specific system for a single usage, for a limited time, a strange thing that would not have any value in Wikidata as it would have a single unmaintained source). As in Wikidata everything is modifiable and can be augmented, my opinion is that "instance of" in Wikidata has almost no use. We just need "subclass of" for everything. This is true notably for versions and does not prohibit creating derived subclasses for specific ranges, if needed to specify specific properties for such more precise subranges of versions. Verdy p (talk) 17:22, 26 September 2020 (UTC)

AmendmentsEdit

Place amendments here ... if you want to vote on an amended version of the proposal.

DiscussionEdit

  Comment this is the place to discuss this proposal - if you want to make an amendment use the amendment space and then people can vote there - if you want to make a different proposal make a different proposal. Iwan.Aucamp (talk) 16:26, 26 September 2020 (UTC)
Return to "P348" page.