Hey everyone,
Since some time now ranks are available. They are meant as a way to help manage the vast amount of information in Wikidata and make sense of them. One important point is to be able to "hide" old and wrong information using the normal and deprecated ranks. This allows us to for example only show the current leader of a country when asked for it instead of all the ones that have had this title at some point in the past. We want to move forward with making use of this now. This means a few things in particular: * The property parser function {{#property:P123}} will be changed to only return preferred values if they are available. If none are available then the normal ones will be returned. * Lua will be adapted to also by default only return preferred values if available and otherwise normal values. * Simple queries (like "give me the item with ISBN 12345678) will only return items with the value marked as preferred if available and otherwise normal values. * Complex queries will only return items with the values marked as preferred (and if not available normal) initially. Later all can be searched for explicitly as well but by default still only items with the values marked as preferred (and if not available normal) will be returned.
This in essence means that people will need to start marking values as preferred and deprecated where appropriate. This change will happen within the next weeks. I don't yet know exactly when the code change will be ready.
Onwards to a Wikidata that can meaningfully work with historical information \o/
Cheers Lydia
Hoi, When a specific label is preferred, it has preferred labels in any language. Will there be something to make that easy and obvious? Also when one language does not have the appropriate label, will the deprecated label be used.
When it is about values, will they work with dates? Thanks, GerardM
On 6 March 2014 15:30, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:
Hey everyone,
Since some time now ranks are available. They are meant as a way to help manage the vast amount of information in Wikidata and make sense of them. One important point is to be able to "hide" old and wrong information using the normal and deprecated ranks. This allows us to for example only show the current leader of a country when asked for it instead of all the ones that have had this title at some point in the past. We want to move forward with making use of this now. This means a few things in particular:
- The property parser function {{#property:P123}} will be changed to
only return preferred values if they are available. If none are available then the normal ones will be returned.
- Lua will be adapted to also by default only return preferred values
if available and otherwise normal values.
- Simple queries (like "give me the item with ISBN 12345678) will only
return items with the value marked as preferred if available and otherwise normal values.
- Complex queries will only return items with the values marked as
preferred (and if not available normal) initially. Later all can be searched for explicitly as well but by default still only items with the values marked as preferred (and if not available normal) will be returned.
This in essence means that people will need to start marking values as preferred and deprecated where appropriate. This change will happen within the next weeks. I don't yet know exactly when the code change will be ready.
Onwards to a Wikidata that can meaningfully work with historical information \o/
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 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
Am 06.03.2014 16:08, schrieb Gerard Meijssen:
Hoi, When a specific label is preferred, it has preferred labels in any language. Will there be something to make that easy and obvious? Also when one language does not have the appropriate label, will the deprecated label be used.
Ranks are for statements. They do not apply to labels, descriptions, aliases or sitelinks.
All labels are preferred, the non-preferred labels are called aliases.
-- daniel
Hoi, I hope this will be revisited. Many items change there name and dependent on a date they or it are called differently. Thanks, GerardN
PS I take it that the statements will allow for different values dependent on the date
On 6 March 2014 16:20, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 06.03.2014 16:08, schrieb Gerard Meijssen:
Hoi, When a specific label is preferred, it has preferred labels in any
language.
Will there be something to make that easy and obvious? Also when one
language
does not have the appropriate label, will the deprecated label be used.
Ranks are for statements. They do not apply to labels, descriptions, aliases or sitelinks.
All labels are preferred, the non-preferred labels are called aliases.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Am 06.03.2014 16:27, schrieb Gerard Meijssen:
Hoi, I hope this will be revisited. Many items change there name and dependent on a date they or it are called differently.
If the name is something that is changed, debated, or otherwise a subject of discussion, create a statement using an appropriate property. The point of having labels is precisely that they are simple.
-- daniel
Hoi, So how do I indicate that up to a particular date Jakarta was called Batavia ? Muhammed Ali was called Cassius Clay ? There is no discussion about it. All there is an (potentially perceived) inability to use appropriate labels at will.
Labels are not simple. Thanks, Gerard
On 6 March 2014 17:07, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 06.03.2014 16:27, schrieb Gerard Meijssen:
Hoi, I hope this will be revisited. Many items change there name and
dependent on a
date they or it are called differently.
If the name is something that is changed, debated, or otherwise a subject of discussion, create a statement using an appropriate property. The point of having labels is precisely that they are simple.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Am 06.03.2014 17:12, schrieb Gerard Meijssen:
Hoi, So how do I indicate that up to a particular date Jakarta was called Batavia ? Muhammed Ali was called Cassius Clay ? There is no discussion about it. All there is an (potentially perceived) inability to use appropriate labels at will.
Create a property for "official name" and make staements. Labels are there for display and search. They are not intended to convey complex information.
-- daniel
Hoi, When data is to be shown in the context of history, the appropriate label is to be shown, is to be found. It is as complex as what we do with statements.
The point is very much that when you state that when labels are not intended to convey "complex" information, the intention is debatable. It is arguably wrong. Thanks, GerardM
On 6 March 2014 17:15, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 06.03.2014 17:12, schrieb Gerard Meijssen:
Hoi, So how do I indicate that up to a particular date Jakarta was called
Batavia ?
Muhammed Ali was called Cassius Clay ? There is no discussion about it.
All
there is an (potentially perceived) inability to use appropriate labels
at will.
Create a property for "official name" and make staements. Labels are there for display and search. They are not intended to convey complex information.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
If you want to model everything precisely, you'll never get done.
"If the doors of perception were cleansed every thing would appear to man as it is, Infinite." -- William Blake
Am 06.03.2014 17:21, schrieb Gerard Meijssen:
Hoi, When data is to be shown in the context of history, the appropriate label is to be shown, is to be found. It is as complex as what we do with statements.
The point is very much that when you state that when labels are not intended to convey "complex" information, the intention is debatable. It is arguably wrong. Thanks, GerardM
On 6 March 2014 17:15, Daniel Kinzler <daniel.kinzler@wikimedia.de mailto:daniel.kinzler@wikimedia.de> wrote:
Am 06.03.2014 17:12, schrieb Gerard Meijssen: > Hoi, > So how do I indicate that up to a particular date Jakarta was called Batavia ? > Muhammed Ali was called Cassius Clay ? There is no discussion about it. All > there is an (potentially perceived) inability to use appropriate labels at will. Create a property for "official name" and make staements. Labels are there for display and search. They are not intended to convey complex information. -- daniel -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto: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
It's OK if we have a way to represent the information in another way. Reasonator plays kind of fine with this, it's enough to make him aware of the "official name" to treat it differently. The name to display is a contextful information, and anyway it needs special ways to treat the information and select the context and the data to display, so it''s not really a problem.
2014-03-06 17:21 GMT+01:00 Gerard Meijssen gerard.meijssen@gmail.com:
Hoi, When data is to be shown in the context of history, the appropriate label is to be shown, is to be found. It is as complex as what we do with statements.
The point is very much that when you state that when labels are not intended to convey "complex" information, the intention is debatable. It is arguably wrong. Thanks, GerardM
On 6 March 2014 17:15, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 06.03.2014 17:12, schrieb Gerard Meijssen:
Hoi, So how do I indicate that up to a particular date Jakarta was called
Batavia ?
Muhammed Ali was called Cassius Clay ? There is no discussion about it.
All
there is an (potentially perceived) inability to use appropriate labels
at will.
Create a property for "official name" and make staements. Labels are there for display and search. They are not intended to convey complex information.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
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
There is a "official name" property for this purpose in Wikidata. Date qualifiers gives the information on when the name was the official one.
---------- Forwarded message ---------- From: Gerard Meijssen gerard.meijssen@gmail.com Date: 2014-03-06 17:12 GMT+01:00 Subject: Re: [Wikidata-l] rank related changes To: "Discussion list for the Wikidata project." < wikidata-l@lists.wikimedia.org>
Hoi, So how do I indicate that up to a particular date Jakarta was called Batavia ? Muhammed Ali was called Cassius Clay ? There is no discussion about it. All there is an (potentially perceived) inability to use appropriate labels at will.
Labels are not simple. Thanks, Gerard
On 6 March 2014 17:07, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 06.03.2014 16:27, schrieb Gerard Meijssen:
Hoi, I hope this will be revisited. Many items change there name and
dependent on a
date they or it are called differently.
If the name is something that is changed, debated, or otherwise a subject of discussion, create a statement using an appropriate property. The point of having labels is precisely that they are simple.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
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
Use 'Birth name (P513)' (string datatype) for Cassius Clay or 'Official name' (Proposed property with monolingual text datatype) for Batavia - with date qualifiers.
Joe
On Thu, Mar 6, 2014 at 4:12 PM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
Hoi, So how do I indicate that up to a particular date Jakarta was called Batavia ? Muhammed Ali was called Cassius Clay ? There is no discussion about it. All there is an (potentially perceived) inability to use appropriate labels at will.
Labels are not simple. Thanks, Gerard
On 6 March 2014 17:07, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 06.03.2014 16:27, schrieb Gerard Meijssen:
Hoi, I hope this will be revisited. Many items change there name and
dependent on a
date they or it are called differently.
If the name is something that is changed, debated, or otherwise a subject of discussion, create a statement using an appropriate property. The point of having labels is precisely that they are simple.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
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
Hoi, The name was Batavia at that time in any language.
The issue is that when you fudge information in this way, you can not have proper queries. This is why Daniel is wrong and the notion that labels are simple needs to be revisited. It is not rare at all and it exists in many domains. This is why it is wrong, wrong, wrong. Thanks, GerardM
On 6 March 2014 19:31, Joe Filceolaire filceolaire@gmail.com wrote:
Use 'Birth name (P513)' (string datatype) for Cassius Clay or 'Official name' (Proposed property with monolingual text datatype) for Batavia - with date qualifiers.
Joe
On Thu, Mar 6, 2014 at 4:12 PM, Gerard Meijssen <gerard.meijssen@gmail.com
wrote:
Hoi, So how do I indicate that up to a particular date Jakarta was called Batavia ? Muhammed Ali was called Cassius Clay ? There is no discussion about it. All there is an (potentially perceived) inability to use appropriate labels at will.
Labels are not simple. Thanks, Gerard
On 6 March 2014 17:07, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
Am 06.03.2014 16:27, schrieb Gerard Meijssen:
Hoi, I hope this will be revisited. Many items change there name and
dependent on a
date they or it are called differently.
If the name is something that is changed, debated, or otherwise a subject of discussion, create a statement using an appropriate property. The point of having labels is precisely that they are simple.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
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
Wikidata labels are simple. This is due to the necessities of the project. We need one single label to display. Having Wikidata labels with ranks, qualifieres, sources, etc. simply would not work in the UI.
Labels and names in reality are indeed extremely complex. But as already pointed out, this kind of information can be expressed with Statements, and we already have properties to do so and will probably get more such properties when the multi- and monolingual text properties get developed.
So, yes, Gerard, Daniel would be wrong if he would say that labels are simple in the world. But that is not what he said. He was simply referring to labels as they are already implemented in Wikidata, and that serve a very specific purpose - and for these, he is absolutely right to say that ranks do not apply for them.
The only purpose of labels and descriptions is to provide identifying information and to provide something to display for an item. The only purpose for aliases is to increase recall for search. I would consider having an alias containing a frequent typo absolutely OK, if it helps people find that item. They don't have to be right. They don't have to be sourced. They have to be useful.
Statements on the other hand contain the actual content of Wikidata. And those have ranks, qualifiers, sources, etc. Statemnt can contain historical names of cities, and say from when to when they were used. Queries can then some day use this information and display it within the context of a specific query. But that is not what Wikidata labels are there for.
I hope that makes sense.
On Fri Mar 07 2014 at 12:01:32 AM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, The name was Batavia at that time in any language.
The issue is that when you fudge information in this way, you can not have proper queries. This is why Daniel is wrong and the notion that labels are simple needs to be revisited. It is not rare at all and it exists in many domains. This is why it is wrong, wrong, wrong. Thanks, GerardM
On 6 March 2014 19:31, Joe Filceolaire filceolaire@gmail.com wrote:
Use 'Birth name (P513)' (string datatype) for Cassius Clay or 'Official name' (Proposed property with monolingual text datatype) for Batavia - with date qualifiers.
Joe
On Thu, Mar 6, 2014 at 4:12 PM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, So how do I indicate that up to a particular date Jakarta was called Batavia ? Muhammed Ali was called Cassius Clay ? There is no discussion about it. All there is an (potentially perceived) inability to use appropriate labels at will.
Labels are not simple. Thanks, Gerard
On 6 March 2014 17:07, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
Am 06.03.2014 16:27, schrieb Gerard Meijssen:
Hoi, I hope this will be revisited. Many items change there name and
dependent on a
date they or it are called differently.
If the name is something that is changed, debated, or otherwise a subject of discussion, create a statement using an appropriate property. The point of having labels is precisely that they are simple.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
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
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hoi,
Sorry it does not wash with me. When you look at the current user interface it is crummy. It is not informative and I am grateful for Magnus to have started with the Reasonator. When your argument is that the current UI does not and is not able to support more complex logic for labels I agree. It does not.
At this moment in time the only logic supported is on the level of statements. When your argument is that this is what we can safely support, I understand and I can live with it for now. When you mean to argue that this should suffice, I disagree totally with you.
At this moment there is a start of having "badges". They are at this stage basic information on the article level. It demonstrates that we CAN have information that is beyond statements. It is arguably not sufficient, an argument made in bug 40810#c38.
When Wiktionary is to be integrated, labels are what Wiktionary is about. This should be obvious, The argument is that we can leave labels for now. It requires revisiting in the not to far off future.
NB Do not read into this that I do not value or appreciate the development done by the Wikidata team. What they do is amazing; get a project running that is actually useful and slowly but surely expand its scope. It is a project that shows an increase in people having an active interest. In my opinion Wikidata is a necessary part of the evolution of the Wikimedia Foundations projects. The impact it is having and will have has not registered in most peoples mind. Thanks, GerardM
On 8 March 2014 01:34, Denny Vrandečić vrandecic@gmail.com wrote:
Wikidata labels are simple. This is due to the necessities of the project. We need one single label to display. Having Wikidata labels with ranks, qualifieres, sources, etc. simply would not work in the UI.
Labels and names in reality are indeed extremely complex. But as already pointed out, this kind of information can be expressed with Statements, and we already have properties to do so and will probably get more such properties when the multi- and monolingual text properties get developed.
So, yes, Gerard, Daniel would be wrong if he would say that labels are simple in the world. But that is not what he said. He was simply referring to labels as they are already implemented in Wikidata, and that serve a very specific purpose - and for these, he is absolutely right to say that ranks do not apply for them.
The only purpose of labels and descriptions is to provide identifying information and to provide something to display for an item. The only purpose for aliases is to increase recall for search. I would consider having an alias containing a frequent typo absolutely OK, if it helps people find that item. They don't have to be right. They don't have to be sourced. They have to be useful.
Statements on the other hand contain the actual content of Wikidata. And those have ranks, qualifiers, sources, etc. Statemnt can contain historical names of cities, and say from when to when they were used. Queries can then some day use this information and display it within the context of a specific query. But that is not what Wikidata labels are there for.
I hope that makes sense.
On Fri Mar 07 2014 at 12:01:32 AM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, The name was Batavia at that time in any language.
The issue is that when you fudge information in this way, you can not have proper queries. This is why Daniel is wrong and the notion that labels are simple needs to be revisited. It is not rare at all and it exists in many domains. This is why it is wrong, wrong, wrong. Thanks, GerardM
On 6 March 2014 19:31, Joe Filceolaire filceolaire@gmail.com wrote:
Use 'Birth name (P513)' (string datatype) for Cassius Clay or 'Official name' (Proposed property with monolingual text datatype) for Batavia - with date qualifiers.
Joe
On Thu, Mar 6, 2014 at 4:12 PM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, So how do I indicate that up to a particular date Jakarta was called Batavia ? Muhammed Ali was called Cassius Clay ? There is no discussion about it. All there is an (potentially perceived) inability to use appropriate labels at will.
Labels are not simple. Thanks, Gerard
On 6 March 2014 17:07, Daniel Kinzler daniel.kinzler@wikimedia.dewrote:
Am 06.03.2014 16:27, schrieb Gerard Meijssen:
Hoi, I hope this will be revisited. Many items change there name and
dependent on a
date they or it are called differently.
If the name is something that is changed, debated, or otherwise a subject of discussion, create a statement using an appropriate property. The point of having labels is precisely that they are simple.
-- daniel
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
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
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
Am 08.03.2014 11:22, schrieb Gerard Meijssen:
At this moment there is a start of having "badges". They are at this stage basic information on the article level. It demonstrates that we CAN have information that is beyond statements. It is arguably not sufficient, an argument made in bug 40810#c38.
Badges are editorial information (they say somthine about an article in the Wikimedia universe), they don't say anthing about the entity itself. IF they did, they would be (part of) statements.
When Wiktionary is to be integrated, labels are what Wiktionary is about. This should be obvious, The argument is that we can leave labels for now. It requires revisiting in the not to far off future.
This is not how Wiktionary integration is going to work. At all. Please read the proposal: https://www.wikidata.org/wiki/Wikidata:Wiktionary. This has nothing to do with labels, precisely because we need labels to be simple. The proposal does not detail how lexemes interact with items in the UI and in search - that's still open, and that's exactly where the things you have been mentionen will have their place. That'S going to be a lot more powerful and flexible than trying to glue extra attributes to labels.
-- daniel
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hoi, There is little point to integrating Wiktionary and the current proposal if it is unclear how that information is going to be used. The proposal for all its fancy words misses the point completely and you point it out really well: it is unclear how lexemes will interact in the UI and in search.
The current labels will one on one coincide with lexemes. I think we can agree on this. Thanks, GerardM
On 10 March 2014 12:43, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.03.2014 11:22, schrieb Gerard Meijssen:
At this moment there is a start of having "badges". They are at this
stage basic
information on the article level. It demonstrates that we CAN have
information
that is beyond statements. It is arguably not sufficient, an argument
made in
bug 40810#c38.
Badges are editorial information (they say somthine about an article in the Wikimedia universe), they don't say anthing about the entity itself. IF they did, they would be (part of) statements.
When Wiktionary is to be integrated, labels are what Wiktionary is
about. This
should be obvious, The argument is that we can leave labels for now. It
requires
revisiting in the not to far off future.
This is not how Wiktionary integration is going to work. At all. Please read the proposal: https://www.wikidata.org/wiki/Wikidata:Wiktionary. This has nothing to do with labels, precisely because we need labels to be simple. The proposal does not detail how lexemes interact with items in the UI and in search - that's still open, and that's exactly where the things you have been mentionen will have their place. That'S going to be a lot more powerful and flexible than trying to glue extra attributes to labels.
-- daniel
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
On Mon, Mar 10, 2014 at 1:50 PM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
Hoi, There is little point to integrating Wiktionary and the current proposal if it is unclear how that information is going to be used. The proposal for all its fancy words misses the point completely and you point it out really well: it is unclear how lexemes will interact in the UI and in search.
Lexemes UI/search is not clear, but it can be clarified when needed. I don't think now it is the time, maybe after getting some experience with queries.
The current labels will one on one coincide with lexemes. I think we can agree on this.
Not always, not for all the languages, and not necessarily. A structured Wiktionary should be the interface to written (and hopefully spoken) human language. Q-item labels are for humans to have some clue what the concept is about, but the textual expression is a different topic.
Thanks, Micru
Hoi, When you look at the current use of labels, they are used to identify items. When a statement is used on an item, it uses a combination of a property and another item. What we notice is that several not so smart choices have been made in the past that make the current use of labels problematic. I remind you of the discussion of calling an item a list when it is used an a single instance.
The notion that labels on statements are not used flies in the face of it being applied in Reasonator for instance.
Forget about what a structured Wiktionary will do in abstraction, it is not where we are. We are at a point where we have labels and no clue (in a Wikidata context) if and what practical benefits embedding Wiktionary will bring. It is really nice to point to "Lemon" and say that it is a standard. But as far as I am concerned it is a lemon [1] when there is no translation in how the information can be leveraged.
I can appreciate that we have simple labels at this time. It will not stay that way. The alternative is that including Wiktionary in Wikidata will truly become a lemon [1]. I will do what I can to help prevent that, my ambition is that Wikidata will truly replace Omegawiki. Thanks, GerardM
[1] A defective https://en.wiktionary.org/wiki/defective or inadequatehttps://en.wiktionary.org/wiki/inadequateitem.
On 10 March 2014 14:03, David Cuenca dacuetu@gmail.com wrote:
On Mon, Mar 10, 2014 at 1:50 PM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, There is little point to integrating Wiktionary and the current proposal if it is unclear how that information is going to be used. The proposal for all its fancy words misses the point completely and you point it out really well: it is unclear how lexemes will interact in the UI and in search.
Lexemes UI/search is not clear, but it can be clarified when needed. I don't think now it is the time, maybe after getting some experience with queries.
The current labels will one on one coincide with lexemes. I think we can agree on this.
Not always, not for all the languages, and not necessarily. A structured Wiktionary should be the interface to written (and hopefully spoken) human language. Q-item labels are for humans to have some clue what the concept is about, but the textual expression is a different topic.
Thanks, Micru
Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l
Hi,
I don't know which kind of wrong choices you are talking about, maybe you can expand on that? If you would have preferred labels to be treated as statements with ranks, qualifiers, etc, there are already properties like "birth name (P513)", "short name (P743)", etc. which are properties that you can use *now*, and nothing prevents you of proposing new properties in that direction for historical names. True that they would become more useful with the mono-/multi-lingual datatype, but it will be there some day.
I cannot "forget about what a structured Wiktionary will do in abstraction" because that is a totally flawed argument. Same could have been said about Wikidata some time ago about the potential benefits to Wikipedia... The benefits are only known in abstraction, and only by doing it we'll know the answer.
Even being technically more advanced, Omegwiki didn't gather a community for a number of reasons. Wiktionary managed to gather a community, but has strong technical flaws. Don't you think it is worth it to learn the lessons from each site and forget about one-sided preferences?
Thanks, Micru
On Mon, Mar 10, 2014 at 2:27 PM, Gerard Meijssen gerard.meijssen@gmail.comwrote:
Hoi, When you look at the current use of labels, they are used to identify items. When a statement is used on an item, it uses a combination of a property and another item. What we notice is that several not so smart choices have been made in the past that make the current use of labels problematic. I remind you of the discussion of calling an item a list when it is used an a single instance.
The notion that labels on statements are not used flies in the face of it being applied in Reasonator for instance.
Forget about what a structured Wiktionary will do in abstraction, it is not where we are. We are at a point where we have labels and no clue (in a Wikidata context) if and what practical benefits embedding Wiktionary will bring. It is really nice to point to "Lemon" and say that it is a standard. But as far as I am concerned it is a lemon [1] when there is no translation in how the information can be leveraged.
I can appreciate that we have simple labels at this time. It will not stay that way. The alternative is that including Wiktionary in Wikidata will truly become a lemon [1]. I will do what I can to help prevent that, my ambition is that Wikidata will truly replace Omegawiki. Thanks, GerardM
[1] A defective https://en.wiktionary.org/wiki/defective or inadequatehttps://en.wiktionary.org/wiki/inadequateitem.
On 10 March 2014 14:03, David Cuenca dacuetu@gmail.com wrote:
On Mon, Mar 10, 2014 at 1:50 PM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, There is little point to integrating Wiktionary and the current proposal if it is unclear how that information is going to be used. The proposal for all its fancy words misses the point completely and you point it out really well: it is unclear how lexemes will interact in the UI and in search.
Lexemes UI/search is not clear, but it can be clarified when needed. I don't think now it is the time, maybe after getting some experience with queries.
The current labels will one on one coincide with lexemes. I think we can agree on this.
Not always, not for all the languages, and not necessarily. A structured Wiktionary should be the interface to written (and hopefully spoken) human language. Q-item labels are for humans to have some clue what the concept is about, but the textual expression is a different topic.
Thanks, Micru
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
"David Cuenca" dacuetu@gmail.com writes:
Lexemes UI/search is not clear, but it can be clarified when needed. I don't think now it is the time, maybe after getting some experience with queries.
If you read linguist literature, you'll find no clear cut definion of "lexeme" across all languages (nor "word" for that matter), you will find that relating lexemes of different languages per their semantic values (vulgo "translation") can be extremely difficult, and you will find lots of edge cases ("1" being a lexeme of many languages? Or none at all?) -- so coming to a workable solution about the meaning of "lexeme" and relations between labels and lexemes, and their possible other properties should be worth our while.
Purodha
Am 10.03.2014 15:53, schrieb P. Blissenbach:
If you read linguist literature, you'll find no clear cut definion of "lexeme" across all languages (nor "word" for that matter), you will find that relating lexemes of different languages per their semantic values (vulgo "translation") can be extremely difficult, and you will find lots of edge cases ("1" being a lexeme of many languages? Or none at all?) -- so coming to a workable solution about the meaning of "lexeme" and relations between labels and lexemes, and their possible other properties should be worth our while.
In that context - Purodha, what's your take on the Wiktionary proposal https://www.wikidata.org/wiki/Wikidata:Wiktionary? I'm curious what you think of it. We briefly talked about this kind of model in Amsterdam last year - I hope the proposal is what you hoped for, at least roughly :)
-- daniel
"Daniel Kinzler" daniel.kinzler@wikimedia.de writes:
Am 10.03.2014 15:53, schrieb P. Blissenbach:
If you read linguist literature, you'll find no clear cut definion of "lexeme" across all languages (nor "word" for that matter), you will find that relating lexemes of different languages per their semantic values (vulgo "translation") can be extremely difficult, and you will find lots of edge cases ("1" being a lexeme of many languages? Or none at all?) -- so coming to a workable solution about the meaning of "lexeme" and relations between labels and lexemes, and their possible other properties should be worth our while.
In that context - Purodha, what's your take on the Wiktionary proposal https://www.wikidata.org/wiki/Wikidata:Wiktionary? I'm curious what you think of it. We briefly talked about this kind of model in Amsterdam last year - I hope the proposal is what you hoped for, at least roughly :)
I read it and I am thinking it over :-) It's sufficiently general to be useful, but there are points that need further refinement, or modifications.
I shall write some comments in a while.
Purodha
Am 10.03.2014 13:50, schrieb Gerard Meijssen:
Hoi, There is little point to integrating Wiktionary and the current proposal if it is unclear how that information is going to be used.
It's going to be used as a dictionary and thesaurus, just like Wiktionary.
The proposal for all its fancy words misses the point completely and you point it out really well: it is unclear how lexemes will interact in the UI and in search.
But the conceptual relationship between lexemes, senses, and items is well defined.
It's just the UI details that need to be sorted out. They could be integrated with aliases and labels "somehow", but I have no clear idea of what should look like yet.
The current labels will one on one coincide with lexemes. I think we can agree on this.
No. There will be a lot of lexemes that will not be used as labels for data items (just as there are many words/meanings on Wikionary with no Wikipedia article), and there will be some labels that are not lexemes (like most names of People and Places, and also perhaps common misspellings).
-- daniel
Thanks, GerardM
On 10 March 2014 12:43, Daniel Kinzler <daniel.kinzler@wikimedia.de mailto:daniel.kinzler@wikimedia.de> wrote:
Am 08.03.2014 11:22, schrieb Gerard Meijssen: > At this moment there is a start of having "badges". They are at this stage basic > information on the article level. It demonstrates that we CAN have information > that is beyond statements. It is arguably not sufficient, an argument made in > bug 40810#c38. Badges are editorial information (they say somthine about an article in the Wikimedia universe), they don't say anthing about the entity itself. IF they did, they would be (part of) statements. > When Wiktionary is to be integrated, labels are what Wiktionary is about. This > should be obvious, The argument is that we can leave labels for now. It requires > revisiting in the not to far off future. This is not how Wiktionary integration is going to work. At all. Please read the proposal: <https://www.wikidata.org/wiki/Wikidata:Wiktionary>. This has nothing to do with labels, precisely because we need labels to be simple. The proposal does not detail how lexemes interact with items in the UI and in search - that's still open, and that's exactly where the things you have been mentionen will have their place. That'S going to be a lot more powerful and flexible than trying to glue extra attributes to labels. -- daniel > _______________________________________________ > Wikidata-l mailing list > Wikidata-l@lists.wikimedia.org <mailto:Wikidata-l@lists.wikimedia.org> > https://lists.wikimedia.org/mailman/listinfo/wikidata-l > -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. _______________________________________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org <mailto: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
On Thu, Mar 6, 2014 at 3:30 PM, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:
Hey everyone,
Since some time now ranks are available. They are meant as a way to help manage the vast amount of information in Wikidata and make sense of them. One important point is to be able to "hide" old and wrong information using the normal and deprecated ranks. This allows us to for example only show the current leader of a country when asked for it instead of all the ones that have had this title at some point in the past. We want to move forward with making use of this now. This means a few things in particular:
- The property parser function {{#property:P123}} will be changed to
only return preferred values if they are available. If none are available then the normal ones will be returned.
- Lua will be adapted to also by default only return preferred values
if available and otherwise normal values.
- Simple queries (like "give me the item with ISBN 12345678) will only
return items with the value marked as preferred if available and otherwise normal values.
- Complex queries will only return items with the values marked as
preferred (and if not available normal) initially. Later all can be searched for explicitly as well but by default still only items with the values marked as preferred (and if not available normal) will be returned.
This in essence means that people will need to start marking values as preferred and deprecated where appropriate. This change will happen within the next weeks. I don't yet know exactly when the code change will be ready.
Onwards to a Wikidata that can meaningfully work with historical information \o/
The changes are ready for deployment now. We plan to have them go live on Wikisource and Wikivoyage on 25th of April and on Wikipedia on 27th of April.
Cheers Lydia
On Sun, Mar 16, 2014 at 2:59 PM, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:
The changes are ready for deployment now. We plan to have them go live on Wikisource and Wikivoyage on 25th of April and on Wikipedia on 27th of April.
And that should of course be March instead of April...
Cheers Lydia