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(a)gmail.com>wrote;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 <https://en.wiktionary.org/wiki/defective> or
inadequate<https://en.wiktionary.org/wiki/inadequate>itemt;item.
On 10 March 2014 14:03, David Cuenca <dacuetu(a)gmail.com> wrote:
On Mon, Mar 10, 2014 at 1:50 PM, Gerard Meijssen
<
gerard.meijssen(a)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(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
--
Etiamsi omnes, ego non