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.vrandecic(a)wikimedia.de
To: wikidata-l(a)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 <dtaraborelli(a)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.jr(a)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: tfmorris(a)gmail.com
To: wikidata-l(a)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(a)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
listWikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l