Wikidata:Property proposal/Type properties
Jump to navigation
Jump to search
Properties for nomenclatural types[edit]
Name-bearing type[edit]
Originally proposed at Wikidata:Property proposal/Natural science
Not done
| Description | The name/identifier for this species' type |
|---|---|
| Represents | type (Q3707858) |
| Data type | String |
| Domain | taxa |
| Example |
|
| Expected completeness | always incomplete (Q21873886) |
| See also | taxonomic type (P427) |
Nature of type[edit]
Originally proposed at Wikidata:Property proposal/Natural science
Not done
| Description | Identify which subcategory of type this species has, only as subproperty |
|---|---|
| Represents | type (Q3707858) |
| Data type | Item |
| Domain | item |
| Allowed values | holotype (Q1061403), lectotype (Q2439719), neotype (Q19353453), epitype (Q55195035) |
| Example | Solanum africanum (Q17400483) → Dillenius, Hort. Eltham. 2:365, t. 273, f. 352. 1732 → lectotype (Q2439719), s.c. s.n. (Dill-HE 273-352) → epitype (Q55195035) |
| Expected completeness | always incomplete (Q21873886) |
Motivation[edit]
These two properties allow for the entry of data about type specimens for species and infraspecific taxa (subspecies, varieties etc.), which is actually more crucial to defining taxa than any other data we currently have. All other elements that "Name-bearing type" would need can be handled in a straightforward manner with existing properties:
- Holding institution: collection (P195) (possibly in combination with object named as (P1932) as they are usually abbreviated)
- Type locality: location of discovery (P189)
- Author and place of designation (for all types other than holotype): this would require slight adjustments to taxon author (P405) and P5326 (P5326), but as nomenclatural acts (i.e. whose date is important for priority) being governed by the same codes as species descriptions, there is in my opinion no reason to create separate properties for this. Plus it might lead to a shorter name for P5326 (P5326) that is less likely to overflow into the name of the subproperly directly below it, currently a frequent occurrence.
Also note that the proposed CETAF id above could make use of Nature of type for describing what the specimen is (the proposal currently doesn't include an actual way to do that).
Circeus (talk) 20:43, 7 October 2018 (UTC)
Discussion[edit]
WikiProject Taxonomy has more than 50 participants and couldn't be pinged. Please post on the WikiProject's talk page instead.
- I think it would be helpful if the labels indicated that these properties are for species. Yair rand (talk) 19:01, 9 October 2018 (UTC)
- Actually types apply to all ranks (at least in 'botany'), not just species. – The preceding unsigned comment was added by Brya (talk • contribs) at 10:51, 13 October 2018 (UTC).
Oppose We have taxonomic type (P427). --Succu (talk) 21:38, 12 October 2018 (UTC) PS: An new qualifier designated by (LT) is probably more valuable. --Succu (talk) 22:13, 12 October 2018 (UTC)
- Taxonomic type is explicitly intended for type species/genus and are of a different data type. You literally cannot assign a type with taxonomic type (P427) without creating an item for the individual specimen first. That is hardly a practical approach. If you want to expand a property, expand taxon author (P405) to handle all types of nomenclatural acts, as I explicitly suggested above. Circeus (talk) 00:26, 13 October 2018 (UTC)
- So what? This project tries to provide structure data, not plain strings. Structured authorship and references to nomenclatural acts (ICZN) are working well, but are needing a lot more of knowledgeble contributers. --Succu (talk) 22:02, 13 October 2018 (UTC)
- Taxonomic type is explicitly intended for type species/genus and are of a different data type. You literally cannot assign a type with taxonomic type (P427) without creating an item for the individual specimen first. That is hardly a practical approach. If you want to expand a property, expand taxon author (P405) to handle all types of nomenclatural acts, as I explicitly suggested above. Circeus (talk) 00:26, 13 October 2018 (UTC)
Comment These are two separate proposed properties, and it would be better to have two separate discussions.
- the first touches on the perennial question if it is handy to have two separate properties (one with datatype string, and one with datatype item) for the same feature. This would also be handy for synonyms (not all synonyms are notable). I guess a string property for nomenclatural types may work, but it could also cause problems, depending on how it is used. Separate items are safer, but a lot more work. I guess I could be talked into either approach (and in the long run either approach may prove to be wrong). - Brya (talk) 10:50, 13 October 2018 (UTC)
- the second would probably be useful, but if Wikidata has separate items for types, this had best be a statement, and if Wikidata allows strings for types, it needs to be a qualifier.
- a property for "designated by" (LT, NT, EP) may be useful also. - Brya (talk) 10:56, 13 October 2018 (UTC)
- marking this as
Not done given that the discussion has stalled without support − Pintoch (talk) 20:36, 6 March 2019 (UTC)
