Wikidata:Property proposal/century fl.
Jump to navigation
Jump to search
century fl.
[edit]Originally proposed at Wikidata:Property proposal/Person
Withdrawn
Description | century or centuries in which a person was known to be alive |
---|---|
Data type | Item |
Domain | human (Q5) |
Allowed values | items such as 15th century (Q7018), i.e. direct instances of century (Q578) |
Example 1 | Edgar Leopold Layard (Q553155) → 19th century (Q6955) |
Example 2 | Edgar Leopold Layard (Q553155) → 20th century (Q6927) |
Example 3 | Anna Fugger (Q58264807) → 15th century (Q7018) |
See also | date of birth (P569), date of death (P570), date of baptism (P1636), date of disappearance (P746), floruit (P1317) |
Motivation
[edit]Notified participants of WikiProject Q5
While it's possible to compute this from a series of possible properties, this isn't particularly efficient when sorting lists of non-contemporary people or trying to find matches within such lists/queries (Add your motivation for this property here.) --- Jura 07:47, 22 December 2018 (UTC)
Discussion
[edit]- Oppose Use floruit (P1317) with
|precision=century
, like this; and with multiple values if necessary. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:59, 22 December 2018 (UTC) - Oppose per Pigsonthewing. ChristianKl ❪✉❫ 14:27, 24 December 2018 (UTC)
- Wait per Pigsonthewing and the follwing. I've worked on finding matches/comparing with SPARQL for date of birth (P569)/date of death (P570) using the precision and it's not very handy, but a cleaner solution then this proposed property which would would cause maintaining costs and redundancy. --Marsupium (talk) 16:49, 26 December 2018 (UTC), 12:16, 28 December 2018 (UTC)
- It seems somewhat redundant to set a P1317 value for people who already have some other date. Makes me wonder @ChristianKl: did you actually use this or is this just some virtual idea?
@Marsupium: I agree that this is equivalent, but I don't think it's handy at all. When trying to match people across centuries, I found grouping them by century is by far the easiest approach. For the new property, there wouldn't be any maintenance involved: once it's defined it doesn't move and it can be set in a fairly by bot. --- Jura 11:17, 28 December 2018 (UTC)- @Jura1: Ok, it can be set by bot indeed. Do you have an example of a query you used that could help to illustrate how big the advantage would be? --Marsupium (talk) 12:01, 28 December 2018 (UTC)
- @Marsupium: family_name/Crawford and family_name/Fugger would probably work better by century and given name, at least when one uses it to try to find out where a random member fits in. --- Jura 12:05, 28 December 2018 (UTC)
- I'll try to investigate/understand the cases later! --Marsupium (talk) 12:16, 28 December 2018 (UTC)
- When it comes to a list like that, it seems to me it woud make more sense if the value would be calculated on-the-fly. ChristianKl ❪✉❫ 13:15, 28 December 2018 (UTC)
- @ChristianKl: Can you clarify your suggestion about using P1317? It seems a really odd alternative. Do you actually use that? Why would you add a second statement with century precision? --- Jura 13:18, 28 December 2018 (UTC)
- I personally don't feel a need and as such I don't use it. ChristianKl ❪✉❫ 13:33, 28 December 2018 (UTC)
- @ChristianKl: maybe you want to edit your comment above. Some users might try to follow your suggestion and end up getting reverted. See Help:Dates for general suggestions. --- Jura 13:37, 28 December 2018 (UTC)
- I personally don't feel a need and as such I don't use it. ChristianKl ❪✉❫ 13:33, 28 December 2018 (UTC)
- It is easy to get the century (as whatever you want to define it, see phab:T95553) from any Time datatype value. Do the queries time out if you do that? Any problem with using existing date of birth (P569)/date of death (P570) for that? --Marsupium (talk) 23:45, 29 December 2018 (UTC)
- @ChristianKl: Can you clarify your suggestion about using P1317? It seems a really odd alternative. Do you actually use that? Why would you add a second statement with century precision? --- Jura 13:18, 28 December 2018 (UTC)
- @Marsupium: family_name/Crawford and family_name/Fugger would probably work better by century and given name, at least when one uses it to try to find out where a random member fits in. --- Jura 12:05, 28 December 2018 (UTC)
- @Jura1: Ok, it can be set by bot indeed. Do you have an example of a query you used that could help to illustrate how big the advantage would be? --Marsupium (talk) 12:01, 28 December 2018 (UTC)
- It seems somewhat redundant to set a P1317 value for people who already have some other date. Makes me wonder @ChristianKl: did you actually use this or is this just some virtual idea?
- Oppose Facilitating some matching tasks is not enough reason to introduce redundant properties.
- Why "century" only? Why not "decade of birth" etc etc?
- If you need derived fields for matching, incent Magnus to port MnM to Wikibase (@Jura1: have you heard the news?) and in that Wikibase I'm sure people will more readily accept all sort of cached props
- --Vladimir Alexiev (talk) 13:55, 3 January 2019 (UTC)
- Thanks for your input. I think the use of most properties at Wikidata is just limited to some matching task. --- Jura 14:10, 3 January 2019 (UTC)
- Oppose, redundant to floruit (P1317). --Yair rand (talk) 05:02, 14 March 2019 (UTC)
- Oppose it seems unnecessary to have a temporal property for a specific precision. Simon Cobb (User:Sic19 ; talk page) 16:45, 5 April 2019 (UTC)