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: denny.vrande...@wikimedia.de
To: wikidata-l@lists.wikimedia.org
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 <hale.michael...@live.com>




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: denny.vrande...@wikimedia.de
To: wikidata-l@lists.wikimedia.org

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 <dtarabore...@wikimedia.org>


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 <hale.michael...@live.com> 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: tfmor...@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...@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 
listwikidat...@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

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




_______________________________________________

Wikidata-l mailing list

Wikidata-l@lists.wikimedia.org

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
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l                         
                  

_______________________________________________

Wikidata-l mailing list

Wikidata-l@lists.wikimedia.org

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
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l                         
                  
_______________________________________________
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Reply via email to