Wikidata:Property proposal/type code

Mac OS type code edit

Originally proposed at Wikidata:Property proposal/Generic

Done: Mac OS type code (P7126) (Talk and documentation)

Description	code used formerly by Mac OS to identify file types and programs
Represents	Type code (Q9090749)
Data type	String
Template parameter	Template:Infobox file format (Q10986167)@es "type code"
Domain	file format (Q235557), software (Q7397)
Allowed values	hexadecimal (Q82828)
Example 1	Photoshop File Format (Q2141903) → "`38 42 49 4d`" ("8BIM")
Example 2	OpenType Font (Q260180) → "`73 66 6e 74`" ("sfnt")
Example 3	AutoCAD (Q83570) → "`41 43 41 44`" ("ACAD")
Source	https://www.macdisk.com/macsigen.php
Planned use	Use it in infoboxes
Expected completeness	eventually complete (Q21873974)
See also	media type (P1163)

Motivación edit

(Indica tu motivación para solicitar esta propiedad aquí). --Tinker Bell ★ ♥ 23:16, 11 July 2019 (UTC)[reply]

Discussion edit

It appears the examples used here for this property are actually "Creator Codes" , not "Type Codes". A Photoshop file, for example, would be "8BIM" as creator and "8BPS" for type. The source link shows this difference. It would also seem appropriate to create a Mac OS Creator code, so go along with this property. --Thorsted (talk) 14:51, 26 September 2022 (UTC)[reply]
Support David (talk) 04:56, 12 July 2019 (UTC)[reply]
Support --DannyS712 (talk) 12:30, 12 July 2019 (UTC)[reply]
could you add "Mac OS" or something similar to the label? Otherwise people are likely not to use it correctly. --- Jura 16:30, 12 July 2019 (UTC)[reply]
- Jura, Done --Tinker Bell ★ ♥ 17:13, 12 July 2019 (UTC)[reply]
Support - Premeditated (talk) 18:19, 13 July 2019 (UTC)[reply]
It is not clear to me from the examples what the values should really be. What do we do with the bracketed parts? Marking as not ready because of that. − Pintoch (talk) 21:21, 23 July 2019 (UTC)[reply]

The text in the brackets are the signature of where the block starts. Example: For a PSD file, we look for the byte sequence 38 42 50 53 or the ASCII sequence of 8BPS (signature). - Premeditated (talk) 08:25, 24 July 2019 (UTC)[reply]

Pintoch, Premeditated: I wrote the two representations, because I don't know how to store these values. Although many codes can be represented as ASCII, some codes can't be represented as ASCII, because they have non-printable characters. I don't know if Wikidata could store the code as hexadecimal, and show the value as ASCII too. The explain at macdisk.com says:

Signatures are often considered as strings, and the greatest part of information published on signatures is based on this assumption.

However, signatures are handled by programs as 32-bit integers, which means that when you see a filetype coded as 'TEXT', a program will see 0x54455854, or even 0x54584554, depending on whether it is big-endian or little-endian.

This is the explanation of the possible presence of spaces (very frequent) or even of cryptic characters, even of non-printable characters, in the signatures.

--Tinker Bell ★ ♥ 18:27, 30 July 2019 (UTC)[reply]

I marked this proposal as ready. I think it's fine to add either way or in both formats, and use encoding (P3294) as a qualifier to specify the representation. ArthurPSmith (talk) 20:21, 31 July 2019 (UTC)[reply]

I'm not a domain expert, but it seems very similar to Mac OS type code (P7126). Could someone check it? In case you meant the file type creator code, as suggested in the first comment, please change the description and name of the property. Thanks --Luca.favorido (talk) 02:53, 6 October 2022 (UTC)[reply]
yeah I believe this was made years ago and this proposal was simply never closed properly. BrokenSegue (talk) 03:42, 26 October 2022 (UTC)[reply]