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

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 or inadequate item.

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

--
Etiamsi omnes, ego non