Wikidata:Property proposal/Service number
Service number
[edit]Originally proposed at Wikidata:Property proposal/Person
Description | Service number given to the subject by a military organisation |
---|---|
Represents | service number (Q7455778) |
Data type | String |
Domain | human (Q5) |
Allowed values | [^\s\/]+ |
Example | Douglas Bader (Q348780) → 26151 |
Source | Various external references and historic sources |
See also | United States Armed Forces service number (P2028) |
- Motivation
A military figure's service number is intended to be an identifier for them. It is usually part of the historical record, particularly for people killed in action and buried in military cemeteries, or who received military awards. In some contexts it can even be easier to identify a person from a number than a name.
We currently have United States Armed Forces service number (P2028), but this is very narrowly defined - it only applies to US personnel under the various 1918-1974 numbering schemes. The sheer range of different schemes used over the years make it impractical to create a lot of specific-use properties like this; a more generic property would be usable on all people, perhaps with a military branch (P241) qualifier where it is necessary to clarify which numbering system was used.
This proposal comes out of a discussion on project chat last month; ping @Pigsonthewing, Jura1, Hsarrazin, Richard Arthur Norton (1958- ): who commented there or on the P2028 proposal. Andrew Gray (talk) 23:18, 4 December 2017 (UTC)
- Discussion
- How about converting "United States Armed Forces service number (P2028)" into a more general service number field? I had planned to create a bot to crawl through the United States Armed Forces service database but I never got around to learning how to create one. --RAN (talk) 23:56, 4 December 2017 (UTC)
- Support David (talk) 07:29, 5 December 2017 (UTC)
- Support, but only if we cannot a) repurpose P2028, which would be a better option (it is currently used on only eleven items; or b) use catalog code (P528)/ catalog (P972), which is logically equivalent. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:47, 5 December 2017 (UTC)
- As noted in the earlier discussion, I don't think catalog code (P528)/ catalog (P972) are appropriate - they would need us to know the qualifiers used in advance in order to write queries to find service numbers, and this wouldn't be practical. Andrew Gray (talk) 21:50, 5 December 2017 (UTC)
- Oppose I would prefer to repurpose P2028. In any case, I don't think this should be used without a qualifier as suggested in the example. ChristianKl (✉) 16:31, 5 December 2017 (UTC)
- I would also prefer to repurpose P2028, but there was opposition to that... Regarding qualifiers, I think these would probably be advisable, though perhaps in some cases a "numbering system" property qualifier would be more appropriate than P241. Andrew Gray (talk) 21:50, 5 December 2017 (UTC)
- I don't see any attempt on the talk page of United States Armed Forces service number (P2028) to start a discussion about repurposing it. ChristianKl (✉) 14:15, 6 December 2017 (UTC)
- Comment for the current sample (Douglas Bader (Q348780) → 26151) to work, the label would probably need to be "British (something) Service number". Is that consider a social security number?
--- Jura 19:37, 5 December 2017 (UTC)
- The point is that it could be a generic service number property; we could use qualifiers to indicate what it was for (in this case, the RAF). And no, it is not a social security number of any kind. Andrew Gray (talk) 21:50, 5 December 2017 (UTC)
- The example doesn't use any qualifiers. If you want to propose a way to express this information that includes qualifiers, I would advocate to use corresponding examples. ChristianKl (✉) 14:12, 6 December 2017 (UTC)
- Actually, on some level it makes sense as the proposed property isn't using "external identifier" as propertytype. There is just a risk that it ends up including social security numbers.
--- Jura 16:26, 13 December 2017 (UTC)
- Actually, on some level it makes sense as the proposed property isn't using "external identifier" as propertytype. There is just a risk that it ends up including social security numbers.
Not done, looks like repurposing United States Armed Forces service number (P2028) is preferred. − Pintoch (talk) 09:46, 10 February 2018 (UTC)- @Pintoch: Since when do we repurpose properties? Datatypes are different, does that mean we have to change it?
--- Jura 09:49, 10 February 2018 (UTC)- @Jura1: I'm just summarizing what I see above and not expressing my own opinion, trying to clean up the backlog of inactive proposals at Wikidata:Property proposal/Overview. I guess the editors above used "repurposing" to mean "broadening the scope of", which is definitely acceptable. I have no opinion about the datatype. I'm happy to reopen it though. − Pintoch (talk) 09:58, 10 February 2018 (UTC)
- Maybe you should just close it as "not done". I don't see the other aspects being addressed so you can't include it in the conclusion.
--- Jura 10:00, 10 February 2018 (UTC)- Sure, happy to do that. Closing as Not done then, without concluding anything and inviting interested editors to find out why by reading the rest of the proposal. Do you like it more this way? − Pintoch (talk) 13:30, 20 February 2018 (UTC)
- Maybe you should just close it as "not done". I don't see the other aspects being addressed so you can't include it in the conclusion.
- @Jura1: I'm just summarizing what I see above and not expressing my own opinion, trying to clean up the backlog of inactive proposals at Wikidata:Property proposal/Overview. I guess the editors above used "repurposing" to mean "broadening the scope of", which is definitely acceptable. I have no opinion about the datatype. I'm happy to reopen it though. − Pintoch (talk) 09:58, 10 February 2018 (UTC)
- @Pintoch: Since when do we repurpose properties? Datatypes are different, does that mean we have to change it?