Wikidata

Wikidata:Property proposal/Non volatile storage capacity

< Wikidata:Property proposal

Non volatile storage capacity edit

Originally proposed at Wikidata:Property proposal/Generic

   Not done
Descriptiontotal capacity of a type of memory used in electronic devices
Data typeQuantity
Allowed unitsyottabyte (Q79752), zettabyte (Q79747), exabyte (Q79745), petabyte (Q79744), terabyte (Q79741), gigabyte (Q79738), megabyte (Q79735), kilobyte (Q79726), byte (Q8799), bit (Q8805), kibibyte (Q79756), mebibyte (Q79758), gibibyte (Q79765), tebibyte (Q79769), pebibyte (Q79774), exbibyte (Q79777), zebibyte (Q79779), yobibyte (Q79781),
Example 1BeagleBone Green (Q95689317) : has part(s) (P527): embedded MultiMediaCard (Q11054432): Qualifier: Non volatile storage capacity: 4GB
Example 2ThinkPad X200 (Q51954707): has part(s) (P527): hard disk (Q4439): Qualifier: Non volatile storage capacity: 160GB, has part(s) (P527): hard disk (Q4439): Qualifier: Non volatile storage capacity: 250GB
Example 3W25X64 (Q95770455): Qualifier: Non volatile storage capacity: 8192 KiB
Example 4floppy disk (Q5293): Qualifier: Non volatile storage capacity: 1,440 kilobyte, 1,200 kilobyte , etc.
Planned useConvert what I can to use non volatile storage capacity when it's used both for RAM and storage like iPhone 8 Plus (Q39598190), ThinkPad X200 (Q51954707), etc, and where I'm sure that the device doesn't have 160G of RAM but instead 160G of storage, and start adding it to device I know about like the BeagleBone Green (Q95689317) which has a 4GB eMMC storage.
Expected completenesseventually complete, (might be approximate for formats like DVD9 or CDR 60 or CDR 90)
See alsomemory capacity (P2928)

Motivation edit

  Comment The reason for this is because memory capacity (P2928) has been renamed. --Haansn08 (talk) 10:48, 5 June 2020 (UTC)[reply]
  • There is no way to indicate how big is some storage (eMMC, HDD, etc)
  • Having that information is very useful in case of soldered storage like eMMC.
  • The previous attempt used ROM in the name and was rejected only because of that.
GNUtoo (talk) 05:16, 30 May 2020 (UTC)[reply]

Discussion edit

While it could also work in theory, I'm not comfortable with a single property as I think it's prone to confusion in practice:
  • The iPhone 7 (Q26831164) used the same property for the RAM and the storage, without expliciting which component stores that data. The people that adds such information do not necessarily know the type of the component (NAND, eMMC, eSD, etc) and in some cases it may not be possible to know (historical computers that have been destroyed, fictitious computers that comes from science fiction, etc).
  • There is a limited depth in properties of properties. For instance a GT-I9300 (Q83637336) has an eMMC that is well known due to bugs affecting its firmware. That eMMC is like a computer with its own CPU (which runs ARM instructions if I recall well), and most probably has a cache and some RAM. SSD and HDD also have a processor, and some RAM.
GNUtoo (talk) 23:49, 3 June 2020 (UTC)[reply]
If absolutely nothing about the hardware is known one could use
For GT-I9300 (Q83637336):
--Haansn08 (talk) 20:28, 4 June 2020 (UTC)[reply]
Thanks. Now that we know it can work in theory, my remaining concern is if people will always take an extra step to think about how to do it and really do it this way. Do you have any idea how that could work in practice? Could that concern really be an issue in practice? Are there bots or other ways to warn people or to help people doing the extra steps? And do you have any idea of the downsides of the approach I proposed? or the advantages of your approach? Does your approach enable more advanced querries? GNUtoo (talk) 22:25, 4 June 2020 (UTC)[reply]
I think having more general properties is of advantage. I do see why one would want to use the properties non-volatile storage capacity and volatile storage capacity on say a smartphone model. But this distinction really comes from the different components built into the phone, so I think it's also natural to use applies to part (P518). Probably the best method we have to stop people from messing things up are property constraints, for example, to require an applies to part (P518) seperator if multiple storage capacity values are present.
Other statements could be
Montecito (Q864328)storage capacity24 MBapplies to part (P518)L3 cache (Q28972917)
instead of creating a L3 cache size property. We also know the statement refers to volatile memory, because L3 cache (Q28972917)subclass of (P279)volatile memory (Q496533).
--Haansn08 (talk) 10:14, 5 June 2020 (UTC)[reply]
This could work. What do you think of using memory capacity. Also in that case we might want to require applies to part (P518) by default, always, and not just if there are multiple memory capacity values. Otherwise people could only add one memory capacity, and in that case we wound't be able to distinguish between RAM and storage devices. If a device has a memory capacity of 4GiB, I won't be able to know if it's the RAM or eMMC. My next question would be how your proposal could be implemented? I don't know how to do that. Also I don't have the use case right now, but it might be interesting to support virtual storage (like 2 SSD of 500G for instance), but there is probably a trick for that with memory capacity that would applies to part (P518) to the whole device or something like that. GNUtoo (talk) 05:43, 8 July 2020 (UTC)[reply]
  Comment I just learned the property memory capacity (P2928) was storage capacity originally, but has been renamed without discussion (as far as I can tell). I have reverted this change for now. --Haansn08 (talk) 10:55, 5 June 2020 (UTC)[reply]

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

Rationale for the ping: General computer hardware

Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Non_volatile_storage_capacity&oldid=1348222121"