For most of the scenarios I can think of, parsing the dates out of strings that are in a standard format by convention will be much easier. The number of ways people will want to use qualifiers will increase like the number of properties and items. So the way I see it, we have to support string-based qualifiers at the minimum. Then I think we should only support strongly typed qualifiers if performance requires it. By setting an update polling frequency on templates that use the information I don't think we'll run into performance issues for most scenarios. Even with this example the qualifier type is a date range, not just a date. So do we want them to have to choose from a large, fixed list of qualifier types or just look at a similar example and set a string to something similar and then gradually enforce types on the most popular uses that we see. I think this type of organic growth as opposed to trying to guess the qualifier types in advance is exactly in the spirit of Wikipedia.


Date: Fri, 15 Mar 2013 09:58:38 -0400
From: tfmorris@gmail.com
To: wikidata-l@lists.wikimedia.org
Subject: Re: [Wikidata-l] Expiration date for data

On Fri, Mar 15, 2013 at 1:49 AM, Michael Hale <hale.michael.jr@live.com> wrote:
Yes, I think once qualifiers are enabled you would just have something like:
...
Property(head of local government)
    ...
    Value(Elizabeth I) - Qualifier("1558-1603") - Sources()
    Value(James VI and I) - Qualifier("1603-1625") - Sources()
    ...
...

There was a discussion about whether qualifiers should have specific datatypes other than just string, but I think we should only do that if needed.

Clearly the example that you gave is one where non-string datatypes are critically important.  If you don't know that they're dates, you have no way of telling when they were in those roles.

Tom 

_______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l