Wikidata:Property proposal/century fl.

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)[reply]

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)[reply]
Oppose per Pigsonthewing. ChristianKl ❪✉❫ 14:27, 24 December 2018 (UTC)[reply]
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)[reply]
- 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)[reply]
  - @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)[reply]
    - @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)[reply]
      - I'll try to investigate/understand the cases later! --Marsupium (talk) 12:16, 28 December 2018 (UTC)[reply]
      - 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)[reply]
        @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)[reply]
        I personally don't feel a need and as such I don't use it. ChristianKl ❪✉❫ 13:33, 28 December 2018 (UTC)[reply]
        @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)[reply]
        
        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)[reply]
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)[reply]

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)[reply]

Oppose, redundant to floruit (P1317). --Yair rand (talk) 05:02, 14 March 2019 (UTC)[reply]
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)[reply]

Wikidata:Property proposal/century fl.

century fl.[edit]

Motivation[edit]

Discussion[edit]

Navigation menu

Search