Wikidata:Property proposal/extension of

extension of edit

Originally proposed at Wikidata:Property proposal/Natural science

Not done

Description	A file format or a piece of software can be extended to serve additional purposes. This property would allow us to specify such relationships between items in Wikidata.
Represents	software (Q7397)
Data type	Item
Domain	software, file formats
Allowed values	instances of software, instances of file format
Example	UTF-8 (Q193537) extension of ASCII (Q8815) Broadcast Wave Format (Q922446) extension of Waveform Audio File Format (Q217570)
Planned use	I would like to use this property to connect some software items and to connect some file format items.
See also	based on (P144)

Motivation

The defunct Global Digital Format Registry had a similar property to model what software is an extension of a previous piece of software. This is a different relationship than what we model with based on (P144) because here some of the code is shared between the two, the extended piece also contains additional code. YULdigitalpreservation (talk) 13:51, 22 September 2017 (UTC)[reply]

Discussion

WikiProject Informatics has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead. YULdigitalpreservation (talk) 15:33, 22 September 2017 (UTC)[reply]

Comment The distinction with based on (P144) is not entirely clear to me, can you elaborate a bit? The distinction should really be clear cut, otherwise we end up debating a lot over which one is appropriate (for instance occupation (P106) and position held (P39) are already too close to my taste, even if I understand the difference). − Pintoch (talk) 16:24, 22 September 2017 (UTC)[reply]

Comment Is it a relation as strong as subclass of (P279) ? I mean, if any ascii file is also valid utf8 and we assimilate the utf8 class to the set of all utf8 files then subclass of fits. author TomT0m / talk page 10:14, 25 September 2017 (UTC)[reply]
Support ديفيد عادل وهبة خليل 2 (talk) 15:58, 1 October 2017 (UTC)[reply]
~~Support~~ I feel that it's good to have this as a separate property from "subclass of" ChristianKl (talk) 22:40, 11 October 2017 (UTC)[reply]
Oppose I can't think of any case where this would be better than based on (P144). That property is already used for file formats and software, for example Extensible Markup Language (Q2115) based on (P144) Standard Generalized Markup Language (Q207819), LaTeX (Q5310) based on (P144) TeX (Q5301), Ubuntu (Q381) based on (P144) Debian (Q7593) etc. We could add "extension of" as an alias for P144 if necessary (it already has "extended from" in English). ArthurPSmith (talk) 18:03, 12 October 2017 (UTC)[reply]

I didn't know we had based on (P144). I agree that's better, so

Oppose. ChristianKl (talk) 18:25, 17 October 2017 (UTC)[reply]

@YULdigitalpreservation: What do you think about using based on (P144) here? ChristianKl (talk) 14:19, 22 October 2017 (UTC)[reply]

@YULdigitalpreservation, ArthurPSmith, ديفيد عادل وهبة خليل 2, TomT0m, Pintoch: Not done, use based on (P144). ChristianKl (✉) 21:29, 13 November 2017 (UTC)[reply]

Comment @YULdigitalpreservation, ArthurPSmith, ديفيد عادل وهبة خليل 2, TomT0m, Pintoch, ChristianKl: The problem of using based on (P144) is that for file formats, we need to be able to infer that if format A based on (P144) format B, an instance of format A is also a valid instance of format B. As based on (P144) is used too broadly, we cannot infer this (e.g., Turtle (Q114409) based on (P144) N-Triples (Q44044) but a Turtle file is not a valid N-Triples file - it's the contrary in fact -, or MPEG-1 (Q336284) based on (P144) JPEG (Q2195), but an MPEG-1 file is not a valid JPEG file).--Dipsode87 (talk) 10:05, 16 November 2017 (UTC)[reply]
I removed the "Not done". If you want to define this property to give that gurantee, I think that gurantee should be clearly expressed in the description. ChristianKl (✉) 12:28, 16 November 2017 (UTC)[reply]
@Dipsode87: Well that was definitely NOT clearly explained in this proposal, and the examples don't fit your case - a UTF-8 file is NOT (generally) a valid ASCII file (but the reverse is true if you limit ASCII to the original 7-bit variety at least). I think if that is what is needed, it would be best to start off with a clear new proposal, with a name something like "format compatible with" and be very specific about the meaning. ArthurPSmith (talk) 15:04, 16 November 2017 (UTC)[reply]
@YULdigitalpreservation, ArthurPSmith, ChristianKl: OK, I see. In this case, based on (P144) should be used for extensions of software / file formats, and we will prepare a new proposal (something like "restriction") for our use case for file formats. --Dipsode87 (talk) 12:59, 22 November 2017 (UTC)[reply]
I retagged it as "Not done". @YULdigitalpreservation, ArthurPSmith, Dipsode87: ChristianKl (✉) 13:41, 22 November 2017 (UTC)[reply]