Wikidata:Property proposal/restriction of

restriction of

Originally proposed at Wikidata:Property proposal/Generic

   Not done

Description	file format A is a restriction of file format B if all instances of A are also instances of B, but instances of B are not necessarily instances of A.
Data type	Item
Template parameter	en:Template:Infobox file format extended from
Domain	file format (Q235557)
Allowed values	file format (Q235557)
Example 1	GeoTIFF (Q1502796) → TIFF (Q215106)
Example 2	EPUB 3 (Q27196933) → ZIP (Q136218)
Example 3	Portable Document Format/Archive, version 1 Basic (Q26543628) → Portable Document Format, version 1.4 (Q26085326)
Source	http://hul.harvard.edu/gdfr/documents/GDFR-Format-Model-and-Relationship-1_0_7.rtf
Planned use	Populate this property with information from the extended_from infobox parameter (after careful examination, because the meaning of this parameter is often misunderstood).
See also	based on (P144)

Motivation

This proposal is derived from a rejected "extension of" property proposal.

For digital preservation, we need to know when a file of format A is also a valid instance of format B (see http://hul.harvard.edu/gdfr/documents/GDFR-Format-Model-and-Relationship-1_0_7.rtf, section 3.2). The property based on (P144) is related but broader (for example, EPUB 3 (Q27196933) is a restriction of ZIP (Q136218), but it is also based on (P144) Extensible HyperText Markup Language (Q166074) and Cascading Style Sheets (Q46441).  – The preceding unsigned comment was added by Dipsode87 (talk • contribs) at 10:24, September 13, 2018‎ (UTC).

Discussion

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

•  Support. YULdigitalpreservation (talk) 12:56, 13 September 2018 (UTC)
•  Support. Toto256 (talk) 13:02, 13 September 2018 (UTC)
•  Support Nice and clear proposal, thanks. ArthurPSmith (talk) 20:14, 13 September 2018 (UTC)
•  Support John Samuel (talk) 17:18, 14 September 2018 (UTC)
•  Support David (talk) 09:41, 15 September 2018 (UTC)
•  Comment as this seems to be meant for file formats, I added that in the description. --- Jura 10:45, 15 September 2018 (UTC)
• I think it would be helpful if the label was more specific, to avoid misuse. --Yair rand (talk) 19:54, 17 September 2018 (UTC)
•  Support Dhx1 (talk) 23:46, 29 September 2018 (UTC)

 Comment_It seems to me that subclass of (P279) can definitely do the trick. If all files within a subformat are also valid superformat files, then if any file which conforms to the format is an instance of it the restricted subformat is definitely a subclass of its parent. This make sense if you consider the definition of the format as a « class expression » that defines the properties shared by its instances. So I’d tend to  Oppose. author  TomT0m / talk page 13:26, 3 October 2018 (UTC) Note that the definition is the same than subclass of (P279) and we should not multiply the number of typing properties. author  TomT0m / talk page 13:28, 3 October 2018 (UTC)

• @Dipsode87, YULdigitalpreservation, Toto256, Jsamwrites, Dhx1: can you respond to TomT0m's query why not to use subclass of (P279)? ArthurPSmith (talk) 17:59, 3 October 2018 (UTC)
• @ArthurPSmith, TomT0m, YULdigitalpreservation, Toto256, Jsamwrites, Dhx1: I’m wondering whether declaring file formats items as both instances of file format (Q235557) and subclasses of instances of file format (Q235557) wouldn’t contradict TomT0m’s assertion “classes (of individuals) should never be subclasses of oher things than classes (of individuals), classes of classes (of individuals) should never be subclasses of oher things than classes of classes (of individuals), ... This implies that an instance of something can never be a subclass of the same thing, either directly or following a subclass chain.” (https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Are_colors_instance-of_or_subclass-of_color)... But if it’s not the case, using subclass of (P279) could be a good option. --Dipsode87 (talk) 10:12, 5 October 2018 (UTC)

  @Dipsode87: It’s not the case. If a file format is a subclass of file, you get

  ⟨ JPEG ⟩ subclass of (P279) ⟨ file ⟩

  ,

  ⟨ XML ⟩ subclass of (P279) ⟨ file ⟩

  ,

  ⟨ Atom ⟩ subclass of (P279) ⟨ XML ⟩

  . Then no class format is a subclass of « file format », neither « file format » is a subclass of « file ». You instead get « file format » as a metaclass of file :

  ⟨ XML ⟩ instance of (P31) ⟨ file format ⟩

  ,

  ⟨ JPEG ⟩ instance of (P31) ⟨ file format ⟩

  and so on. You then never get an instance of a class that is also a subclass of that file. author  TomT0m / talk page 10:55, 5 October 2018 (UTC)

  @TomT0m: OK, that seems a reasonable option. --Dipsode87 (talk) 11:35, 5 October 2018 (UTC)

• Given the present name and description it's likely that this property will be used outside of it's scope. Can we find a name that's more clear about the scope? ChristianKl ❪✉❫ 14:26, 12 December 2018 (UTC)

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

•  Comment We could consider "restriction of format" for the label. YULdigitalpreservation (talk) 15:37, 12 December 2018 (UTC)
  • Or we could just use « subclass of (P279)  ». author  TomT0m / talk page 15:40, 12 December 2018 (UTC)
•  Oppose Like TomT0m, I think a simple instance of (P31) should be enough. --Giovanni Alfredo Garciliano Díaz ★ diskutujo 19:56, 12 December 2018 (UTC)
•  Comment Both options (rename it "restriction of format" or use instead subclass of (P279)) seem fine (but not instance of (P31)!). --Dipsode87 (talk) 14:49, 15 April 2019 (UTC)
  • @Dipsode87: I'm marking thia property proposal as  Not done, may use subclass of (P279). Regards, ZI Jony ^(Talk) 13:44, 13 May 2019 (UTC)