We do have strong types, but only few of time: item, commons media, string, time, geo, URL. "Government leader" would not be a supported type.
The exact list and details are here: < http://meta.wikimedia.org/wiki/Wikidata/Data_model#Datatypes_and_their_Values > Cheers, Denny 2013/3/21 Michael Hale <[email protected]> > That seems better to constrain the overall type of a qualifier to any > property. It still doesn't feel exactly right, but I'm not sure what would. > Now that I think about it more, for the case of heads of government it > doesn't seem appropriate to use a qualifier at all to me. It would just be > a list of items which are presumably people. Each of those items would then > have a single date or list of dates for start of head of government and end > of head of government. The qualifier would be redundant. It seems the > downside to having everything be strongly typed like in Freebase is that > you end up with really weird and specific entity types like "government > leadership timespan" to try to capture all of the details that you want, > and the downside to semi-weakly typed items in Wikidata is that you might > end up with different items representing the same information with > different properties or qualifiers. But I have faith that Wikidata will > ultimately work and achieve stability and convergence for the most common > types just like how template boxes naturally emerged on Wikipedia. And I > think the key advantage of Wikidata is that it will achieve growth, > stability, and convergence without suffocating from having too many weird > and specific item types to try to bridge and glue different types of > information together. > > ------------------------------ > Date: Thu, 21 Mar 2013 15:40:39 +0100 > From: [email protected] > > To: [email protected] > Subject: Re: [Wikidata-l] Expiration date for data > > We will have a time datatype, and every property is strongly typed. This > is also true for properties used as qualifiers. > > Regarding the priority of qualifiers: very high. They are the next major > UI feature to be deployed, and as far as I can tell from the progress of > the team it looks like they will be deployed in April. > > Cheers, > Denny > > > > 2013/3/20 Dario Taraborelli <[email protected]> > > 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 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 > > > > > -- > Project director Wikidata > Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin > Tel. +49-30-219 158 26-0 | http://wikimedia.de > > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter > der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für > Körperschaften I Berlin, Steuernummer 27/681/51985. > > _______________________________________________ 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 > > -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________ Wikidata-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-l
