Am 17.05.2015 um 00:46 schrieb John Erling Blad:
> Your description is pretty far from whats in the proposal right now.
> The proposal is not clear at all, so I would say update it and
> resubmit if for a new discussion.
Can you explain where you think my description is inconsistent with the curre
John, sorry, I guess I was too slow - as far as I understand you have now
re-read the 13-08 proposal, which has made my last Email redundant.
https://www.wikidata.org/w/index.php?title=Wikidata_talk:Wiktionary/Development/Proposals/2015-05&diff=216035102&oldid=216029531
I hope that the model is c
Daniel's answer fits exactly with the proposal (which is unsurprising,
because he reviewed and certainly influenced it).
To make it clear again: the proposal on
https://www.wikidata.org/wiki/Wikidata:Wiktionary/Development/Proposals/2015-05
is a proposal for the tasks that need to be performed. Yo
Your description is pretty far from whats in the proposal right now.
The proposal is not clear at all, so I would say update it and
resubmit if for a new discussion.
On Sat, May 16, 2015 at 12:21 PM, Daniel Kinzler
wrote:
> Am 15.05.2015 um 01:11 schrieb John Erling Blad:
>> How do we go from a s
Am 15.05.2015 um 01:11 schrieb John Erling Blad:
> How do we go from a spelled form of a lexeme at Wiktionary and to an
> identifier on Wikidata?
What do you mean by "go to"? And what do you mean by "identifier on Wikidata" -
Items, Lexemes, Senses, or Forms?
Generally, Wiktionary currently comb
Hoi,
This is in other words what my question amounts to. The question that Denny
does not answer.
Thanks,
GerardM
On 15 May 2015 at 01:11, John Erling Blad wrote:
> Seems like this is doable, and it does describe a solution to how
> Wiktionary can be linked form Wikidata. It is although no
Seems like this is doable, and it does describe a solution to how
Wiktionary can be linked form Wikidata. It is although not completely
clear to me how some remaining problems can be solved.
How do we go from a spelled form of a lexeme at Wiktionary and to an
identifier on Wikidata? And how do we
Yes, found a sentence in task 2. :)
On Fri, May 15, 2015 at 12:34 AM, Daniel Kinzler
wrote:
> Am 14.05.2015 um 23:54 schrieb John Erling Blad:
>> Let me rephrase, and the question is for Denny unless someone knows the
>> answer.
>>
>> Lexemes at different languages share a spelling, and that is
Am 14.05.2015 um 23:54 schrieb John Erling Blad:
> Let me rephrase, and the question is for Denny unless someone knows the
> answer.
>
> Lexemes at different languages share a spelling, and that is the
> reason why they are linked together. That kind of linkage can be
> automated. Some other page
Let me rephrase, and the question is for Denny unless someone knows the answer.
Lexemes at different languages share a spelling, and that is the
reason why they are linked together. That kind of linkage can be
automated. Some other pages (usually in other namespaces) at those
projects should be li
Hoi,
>From a Wiktionary point of view they are not the same. Wiktionary links
articles that have the same spelling in common. For every meaning in every
language they link to the articles that have a specific spelling and it is
potluck if that meaning actually exists.
Thanks,
GerardM
On 14 M
As I read your proposal you want to automate IW-linkage of similar
lexemes, but how do you want to handle those cases where the lexemes
are not similar? Your example "the tea room" vs "le questions sur let
mots" is such a case. Is this handled as a mixed automatic/manuel
case, with lexemes added au
Hoi,
What is your definition of a language and, if it is not along the lines of
the ISO-639-3, how are they organised.
One of the first things to do is understand how these languages can be
incorporated in Wikidata and prepare for that. Do you have a list with all
the languages and hopefully their
French wiktionary uses more than 2000 languages
JAnD
2015-05-07 23:25 GMT+02:00 Federico Leva (Nemo) :
> Andy Mabbett, 07/05/2015 22:53:
>
>> >The Wiktionary communities tend to strongly disagree that splitting
>>> entries
>>> >per language would be easier for either editors or readers.
>>>
>> Ho
Il 08/05/2015 15:40, Federico Leva (Nemo) ha scritto:
Bene*, 08/05/2015 11:15:
So having a Wikibase installation only for Wiktionary makes more sense
in my opinion as that is the same plan we currently have for
Commons/Wikiquote etc.
We? Please remember that's only a personal proposal, which n
Nemo was more effective than me in explaining what I meant. For a partial
excuse, I had to rewrite and simplify my message several times, because I
was trying to make up my mind while writing. :)
L.
Il 08/mag/2015 18:47, "Federico Leva (Nemo)" ha
scritto:
> Paul Houle, 08/05/2015 18:30:
>
>> Con
Hoi,
I have read it, I had read it before, I commented at the time and imho it
is flawed.
What I am waiting for is why there is this insistence on not having
attributes on labels, why there is a "need" for the constructs that you
mentioned that only duplicate what is already there. It is an answer
I very much appreciate OmegaWiki - it has been a trailblazer for many of
the ideas in Wikidata, and as you say, it is the granddaddy in many ways.
OmegaWiki has been extensively looked into and the results from that have
directly flown into the current proposal. The write up of that analysis can
be
Hoi,
Please do appreciate that OmegaWiki, originally WiktionaryZ, really wants
to be considered in all this. It is the grand daddy of Wikidata and it does
combine everything you would want as far as lexical data is concerned.
Thanks,
GerardM
On 8 May 2015 at 18:18, Denny Vrandečić wrote:
>
Paul Houle, 08/05/2015 18:30:
Concepts and words are different things, or better yet, words (word
senses, ...) are a special kind of concept.
I think however that Sannita's point is important and interesting.
It can perhaps be illustrated with a simple point: Wikidata items (like
Wikipedia
Concepts and words are different things, or better yet, words (word
senses, ...) are a special kind of concept.
I was looking at what the data model for a system that supports logical
representation of 100% of critical knowledge in business and technical
documents over narrow domains.
One thin
I very much agree with Lydia and Nemo that there should not be a separate
Wikibase instance for Wiktionary data. Having a single community in a
single project, and not having to vote for admins here and there, have two
different watchlists, have documentation be repeated, policies being
rediscussed
2015-05-08 15:33 GMT+02:00 Federico Leva (Nemo) :
> +1. The Wikimedia community has been long able to think of all the Wikimedia
> projects as an organic whole. Software, on the other hand, too often forced
> innatural divisions.
>
> Wiktionary, Wikipedia, Commons and Wikiquote (to name the main ca
Bene*, 08/05/2015 11:15:
So having a Wikibase installation only for Wiktionary makes more sense
in my opinion as that is the same plan we currently have for
Commons/Wikiquote etc.
We? Please remember that's only a personal proposal, which no Wikiquote
community has ever subscribed to (yet). (C
Lydia Pintscher, 08/05/2015 09:45:
I think we have a
>lot of experience here of running services that are different
>technically but unified by common goals and common purposes and linking
>them.
I would argue we are actually really really bad at it;-)
+1. The Wikimedia community has been lon
Only for some templates, project pages and categories.
The only way it makes sense to link to an article of Wiktionary is when
someone wants to look up what a word can mean.
Romaine
2015-05-07 14:56 GMT+02:00 Yair Rand :
> Task 1 as described on the proposal page isn't completely clear on how i
I personally am waiting for Meta to be added.
Romaine
2015-05-07 14:08 GMT+02:00 Andy Mabbett :
> On 7 May 2015 at 11:57, Ricordisamoa wrote:
>
> > Let's focus on Commons, OpenStreetMap, queries, arbitrary access, new
> > datatypes?
>
> OSM in what context?
>
> Also, we should throw WikiSpecies
On 08.05.2015 11:30, Thomas Douillard wrote:
I don't get this, is this really a technical issue or just an interface
one ? It can be pretty clear to users that the semantic entity pages are
very different from lexical entities in the same instance just by
tweaking the UI. Or with separate instanc
Il 07/05/2015 14:08, Andy Mabbett ha scritto:
On 7 May 2015 at 11:57, Ricordisamoa wrote:
Let's focus on Commons, OpenStreetMap, queries, arbitrary access, new
datatypes?
OSM in what context?
Adding mutual links, keeping them up to date, building applications that
use both databases, etc.
Am 07.05.2015 um 19:38 schrieb Milos Rancic:
> BTW, Daniel, there are standardized templates for "real" "interwiki" links
> (links to the entries with the same meaning in other languages on the same
> Wiktionary). It makes sense that Wikidata creates a db for that. Though, it
> isn't trivial and as
I don't get this, is this really a technical issue or just an interface one
? It can be pretty clear to users that the semantic entity pages are very
different from lexical entities in the same instance just by tweaking the
UI. Or with separate instances this can be confusing as well if not well
do
On Fri, May 8, 2015 at 10:16 AM Bene* wrote:
> Hi
>
> > I do not think a separate Wikibase instance would be needed to provide
> > the data for Wiktionary. I think this can and should be done on
> > Wikidata. But as said by Milos and pointed out by Gerard, lexical
> > knowledge does indeed requir
Hi
I do not think a separate Wikibase instance would be needed to provide
the data for Wiktionary. I think this can and should be done on
Wikidata. But as said by Milos and pointed out by Gerard, lexical
knowledge does indeed require a different data schema. This is why the
proposal introduce
Hi,
On 08.05.2015 09:40, Stas Malyshev wrote:
Hi!
Other technical solutions can be found for keeping content apart when
needed (e.g., separate dumps by entity types).
It's not only dumps, it's also searches, APIs, special pages, etc. Of
course, everything can be solved with enough time and c
On Fri, May 8, 2015 at 9:33 AM, Stas Malyshev wrote:
> Hi!
>
>> The benefits of having it in one instance are huge imho. Our community
>> exists and knows how to handle structured data by now.
>> Processes/documentation/etc are set up. The world outside is starting
>> to realize that Wikidata is t
Hi!
> Other technical solutions can be found for keeping content apart when
> needed (e.g., separate dumps by entity types).
It's not only dumps, it's also searches, APIs, special pages, etc. Of
course, everything can be solved with enough time and coding, but to me
it looks like running a DB ser
On 08.05.2015 08:50, Lydia Pintscher wrote:
On Fri, May 8, 2015 at 7:15 AM, Stas Malyshev wrote:
I am worried that having two different data sets within the same
instance would be a problem for tools working with the data, and for
humans too. And frankly, I don't see too much benefit - virtuall
Hi!
> The benefits of having it in one instance are huge imho. Our community
> exists and knows how to handle structured data by now.
> Processes/documentation/etc are set up. The world outside is starting
> to realize that Wikidata is the place to go to for structured data
> around Wikimedia now.
On Fri, May 8, 2015 at 7:15 AM, Stas Malyshev wrote:
> I am worried that having two different data sets within the same
> instance would be a problem for tools working with the data, and for
> humans too. And frankly, I don't see too much benefit - virtually all
> added value Wikidata has now is w
Hoi,
You do not address how it prevents redundancy. I do not care for lexemes
nor forms when they do not incorporate labels. That is something that you
can explain now.
Thanks,
GerardM
On 8 May 2015 at 07:00, Denny Vrandečić wrote:
> I mean, the lexical data in Wikidata according to the pr
I mean, the lexical data in Wikidata according to the proposal would allow
for statements on Lexemes and Forms. I slipped into the future for a moment
;)
On Thu, May 7, 2015 at 9:32 PM Denny Vrandečić wrote:
> I am not sure I understand what you are saying. The lexical data in
> Wikidata does al
Hoi,
Again I do not care for lexemes and forms when they are distinct from
labels. I hate redundancy.
Thanks,
GerardM
On 8 May 2015 at 06:32, Denny Vrandečić wrote:
> I am not sure I understand what you are saying. The lexical data in
> Wikidata does allow for statements on Lexemes and Form
Hi!
> I do not think a separate Wikibase instance would be needed to provide
> the data for Wiktionary. I think this can and should be done on
> Wikidata. But as said by Milos and pointed out by Gerard, lexical
I am worried that having two different data sets within the same
instance would be a p
Hoi,
I have asked repeatedly to be allowed to indicated on labels that they were
in use up to a given time. The argument that labels are "only" for
identification is imho not valid because it denies the need that cannot be
expressed in a similar way. Having other constructs that do not address
this
I am not sure I understand what you are saying. The lexical data in
Wikidata does allow for statements on Lexemes and Forms, as the proposal
states explicitly.
On Thu, May 7, 2015 at 9:25 PM Gerard Meijssen
wrote:
> Hoi,
> Given the opposition to having statements on the level of the label, it
>
Hoi,
Given the opposition to having statements on the level of the label, it
does not make sense to have Wiktionary included in Wikidata.
Thanks,
GerardM
On 8 May 2015 at 06:19, Denny Vrandečić wrote:
> I would disagree with requiring the Wiktionary communities to change their
> ways. Inst
I would disagree with requiring the Wiktionary communities to change their
ways. Instead we should adapt our plans to fit into the way they are set up.
Even if the English Wiktionary community would change to have per-language
pages instead of the current system, it would be rather unlikely that a
Andy Mabbett, 07/05/2015 22:53:
>The Wiktionary communities tend to strongly disagree that splitting entries
>per language would be easier for either editors or readers.
How many languages are currently used? How will this scale to ~300 languages?
Hm? Last time I counted, the English Wiktionar
On 7 May 2015 at 18:27, Yair Rand wrote:
> The Wiktionary communities tend to strongly disagree that splitting entries
> per language would be easier for either editors or readers.
How many languages are currently used? How will this scale to ~300 languages?
--
Andy Mabbett
@pigsonthewing
http
Citiranje Yair Rand :
> The Wiktionary communities tend to strongly disagree that splitting entries
> per language would be easier for either editors or readers. It has been
> discussed before numerous times over the years.
I do not see this strong disagreement. The last discussion about it was at
BTW, Daniel, there are standardized templates for "real" "interwiki" links
(links to the entries with the same meaning in other languages on the same
Wiktionary). It makes sense that Wikidata creates a db for that. Though, it
isn't trivial and assumes meanings. Though, it seems to me reasonably
pos
Il 07/05/2015 16:03, Daniel Kinzler ha scritto:
Am 07.05.2015 um 14:56 schrieb Yair Rand:
Task 1 as described on the proposal page isn't completely clear on how it would
work. Would the generated "items" have Q-ids? Would it be possible to link
Wiktionary entries to non-Wiktionary pages in the v
The Wiktionary communities tend to strongly disagree that splitting entries
per language would be easier for either editors or readers. It has been
discussed before numerous times over the years.
On Thu, May 7, 2015 at 1:17 PM, Smolenski Nikola wrote:
> Citiranje Jo :
> > What you get on a Wikti
Citiranje Jo :
> What you get on a Wiktionary page is a description of words in several
> languages with that particular spelling. Of course 1 spelling can also be
> several words in 1 language already.
And why? Why not having a separate page for every language, while the spelling
would just be a
2015-05-07 14:28 GMT+02:00 Lydia Pintscher :
> However we also need to look into
> the future. Wiktionary support needs a lot of input to make sure we're
> doing the right thing. And it's good to give that time.
Totally agree with that. There's plenty of work to do for the team, we
all know that,
Am 07.05.2015 um 14:56 schrieb Yair Rand:
> Task 1 as described on the proposal page isn't completely clear on how it
> would
> work. Would the generated "items" have Q-ids? Would it be possible to link
> Wiktionary entries to non-Wiktionary pages in the very rare situations that
> make
> sense (
It is of limited value (as Gerard explained) to do major work on
Wiktionary. Wiktionary articles could be transferred to the structured data
in the similar way like Wikipedia articles, with a lot of trouble. Thus not
the most optimal solution.
What makes sense is to incorporate OmegaWiki logic int
Task 1 as described on the proposal page isn't completely clear on how it
would work. Would the generated "items" have Q-ids? Would it be possible to
link Wiktionary entries to non-Wiktionary pages in the very rare situations
that make sense (articles on particular series of (not-language-associate
Hey folks :)
You're absolutely right that we need to focus on a few other things
first (UI redesign, units, queries, arbitrary access, data quality
tools incl watchlist improvements). However we also need to look into
the future. Wiktionary support needs a lot of input to make sure we're
doing the
On 7 May 2015 at 11:57, Ricordisamoa wrote:
> Let's focus on Commons, OpenStreetMap, queries, arbitrary access, new
> datatypes?
OSM in what context?
Also, we should throw WikiSpecies into the mix.
--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
___
Forgive me, but at the 2014 WikiCon in Cologne, I saw a talk that would see
Wiktionary converted to a separate wikibase installation, collapsing all
the wikitionary languages into items. THAT could reasonably be linked to
Wikidata, or "just" cross-references via properties.
Trying to wedge the cur
Hi Denny,
I would strongly advise against connecting Wiktionary to Wikidata in the
status quo, mainly for the reasons Gerard summarized.
While wikt's 'data model' probably makes sense for a spelling-based
dictionary, it does not for a concept-based knowledge base like ours.
Even turning Wiktiona
What you get on a Wiktionary page is a description of words in several
languages with that particular spelling. Of course 1 spelling can also be
several words in 1 language already.
It's at the level of the definition that one can link to the current
Wikidata. Provided Wikidata wants to have entri
Hoi,
The practice makes sense for Wiktionary. As a matter of fact I think I
added quite a few with my bot. My point is not that it would not make
sense, my point is that it does NOT easily connect to Wikidata. When a
separate Wikibase is used for this ... fine. That makes sense.
Thanks,
Gerard
Citiranje Gerard Meijssen :
> The interwiki links to Wiktionary are from an interwiki point of view
> EXTREMELY easy to do. The problem with those links is that they cannot be
> uniquely linked to existing items to Wikidata and thereby it becomes
> unrealistic to do it in a meaningful way at this t
Hoi,
The interwiki links to Wiktionary are from an interwiki point of view
EXTREMELY easy to do. The problem with those links is that they cannot be
uniquely linked to existing items to Wikidata and thereby it becomes
unrealistic to do it in a meaningful way at this time.
Wiktionary has one articl
On Thu, May 7, 2015 at 2:53 PM, Gerard Meijssen
wrote:
> Hoi,
> Would it not make sense to FIRST finish a few things.. Like Commons and
> Query ?
One of the primary things Wikidata was supposed to do is manage
interlanguage links for Wikimedia projects. That isnt finished until
Wiktionary joins
The work on queries and arbitrary access is well on its way, and also the
new UI is continually being developed and deployed. I don't think that it
is too early to think and gather consensus on how the steps for Wiktionary
could look like. I am certainly not proposing to stop the current work on
qu
Hoi,
Would it not make sense to FIRST finish a few things.. Like Commons and
Query ?
Thanks,
GerardM
On 7 May 2015 at 04:54, Denny Vrandečić wrote:
> It is rather clear that everyone wants Wikidata to also support
> Wiktionary, and there have been plenty of proposals in the last few years.
>
69 matches
Mail list logo