Wikidata:Property proposal/code

code

   Done: code (P3295) (Talk and documentation)

Description	code used to represent a specific concept in a given encoding
Data type	String
Domain	item
Allowed units	String
Example	a (Q25702467) → 97 (Qualifier Encoding: ASCII (Q8815)) voiced velar approximant (Q1054261) → j<vel> (Qualifier Encoding: Kirshenbaum (Q939066))
See also	Wikidata:Property proposal/encoding

Motivation

It would be great if all the information in the infobox in en:Voiced velar approximant could be stored in Wikidata. This suggestion tries to be generally reusable in different context.

I add an additional property for `encoding` to be used along with this property. ChristianKl (talk) 20:14, 8 July 2016 (UTC)

Discussion

•  Comment added to Wikidata:Property proposal/Generic today only.
  --- Jura 07:42, 26 August 2016 (UTC)
•  Comment Looks like something that could replace all the authority control properties not used as qualifiers. --AVRS (talk) 08:32, 28 August 2016 (UTC)

Given that authority control properties have formatter urls I wouldn't use this solution for them. ChristianKl (talk) 09:57, 31 August 2016 (UTC)

OK, but "potentially have formatter urls". --AVRS (talk) 11:47, 31 August 2016 (UTC)

•  Support I thought we had something like this already but the closest I could find was Unicode character (P487) which is quite different. This definitely would be good to get into wikidata. I don't think it replaces external identifiers which are primarily a sort of site link to external websites. ArthurPSmith (talk) 19:04, 30 August 2016 (UTC)
•  Oppose I don't think I'll support this as this is like an open window to import everything and nothing, so I can smell conflicts on which codes are worth using or not. The description is really light. I'd prefer a per-code approach, like we have for IDs. author  TomT0m / talk page 19:56, 12 October 2016 (UTC)

  to be more specific, take the ascii code. The string has to be understood as a decimal coded number ... this is really NOT obvious and code could as well be given in hex. As a result the string has to come with extra information to be interpreted correctly. I'd prefer this to be specified with a proper property. author  TomT0m / talk page 20:01, 12 October 2016 (UTC)

I created the property despite TomT0m opposition because it only expresses concerns about potential drawbacks of the proposed usage of the code (P3295) property and the associated encoding (P3294) qualifier.

@ArthurPSmith:, @ChristianKl:, @Jura1:, @AVRS:, @TomT0m: the property was created. Dachary (talk) 09:25, 16 October 2016 (UTC)

@Dachary: I'm not satisfied with this creation. Not because the property was created but because we're on a tight on the number of votes and that I made alternative (that may be complementary to this proposal) that are still under discussion ... Clearly the point where we reached a stable state in the discussion is not reached. author  TomT0m / talk page 09:42, 16 October 2016 (UTC)

For reference : Wikidata:Property proposal/ASCII code and Wikidata:Property proposal/has code.

For relation, I want to once again repeat my concerns with the current property proposal process : this is too low level. The point is not to create property to create property, it's to find good ways to represent something that may involve properties, qualifier, items and so on. The workflow of property proposal is ill adapted to that as it totally can resort in an inconsistent decision on proposals that are supposed to work together, one accepted, the other rejected. My proposal would be to totally change the workflow : First phase : I want to be able to represent the character encoding. Second step : we discuss a model and agree on a set of properties. Third step : we create all at once. author  TomT0m / talk page 09:55, 16 October 2016 (UTC)

The discussion went on for several weeks with no opposition. For this reason alone the property could have been created some time ago because of this consensus. You entered the debate at a late stage and your opposition did not demonstrate a problem that would have justified re-opening the discussion. Although I find merits in what you suggest regarding the property creation process, it is outside of the scope of this property creation. Dachary (talk) 11:54, 16 October 2016 (UTC)

• If I understand correctly, you consider my opinion invalid because of the timing ? If it's really this, this should be made clear. your opposition did not demonstrate a problem that would have justified re-opening the discussion This opposition de facto reopened the discussion and triggered alternative proposals that triggered their own. You can't just go back in time and do as it did not happen. This is a receipe for a potention proposition of deletion because of badly closed discussion. Imho you should have commented on this and leave the property creation to another contributor if you have such a strong opinion on wether or not my comment was enough to re-open the discussion or not. author  TomT0m / talk page 13:08, 16 October 2016 (UTC)

Since we seem to disagree on how I handled this property creation despite my best efforts to explain the rationale, I'll wait for other property creators to comment. Dachary (talk) 13:53, 16 October 2016 (UTC)

I think "encoding" should come first, and "code" be its qualifier, because you should first say that the item can be encoded with encoding X, then say how (maybe there is more than one way to). --AVRS (talk) 19:24, 16 October 2016 (UTC)