This property should always have the following pattern: "Minimum: (ANY TEXT). Recommended: (ANY TEXT)." or "Minimum: (ANY TEXT)." It is also allowed to use wikisyntax for proper text formatting in case of external use, for example, in Wikipedia. The property should not contain any additional requirements, such as: RT Ultra, RT High, RT Medium, Ultra, Ultra 4K, High, Medium, Performance. See Cyberpunk 2077 (Q3182559) as model item. Note that if such additional requirements are found in the statements, any participant has the right to remove them in the affected items and to adjust the statement to acceptable text value, that is, to the minimum and recommended requirements. (English)
Comment: Text highlighted in yellow is wikisyntax used to bold "minimum" and "recommended" words, while <br>-tag is used to line break, making it easier to read plain text in various Wikipedias in case of external use. See an example of such a styling in the Wikidata sandbox of Russian Wikipedia. I used this item and this monolingual text property in order to display such a text. Here's what this property would look like if it were used without wiki markup. For more info see #Data type has been found, what's next?
Minimum: CPU: 1GHz or faster with two or more cores on a supported 64-bit processor or System on a Chip (SoC); RAM: 4GB; Storage: 64GB or more; System firmware (BIOS): UEFI, Secure Boot capable; TPM: Trusted Platform Module (TPM) version 2; Graphics card: DirectX 12 or later with WDDM 2.0 driver; Display: 720p display or more, 9-inches diagonally, 8 bits per color channel; Internet and Microsoft account: Windows 11 requires internet connectivity to install. (English)
Comment: In some cases, software may only have minimum requirements.
add value
Planned use
It's planned to be used to indicate minimum and recommended system requirements for video game and software-related items with a possible external use on Wikipedias.
I immediately apologize for such a long text, but in this case I had to point out a lot of important details and yes, this is the very property I was talking about. Let me explain a little how it all started and why it took so long to propose this property. Feel free not to comment right away, as it may take some time to read everything I have written.
Alright, it all started back in 2019 when I noticed that many video game-related items didn't have any information about their system requirements. I have searched for a long time for the property that might be suitable for this kind of information, but alas, nothing appropriate came up. Then at this point I decided that we needed a new separate property, which should be called "system requirements". However, right after I had this idea, I ran into a huge problem, which may not yet be completely solved, and that is actually the data type for this property. I racked my brains and spent a lot of time before settling on the monolingual text data type. Now I will try to explain why I chose this data type and what other options I have previously considered, so let's start.
It was the very first data type that came to my mind then. The fact is that for some reason it seemed to me that for system requirements this data type is what you need. At that time, I was inspired by such an idea taken from the examples in the French Wikipedia. The idea was that I create two items, one called minimum requirements, the other recommended requirements, and use qualifier properties like GPU, CPU, RAM, disk space, DirectX version, etc., some of which, by the way, are not created in Wikidata. The problem here is that all these so-called sub-properties would have to have different data types and there would be a lot of them. Especially since I'm not sure that all such properties will be approved (a recent example of an unapproved property). This is where I stopped and after a little thought I came to the conclusion that it would just be crazy to separately create so many sub-properties just for the sake of one property and in the end I threw this idea right away because it does not make any sense, and if it did, it would be almost impossible to implement such an idea. Here's what it looked like in my mind:
Comment: At first glance, this idea may seem good, but the practical implementation of such an idea is too laborious and this is far from the best option.
After a not entirely successful idea with the first option, I decided to simplify the task at times and not get bogged down. Since I saw that there were so many specifications for system requirements and unlikely to be able to indicate them somehow with items, qualifiers, or other properties not yet created in Wikidata, I decided to just switch to plain text. That is, leave everything as it is, but at the same time correctly format the text and use it in the Wikidata property, indicating the source from where the information about system requirements was taken.
Without thinking for a long time, I started looking for a new data type that would fit here and it turned out to be a string. When I tried the string version for the first time in test.wikidata, I was delighted, because it's exactly what I was looking for! The simple string here turned out to be a great option and I no longer had to worry about the data type, but after a several tests I realized that the new problems appeared, prevent this option from being considered optimal and maybe even worse than the first one. Here is what these problems are:
The property that uses a string allows you to write only in one language. This is the main reason why I had to regretfully withdraw this option. It goes against my idea that the text can be added to statements in several languages without any restriction. It was also planned that this property could be used externally in various Wikis.
String properties are not meant for ideas like mine. A quick look at this list shows that string properties are used primarily to specify different numbers or characters, but are definitely not used for a property like this. After carefully reading the description on the information page, namely that the string is used for Chain of characters, numbers and symbols that don't need to be translated into different languages or number formats. A string is not used for calculations, I had no doubts that this data type should definitely not be used, and I finally gave up on this scheme. Okay, let's move on.
After another unsuccessful idea, I never lost hope of finding a more or less correct data type. This time I decided to go through the already created Wikidata properties a bit and started looking for those properties that could meet such criteria:
property with a text string
it is possible to add text in one of the languages
no language barriers
Finally, after some searching, I found one such property that fits these criteria. I decided to look at this property and found out that it uses the monolingual text data type without any language restriction and this property is - Wikidata usage instructions (P2559). It is the most congenial property that should be used in exactly the same way as this one that I proposed. I tried to do a few tests to make sure that this time it was the right data type before moving on and yes it is! After all this time, I think it's pretty safe to say that this is currently the best option for such a property, unless there are other alternatives. Here's what it looks like to use such a property in one of the video game-related properties. Let me know in the discussion what you think about this option.
Despite the fact that after so much time I managed to find an approximate data type and I have no other options, I am still not completely sure that everyone will agree with implementation of the 3rd option, so I would be glad to listen to other participants who may have their own ideas on this matter. Moreover, the final version is only my vision, nothing more.
So, next I focused on my idea of the external use of this property. Long before I settled on the monolingual text variant, I was thinking of testing this potential property on Wikipedia, if possible. I remember that some time ago I tried to display through the Wikidata sandbox on the Russian Wikipedia the plain text containing the system requirements. I managed to get a result, but I encountered the fact that this text is displayed without any design. Here I decided that why not try using wikisyntax (if that seemed possible) in order to bold the words "minimum" and "recommended" and add a <br>-tag to move to a new line. And I succeeded, this is what it looks like with styling and it's worth noting that it's much better than it was before. Since you can add wikisyntax to Wikidata, I would like to suggest its use in this property as well, hence I would like to know what you think about it. As far as I know, wikisyntax is allowed on Wikidata. Judging by this filter, you can see how some folks are using it for images (use of wiki markup in the video game item). BTW I also use it sometimes for certain images to display hyperlinks in the Russian Wikipedia (change with wikisyntax and the result).
By standardization, I mean where should the system requirements text start and end? For instance, I came up with the following pattern: "Minimum: (ANY TEXT). Recommended: (ANY TEXT)." or "Minimum: (ANY TEXT)." That is, the text of the system requirements must always have this pattern and must not go beyond it. What do I mean by that? I mean that the pattern should not include any of these additional requirements. I think that this amount of additional requirements is extremely unjustified and we should only focus on using the minimum and recommended requirements. Why shouldn't we use additional requirements?
In most cases, there are too many of these requirements.
Specifying additional requirements along with the minimum and recommended requirements may exceed the character limit. The current maximum length is 1,500 characters. To prevent this abuse of additional requirements, I wrote the following regex, but, unfortunately, it does not work properly (works in some cases partially), so I had to give up the regex idea for now, with the hope that someone will write it better than me. To make such a regex work, it must either be completely rewritten or tweaked, otherwise not used at all.
If not regex, then how can we monitor the abuse of this property?
Since the regex is unfortunately not yet an option here, I think that we can simply use Wikidata usage instructions (P2559) property to indicate in plain text that the property should not contain such additional requirements as: RT Ultra, RT High, RT Medium, Ultra, Ultra 4K, High, Medium, Performance and many others. Values containing such additional requirements will be adjusted to an acceptable text, i.e. to the minimum and recommended system requirements. By the way, there is another more optimal solution. One can simply write a SPARQL query that will detect such violations in the {{Complex constraint}} template. Here is a sample:
#title:Items containing a specific word that should not be in the value. Sample is based on "Wikidata usage instructions (P2559) property" values.SELECTDISTINCT?affected_item?problematic_valueWHERE{?affected_itemwdt:P2559?problematic_value.FILTER(REGEX(?problematic_value,"(Ctrl\\+F|Humble Bundle store)")).#Words like "Ctrl+F" and "Humble Bundle store" shouldn't be in the values. Just an example.SERVICEwikibase:label{bd:serviceParamwikibase:language"[AUTO_LANGUAGE],en".}}
{{Complex constraint
| label = Invalid words in the values
| description = Words like: RT Ultra, RT High, RT Medium, Ultra, Ultra 4K, High, Medium, Performance should not be in the values.
| sparql = SELECT DISTINCT ?affected_item ?problematic_value WHERE {
?affected_item wdt:PXXXX ?problematic_value.
FILTER(REGEX(?problematic_value, "(RT Ultra{{!}}RT High{{!}}RT Medium{{!}}Ultra{{!}}Ultra 4K{{!}}High{{!}}Medium{{!}}Performance)"))
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
}
}}
Text styling
It should be noted that the added text first of all should be accurately formatted, so that you can not stumble on a typical case of "CTRL+C, CTRL+V". That is, instead of such a mess, something like this more neat formatting, so it is suggested to insert any but well-formed text with commas or semicolons as acceptable separators between words. Feel free to write your text styling recommendations as well.
Data type can still be a problem
As I noted above, my proposed data type may still not be what we need, so in the course of this discussion, we need to weigh all the pros and cons of my proposed idea before creating this property.
What should we do with items that have no sources?
As you can guess, we can easily come across a certain number of items that have system requirements, but no source from which they were taken. In that case, I propose to leave such values for a while, and then, if the participant who added such a value did not deign to provide a source for it, remove it. IMHO sources are more important here than ever. See the next section for more details. What do you think?
This property should always have the following pattern: "Minimum: (ANY TEXT). Recommended: (ANY TEXT)." or "Minimum: (ANY TEXT)." It is also allowed to use wikisyntax for proper text formatting in case of external use, for example, in Wikipedia. The property should not contain any additional requirements, such as: RT Ultra, RT High, RT Medium, Ultra, Ultra 4K, High, Medium, Performance. See Cyberpunk 2077 (Q3182559) as model item. Note that if such additional requirements are found in the statements, any participant has the right to remove them in the affected items and to adjust the statement to acceptable text value, that is, to the minimum and recommended requirements. (English)
Comment: citation-needed constraint (Q54554025) is required here in order to confirm where the information comes from and to avoid cases of invented, intentionally twisted/exaggerated, unofficial or taken from nowhere system requirements, which, by the way, may occur. Another strong argument here is that video game/software developers may in some cases update and subsequently change the original system requirements and that is why the source is so important here. In general terms, having a source is always helpful. What do you think?
The same goes for distinct-values constraint (Q21502410), since there are practically no cases where one value will exactly match another of the same value. Each source from which information is taken forms the text in its own way.
Once a property has been created, any additional and new constraints must be strongly argued on the property's talk page before being added. Their arbitrary addition without any discussion and consensus is highly discouraged and such actions may be declined.
Thanks for your suggestion but this falls under my very first and not good idea (see #1st option (item data type) and also my final comment on this matter). Unfortunately, the properties that we currently have are not enough. We will have to create a lot of new proposals (sub-properties for the main property, which by the way does not exist in our case, unless my proposed one), which, like the recent one, may be rejected, so this is far from the best option. Moreover, as pointed out here above, I don't think you can specify all system requirements exactly this way. In any case, thanks for your comment.
Comment This also creates redundant work for translators who have to translate the strings 'Windows 10' and 'ActiveX' every time this property is added to an item. Instead, we could use existing items with properties and only translate those strings once per language. This has the benefit of reaching many more audiences than with the proposed string format. —Tomodachi94 (talk) 07:21, 19 March 2023 (UTC)[reply]
> Could you please elaborate on what properties we are lacking (and potentially make property proposals where appropriate)? :)
Alright, we are lacking some of these (just examples; some of them are based on Doom 3 specs and some on my examples here above):
Are we really sure that all these sub-properties will be approved for just one property, if we are considering the first option?
Don't you think there will be many of them?
Wouldn't it be easier to indicate this in plain, but well-formed text, instead of creating so many properties?
> ... and the amount of needed disk space, both of which were mentioned in your proposal.
This is refering to data size (P3575). Maybe because I'm not a native English speaker, but please correct me if I'm wrong, I don't think that data size equals to disk space/free space/storage as specified for system requirements, so I think it needs a separate property.
> I recommend you do some more reading about the philosophy of Wikidata and linked data/open data in general.
I'm aware of this, but I think that such a property can be hard to adapt to the philosophy of Wikidata, and you noticed it. Everything here is more complicated than it might seem at first glance.
> This also creates redundant work for translators who have to translate the strings 'Windows 10' and 'ActiveX' every time this property is added to an item.
I'm not quite sure what translators we're talking about here, but I think you misunderstood me because you don't need to translate anything. All information about system requirements is taken from reliable sources in different languages. For instance, here's where you can find the system requirements for Cyberpunk 2077 (Q3182559) in Spanish. Text can be added to the statements in several languages without any restriction. If you want to add Spanish instead of some other language, there's nothing stopping you from doing so. This is what my idea is. Regards Kirilloparma (talk) 07:21, 22 March 2023 (UTC)[reply]
Thanks for compiling this list of missing properties. I think audio system (P7501) can be used for audio cards ; "Web browser used", "APIs used" and BIOS could use depends on software (P1547) with qualifiers (although that might become a bit messy eventually) ; Not too sure "internet connection" − at first I thought it was a data transfer speed requirement (and data transfer speed (P6711) would apply?) but looking at the Doom example, it would be item-based Internet or LAN − if yes that’s I think less of a system requirement and more of a advanced modelling for game mode (P404)? As for RAM and disk space, yeah pretty sure there would be the argument to use storage capacity (P2928) for both, but that can be discussed. Jean-Fred (talk) 08:19, 22 March 2023 (UTC)[reply]
Comment For the long strings - absolutely not, that is not structured data. However, these data points are important and we should include them in some way if they are written somewhere. -wd-Ryan (Talk/Edits) 23:06, 18 March 2023 (UTC)[reply]
Per Tomodachi94, parts of these requirements can already be modeled. Instead of one big property we should make properties for the missing parts. -wd-Ryan (Talk/Edits) 23:07, 18 March 2023 (UTC)[reply]
> For the long strings - absolutely not. In this case the string is not long because it does not reach 1,500 characters for a single value according to the documentation. It is worth noting that many other monolingual text properties including Wikidata usage instructions (P2559) are used in exactly the same way as this proposed property. There are also specific suggestions on what to do if the property is misused (see #Still unresolved issues). In any case, the length of the string is not the really problem here.
> that is not structured data. Let me disagree with this. System requirements are crucial part of any successful software development process. By the way, you noted in your own comment that such data is important, so I disagree with your statement.
> Per Tomodachi94, parts of these requirements can already be modeled. Instead of one big property we should make properties for the missing parts. Modeled, but how? You and Tomodachi94 have suggested another option so far, but without any specifics. I can't guess what we're talking about if there are no specific examples. BTW in the comment to Tomodachi94 and in the property proposal, I have already explained why we should use the monolingual text data type and not the item variant or similar. I also explained there why Tomodachi94's suggestion would not work. My advice is to take your time and read the text of this proposal more carefully. Don't worry, I'll wait. Regards Kirilloparma (talk) 06:00, 19 March 2023 (UTC)[reply]
Hello, for the record I agree that we should include this type of information.
By "not structured data", I meant that it cannot be easily queried and used in other ways. If we wanted to display just the GPU, for example, it would be tedious and inconsistent to extract it from the long string. This is why I don't think that should be the option we pick. Wikidata usage instructions (P2559) is fine in my opinion because its only purpose is to clarify things to human editors and isn't really useful for anything else.
It would be best to have separate properties for each requirement, with a qualifier for "minimum" or "recommended", and references to where it is stated. This would also make it multilingual. I'm willing to help propose other properties if we coordinate.
> By "not structured data", I meant that it cannot be easily queried and used in other ways. If we wanted to display just the GPU, for example, it would be tedious and inconsistent to extract it from the long string.
I agree with that, and I really wish there was an option so you could have structured data, but as you can see it's not that simple.
> Wikidata usage instructions (P2559) is fine in my opinion because its only purpose is to clarify things to human editors and isn't really useful for anything else.
> It would be best to have separate properties for each requirement, with a qualifier for "minimum" or "recommended", and references to where it is stated. This would also make it multilingual. I'm willing to help propose other properties if we coordinate.
Copy that. Well, let's see what comes out of this and what others have to say. Simply to let you know, I abandoned the first option as soon as I realized that the implementation of such an idea requires a lot of work and this is far from being an perfect option. Regards Kirilloparma (talk) 07:23, 22 March 2023 (UTC)[reply]
Comment This is a very interesting proposal, thanks for putting it together! System requirements were never something I cared much about so I would never have thought of it ; but I agree this is a data point worth recording. Let’s look at what others do
I’m aware of two academic data models for video games
Core Metadata Schema for Cataloging Video Games (Q117086356) records “System requirements” as Detailed information about the system requirements, additional requirements, peripherals, or anything needed to play the game beyond the simple statement of platform. In some schemas, this note may include the platform statement. It’s text, but the values are separated for the mapping to Schema.org.
Video Game Metadata Schema (Q61572854) records “System requirements” (both minimum and recommended), defined as Hardware, firmware, and/or software components that are prerequisites for running the video game on a particular platform (There’s also “Special Hardware” (both required and recommended) defined as The additional hardware devices that are recommended or required for playing the video game (e.g. motion controller; gaming headset).) The schema description (both PDF and web-based have one “System requirements” entry, but it’s split in two properties in the OMR. It appears to be free-form text.
Stores will have a section for it, like Steam (example) or GOG (example)
Sooooo, wile I do agree that we should record this data point, I don’t agree with the conclusion that we should do it using monolingual text. I did read through the proposal and the conclusion but that does not seems unsurmontable to me. 1/ Wikidata is linked data, so we really avoid semi-structured text ; 2/ I am no specialist, but looking around, seems like it mostly boils down to a handful of dimensions: OS, CPU/CPU class, RAM, Storage, GPU/GPU class or more generally hardware, and software (DirectX etc.). That’s what Schema.org and most databases seem to do (MobyGames throws in “Minimum DVD-ROM Drive Speed Required” but well :D) so I don’t think it would need to be that many properties.
For me the question is whether we should have a “System requirements” property as “1st option” ; or whether we should not and rather model that as something like
Thank you for this suggestion. So, as far as I can see it fits the current modeling scheme for hardware items. Here's an example. That would be kind of okay (I guess), but with the PS5 example here, I don't like the way the properties are scattered all over the place. I wish they were somehow grouped together and I have an idea for that. What if we create a separate section for system requirements? That is, we have a "statements" section and a "properties" section for items, while the properties have a "statements" section and a "constraints" section, respectively (here is how it should look like). Do you think it would be possible to do this through some kind of module in Wikidata? If so, that would be great! By the way, maybe we can just create some kind of custom script for this, if that's possible. What do you think? In any case, if we come to the conclusion that it would be better to create some separate properties, we can try that, but I'm not sure how to indicate that these are system requirements, and not something else?
Answers to a couple of questions:
> For me the question is whether we should have a “System requirements” property as “1st option”
Since I'm very skeptical about my not-so-successful first option, so the answer here is more no than yes.
> (That would raise more data modeling questions (do we model CPU (“2GB”) or CPU class (“Pentium XYZ”)?
Ideally, both should be modeled
> Do we need dedicated RAM/storage properties like Schema.org does, or shall we make do with memory capacity (P2928)?
Yes, we need to create separate properties.
> How would we use depends on software (P1547) with smth like directX − use software version identifier (P348) as qualifier, or have items for each version? etc.)
What if we just had "minimum required CPU", "minimum required OS", "minimum required RAM", "minimum required GPU", "minimum required storage speed", and "minimum required software" main-value properties so that we didn't have to mess with all of this qualifier stuff? Lectrician1 (talk) 21:44, 20 March 2023 (UTC)[reply]
Hmm.. I don't think that's what we need. Let's better focus on this property for now and try (at least) to choose the right data type for it, since as far as I can see it is still a problem. The data type is the main (nightmare) reason it took me 3+ years to propose this property. I'll try to answer the rest tomorrow. Regards Kirilloparma (talk) 06:10, 21 March 2023 (UTC)[reply]
But this is less of a property proposal and more of a data-modeling discussion/decision: how can we best model system requirements? It might be using a dedicated property (as you proposed here) or it might be using a set of 2x3 or so top-level properties (as suggested by Lectrician) (or it might be using 4 properties like schema.org does etc.). Jean-Fred (talk) 09:41, 21 March 2023 (UTC)[reply]
Please notice that a sofware can have different recommended system requirements (RSR). The RSR for running Wikibase (Q16354758) with 10k items is different than the RSR for running Wikibase with the (currently) 92M items of Wikidata. A video game can have RSR for
I agree the monolingual text proposal is very non-Wikidata-ish and I don't think will fly. I don't have strong opinions on this but I think the above ideas for adding several new main statement properties would be best. ArthurPSmith (talk) 20:41, 21 March 2023 (UTC)[reply]
Comment: At first glance, this idea may seem good, but the practical implementation of such an idea is too laborious and this is far from the best option.
Oppose, I feel this has too broad of a scope to be useful. Why should we use this instead the properties we already have? For example, operating system (P306), depends on software (P1547) (potentially with software version identifier (P348) as a qualifier), data size (P3575) (probably on specific versions) and platform (P400)? —Tomodachi94 (talk) 21:42, 18 March 2023 (UTC)
Not done, no consensus of proposed property at this time based on the above discussion. Regards, ZI Jony (Talk) 07:30, 7 March 2024 (UTC)