[Wikidata-l] Property P107

[John McClure]

  -Original Message-
  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
"every property is strongly typed" is clear, as you refer to datatypes, but
not to "types" in the rdf:type sense, which of course are owl:Class things.
When talking about owl:Class things it's nice to reference an OWL ontology,
which maybe I've missed, from Wikidata. So I've learned from sniffing around
that Wikidata's ontology is going in the direction of
http://d-nb.info/standards/elementset/gnd. And that P107 is semantically
identical to rdf:type.

Is this correct? If so, will you add "rdf:type" as an alternate label?

Although I disagree with some of below which I ran across at
https://news.ycombinator.com/item?id=5328472, I do note that P107 on
Wikidata is entitled "main type (GND)" among other indications. How does
adopting a specific ontology accord with the view in your blog strenuously
promoting folksonomies over ontologies?

That is, a folksonomy in the sense that owl:Class's are implicitly defined,
whose "instances" are associated as a "class" by virtue of possessing in
common certain properties and or property values. IOW, your blog implies
little need to define "classes" at all. You face a challenge though because
soon people want to attach a name to the bundle of properties and-or
property values that comprise a "class" of things, to refer to them as a
collection.

Any light you can shed about ontology plans for Wikidata would be
appreciated!
thanks - john





emw 15 days ago | link

Property P107 (http://www.wikidata.org/wiki/Property:P107) has emerged as
Wikidata's de facto upper ontology. It currently consists of six main types:
person, organization, event, creative work, term, and geographical feature.
It's essentially a clean port of the high-level entities from the GND
Ontology -- a controlled vocabulary developed by the German National Library
and released last summer (http://d-nb.info/standards/elementset/gnd).
There's a fair amount of debate over that property. Are those current high
level types (person, place, work, event, organization, term) a good fit for
a knowledgebase that aims to structure all knowledge and not just library
holdings? Does classifying subjects like inertia, DNA, Alzheimer's disease,
dog, etc. as simply "terms" make sense?

More reading related to Wikidata, ontology and types:
https://blog.wikimedia.de/2013/02/22/restricting-the-world/.
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Expiration date for data

[Andrew Gray]

On 21 March 2013 15:39, Michael Hale  wrote:
> Great post. Regarding the suggestions feature, it seems the easiest way to
> get that rolling would be to have a bot that would periodically tally all of
> the properties for all of the items that have an "is a" property with the
> same value. Then we could say most of the items with "is a _" have a _. Then
> anytime you set an "is a" property you could automatically get suggestions
> for what properties to add. Guided growth without suffocation from
> constraints.

And conversely, advice on unusual combinations: "Only 1 of the 54,687
items with "population" values also have a value for "flavour". Did
you mean to include this?"

-- 
- Andrew Gray
  andrew.g...@dunelm.org.uk

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

Re: [Wikidata-l] Amsterdam + Wikimania hackathon + Wikimania

[Yuri Astrakhan]

I also plan to be in Amsterdam, would love to work closely with the
wikidata team.

--yurik


On Thu, Mar 21, 2013 at 11:53 AM, Andy Mabbett wrote:

> On 21 March 2013 14:26, Lydia Pintscher 
> wrote:
> > Some of the Wikidata team will be at the MediaWiki hackathon in
> > Amsterdam in late May
> > (http://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013). It'd be
> > great to see some of you attend and join us in hacking on Wikidata. If
> > you're coming please let me know in advance so we can better prepare
> > in advance.
>
> I'll be there; and look forward to meeting you all.
>
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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

Re: [Wikidata-l] Amsterdam + Wikimania hackathon + Wikimania

[Andy Mabbett]

On 21 March 2013 14:26, Lydia Pintscher  wrote:
> Some of the Wikidata team will be at the MediaWiki hackathon in
> Amsterdam in late May
> (http://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013). It'd be
> great to see some of you attend and join us in hacking on Wikidata. If
> you're coming please let me know in advance so we can better prepare
> in advance.

I'll be there; and look forward to meeting you all.


--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Wikidata-l] Expiration date for data

[Michael Hale]

Great post. Regarding the suggestions feature, it seems the easiest way to get 
that rolling would be to have a bot that would periodically tally all of the 
properties for all of the items that have an "is a" property with the same 
value. Then we could say most of the items with "is a _" have a _. Then anytime 
you set an "is a" property you could automatically get suggestions for what 
properties to add. Guided growth without suffocation from constraints.

Date: Thu, 21 Mar 2013 16:17:55 +0100
From: denny.vrande...@wikimedia.de
To: wikidata-l@lists.wikimedia.org
Subject: Re: [Wikidata-l] Expiration date for data

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:


Cheers,denny



2013/3/21 Michael Hale 




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: 



Cheers,Denny



2013/3/21 Michael Hale 





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 



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  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 w

Re: [Wikidata-l] Expiration date for data

[Denny Vrandečić]

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:



Cheers,
denny




2013/3/21 Michael Hale 

> 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 
>
> 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 
>
> 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 
> 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
> qualif

Re: [Wikidata-l] Expiration date for data

[Michael Hale]

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: 


Cheers,Denny



2013/3/21 Michael Hale 




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 


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  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  wrote:


Y

Re: [Wikidata-l] Expiration date for data

[Denny Vrandečić]

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 

> 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 
>
> 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 
> 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 
> wrote:
>
> Yes, I think once qualifiers are enabled you would just have something
> like:
> ...
> Property(head of local government)
> ...
> 

Re: [Wikidata-l] Expiration date for data

[Michael Hale]

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 

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  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  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 
_

Re: [Wikidata-l] Expiration date for data

[Denny Vrandečić]

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 

> 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 
> 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 
> 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
> 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
>
>
>
> ___
> 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] Amsterdam + Wikimania hackathon + Wikimania

[Lydia Pintscher]

Heya folks :)

Some of the Wikidata team will be at the MediaWiki hackathon in
Amsterdam in late May
(http://www.mediawiki.org/wiki/Amsterdam_Hackathon_2013). It'd be
great to see some of you attend and join us in hacking on Wikidata. If
you're coming please let me know in advance so we can better prepare
in advance.

We'll also attend the hackathon right before Wikimania in Hong Kong in
early August (http://wikimania2013.wikimedia.org/wiki/Hackathon). The
same applies as for the hackathon in Amsterdam.

For Wikimania itself: Anyone wants to join me for a Wikidata
talk/workshop/...? Other ideas?


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. 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

Re: [Wikidata-l] chancelier du reich, chancelier du reich und reichskanzler

[Sylvain Boissel]

Hello Thomas,

There is a running RfC about this on
http://www.wikidata.org/wiki/Wikidata:Requests_for_comment/A_need_for_a_resolution_regarding_article_moves_and_redirects


Regards,
Sylvain.

2013/3/19 Thomas Douillard 

> 013/3/19 Bináris 
>
>>
>>
>> 2013/3/19 rupert THURNER 
>>
>>> wie würde man eigentlich:
>>> * http://de.wikipedia.org/wiki/Reichskanzler
>>> * http://fr.wikipedia.org/wiki/Chancelier_du_Reich
>>> * http://fr.wikipedia.org/wiki/Chancelier_imp%C3%A9rial
>>> korrekt verlinken?
>>>
>>
>> This is not a WIkidata question, this is an interwiki question, if you
>> understand the difference. I mean WD is a technical tool, but articles of
>> different wikis won't fit to each other better because we have WD; if you
>> couldn't link articles before WD correctly, it won't be easier now.
>> Unfortunately, these problems will exist for long terms.
>>  --
>> Bináris
>>
>
> I got a related question : some Interwikis in the old system points to:
> *  sections in an article in another language,
> * or to article that are actually redirects on a section of another
> article.
>
> It seems that wikidata have trouble dealing with the second case when the
> redirection exists prior switching to Wikidata new interwiki system. It
> solves the redirection and does not want to associate the Item. But when
> the redirection is created after the Item association it works ...
>
> Questions :
> * is there any plan to deal with section of articles, now or in the future
> ?
> * are redirections to section a correct way to deal with this ?
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>


-- 
Sylvain Boissel
Chargé de mission communauté et technologie de Wikimédia France
tél 09.67.28.73.79 - email sylvain.bois...@wikimedia.fr - twitter
@sboissel

*Imaginez un monde où chaque personne sur la planète aurait librement accès
à la totalité du savoir humain. C'est notre engagement. Aidez Wikimedia
France à en faire une réalité .*
www.wikimedia.fr
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Expiration date for data

[Michael Hale]

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: dtarabore...@wikimedia.org
Date: Wed, 20 Mar 2013 10:12:05 -0700
To: wikidata-l@lists.wikimedia.org
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  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  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 
  ___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] chancelier du reich, chancelier du reich und reichskanzler

[Lydia Pintscher]

Hey :)

On Tue, Mar 19, 2013 at 12:44 PM, Thomas Douillard
 wrote:
> I got a related question : some Interwikis in the old system points to:
> *  sections in an article in another language,
> * or to article that are actually redirects on a section of another article.
>
> It seems that wikidata have trouble dealing with the second case when the
> redirection exists prior switching to Wikidata new interwiki system. It
> solves the redirection and does not want to associate the Item. But when the
> redirection is created after the Item association it works ...
>
> Questions :
> * is there any plan to deal with section of articles, now or in the future ?

It is currently not planned. 1-to-1 relations are one of the
fundamental assumptions of Wikidata.

> * are redirections to section a correct way to deal with this ?

As a work-around either that or continue using interwiki links in the
wikitext or adapt the articles.


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. 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