I think it will be about the same amount of work on the client side for templates either way. When would I use a coordinate as a qualifier? I can think of plenty of places where they would be used as property value datatypes, but not for qualifiers. What happens if someone was a head of government twice? Do they have four datetime qualifiers? Two starts and two ends? Would the clients be able to assume they are listed in order or need to sort them anyway to just be safe? Clients would then just have to check for string qualifiers and datetime qualifiers, so I don't think it would make using Wikidata any easier.
From: [email protected] Date: Wed, 20 Mar 2013 10:12:05 -0700 To: [email protected] Subject: Re: [Wikidata-l] Expiration date for data I disagree, and fully concur with Tom: a generic string type for a datetime qualifier defies the purpose of making wikidata statements well-formed and machine-readable.I don't think we should enforce typing for *all* qualifiers and I second the general "organic growth" approach, but datetime qualifiers strike me as a fundamental exception. Would you represent geocoordinates as a generic string and wait for "organic growth" to determine the appropriate datatype? I appreciate the overheads of adding datatype support, but this decision will have a major impact on the shape of collaborative work on wikidata. Denny – on a related note, I wanted to ask you what is the priority of qualifier support relative to the other items you mentioned in your list. As I noted in my previous post, the only way for an editor to correct an outdated statement is to remove information (e.g. Lombardy: head of local government: -Roberto Formigoni +Roberto Maroni ): this information will then be lost forever in an item's revision history. The sooner we introduce basic support for qualifiers, the sooner we can avoid removing valuable information from wikidata entries just for the sake of keeping them up-to-date. Dario On Mar 15, 2013, at 10:09 AM, Michael Hale <[email protected]> wrote: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: [email protected] To: [email protected] Subject: Re: [Wikidata-l] Expiration date for data On Fri, Mar 15, 2013 at 1:49 AM, Michael Hale <[email protected]> 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l_______________________________________________ Wikidata-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l _______________________________________________ Wikidata-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________ Wikidata-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
