Wikidata:Requests for comment/Datatype identifier
An editor has requested the community to provide input on "Datatype identifier" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you! |
THIS RFC IS CLOSED. Please do NOT vote nor add comments.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- Because this was started by a now indefinitely-blocked sockpuppet and the reaction to the proposal has been negative, I will speedy close this. --Rschen7754 05:00, 15 June 2015 (UTC)[reply]
Proposal[edit]
Discuss in the Wikidata Wiki before creating a new datatype and migrating properties.
A proposal to create a new datatype for properties by User:Lydia Pintscher (WMDE). It can be found at phab:T95287. It seems to mean to migrate almost all properties of datatype string, listed at Special:ListProperties/string.
Concern:
- There are already problems with the distinction between monolingualtext and string, see Wikidata:Properties for deletion P1782, P1785. Next to label and alias
- The current datatype "string" might be completely depopulated
(A) Before datatype creation is carried out:
- the datatype creation is discussed in the Wikidata Wiki
- why is another datatype necessary?
- if the value-type will be the same, could the goal be reached by using a statement on the property?
- if the datatype creation and migration is only done for technical reasons, are there no other means?
- performance: couldn't there be a cache?
(B) Before migration is carried out:
- all candidates for migration are marked in a list of all properties that are of datatype string.
- One list that could be used is Wikidata:Database reports/List of properties/datatype/string, marking could be done by a bot, based on some property, e.g. Wikidata property representing a unique identifier (Q19847637)
FreightXPress (talk) 00:33, 10 May 2015 (UTC)[reply]
Discussion[edit]
Some points have been raised already at Wikidata:Project chat#New datatype identifier - relation to datatype string - migration.
The current datatypes listed at Special:ListDatatypes are:
Datatype | Description | Type [1] |
---|---|---|
Commons media | Link to files stored at Wikimedia Commons. When a value is entered, the "File" namespace on Commons will be searched for matching files. | |
Globe coordinate | Literal data for a geographical position given as a latitude-longitude pair in gms or decimal degrees for the given stellar body. Defaults to "Earth" and then "WGS84". It adds a resolution and range. | globecoordinate |
Quantity | Literal data field for a quantity that relates to some kind of well-defined unit. The actual unit goes in the data values that is entered. | string |
String | Literal data field for a string of glyphs. Typical use are identifiers that have written forms which do not depend on the language of the reader. | string |
Time | Literal data field for a time value. Given as a time with some precision and boundaries. The time is always saved internally in the Proleptic Gregorian format, but can use other formats during parsing and formatting. | time |
URL | Literal data field for a URL. URLs are restricted to the protocols also supported for external links in wikitext. | string |
Item | Link to other items at the project. When a value is entered, the project's "Item" namespace will be searched for matching items. | wikibase-entityid |
Property | Link to properties at the project. When a value is entered, the project's "Property" namespace will be searched for matching properties. | wikibase-entityid |
Monolingual text | Literal data field for a string that is not translated into other languages. This type of string is defined once and reused across all languages. Typical use is a geographical names written in the local language, an identifier of some kind, a chemical formula or a Latin scientific name. | string |
Additionally there are properties that are of an undeclared type:
- sitelink (string/Wikimedia identifier)
- alias (~monolingual text)
- label (~monolingual text)
- description (~monolingual text)
Conceptually close are:
- Literals:
- Literal data: string [sometimes, e.g. Commons category (P373) behave similar to sitelink], monolingual text, label, alias, URL (close to links)
- not listed at Special:ListDatatypes: label, alias, description
- subgroup: Time, Quantity, globe-coordinate
- Links:
- Link to: Item, commons media, property
- not listed at Special:ListDatatypes: sitelink
FreightXPress (talk) 00:33, 10 May 2015 (UTC)[reply]
Comments[edit]
- I actually don't understand why this is a request for comment. What should we comment on? You are mainly listing things which are already clear. The technical requirements and needs for such a datatype are described in detail in the bug. The problem which arised concerning the monolingual text datatype have nothing to do with the new datatype. Introducing this new identifier datatype does not necessarily mean that the string datatype will be removed. Therefore, I really don't get the point why this requires an RFC. In my opinion RFCs should be used only for controversial things or changes to guidelines. This however rather belongs into a WikiProject or something like that. Best regards -- Bene* talk 19:19, 10 May 2015 (UTC)[reply]
- Bene* - I cannot see any discussion in the Wiki of why this new datatype is needed. Can you? The reason given in phabricator is rearrangement of statements. This can be achieved without a new datatype. The problems with monolingualtext are mentioned to demonstrate that new datatypes can create new problems. FreightXPress (talk) 18:30, 12 May 2015 (UTC)[reply]