It really depends on your definitions :) Items are strongly typed as items. Any item can have any property. And only items can have properties. Time or geocoordinates, e.g., can not have properties.
But yes, there is no forcing of properties onto any item, nor any restriction of usage of every property. See also here: <http://blog.wikimedia.de/2013/02/22/restricting-the-world/> Cheers, denny 2013/3/21 Michael Hale <[email protected]> > Yes, I just meant that items aren't forced to have a specific set of > properties by the software, so they are essentially weakly typed, right? > > ------------------------------ > Date: Thu, 21 Mar 2013 16:09:58 +0100 > > From: [email protected] > To: [email protected] > Subject: Re: [Wikidata-l] Expiration date for data > > 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 > > _______________________________________________ > 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
