Re: [Wikidata-l] Wikidata for Wiktionary

[Denny Vrandečić]

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 found here:

https://www.wikidata.org/wiki/Wikidata:Comparison_of_Projects_and_Proposals_for_Wiktionary



On Fri, May 8, 2015 at 11:46 AM Gerard Meijssen 
wrote:

> 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:
>
>> 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, etc. sounds like a smart move. Also, the Item-data and the
>> Lexical-data would be much tighter connected than with any other project,
>> and queries should be able to seamlessly work between them.
>>
>> The only reason Commons is proposed to have its own instance is because
>> the actual multimedia files are there, and the community caring about those
>> files is there and should work in one place. If there was only a single
>> Wiktionary project, it might also be worth to consider having the
>> structured data there - but since there are more than 150 editions of
>> Wiktionary, a centralized place makes more sense. And since we already have
>> Wikidata for that, I don't see the advantage of splitting the potential
>> communities.
>>
>>
>> On Fri, May 8, 2015 at 8:35 AM Luca Martinelli 
>> wrote:
>>
>>> 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 cases)
>>> link
>>> > to each other all the time in a constructive division of labour. It
>>> makes no
>>> > sense to make connections between them harder.
>>>
>>>
>>> I start from here, since Nemo got the point IMHO: the fact that every
>>> project has its own scope doesn't imply that the whole of the
>>> community works on different scopes - we just decided to split up our
>>> duties among ourselves. But it's not just that.
>>>
>>> TL;DR: Wikidata and Wiktionary deal with the same things (concepts),
>>> therefore are best-suited for each other, given some needed
>>> adaptations. Structured Data and Structured Wikiquote deal with
>>> different things (objects), therefore are not to be considered good
>>> examples.
>>>
>>> Long version here:
>>>
>>> In theory, one might just agree that a separate instance of Wikibase
>>> might be the best solution for Wiktionary, but Structured Data and
>>> Structured Wikiquote are different from a theoretical "Structured
>>> Wiktionary", because they respectively deal with images, quotes and
>>> words.
>>>
>>> Images and quotes are describable *objects*, as the Wiki*
>>> articles/pages are, and there are billions and billions of those
>>> objects out there. This is the main, if not just the only, reason why
>>> we *have* to put up a separate instance of Wikibase to deal with them:
>>> thinking that Wikidata might deal with such an infinite task is just
>>> nuts.
>>>
>>> Words, on the other hands, are describable *concepts*, not objects.
>>> They can be linked one another by relation, they have synonyms and
>>> opposites, they can be regrouped or separated, etcetera, which is
>>> exactly what we're currently doing with Wikidata items.
>>>
>>> I know, words are even more than images and quotes, so it would be
>>> even more nuts to think to deal with this just with Wikidata - but
>>> Wikidata is *already* structured for dealing with concepts, making it
>>> the best choice for integrating data from Wiktionary.
>>>
>>> In other words, Wikidata and Wiktionary both work with *concepts*,
>>> while all the other projects work with *objects*. From a more
>>> practical point of view, why should I have a Wikidata item about, say,
>>> present tense[1] *AND* a completely similar item on "Structured
>>> Wiktionary"? It's the same concept, why should I have it in two
>>> different-yet-linked databases, belonging to and maintained by the
>>> very same community? Why can't we work something out to keep all
>>> informations just in one database?
>>>
>>> This is why I think that setting up a separate Wikibase for Wiktionary
>>> might end up in doubling our efforts and splitting our communities,
>>> which is exactly the opposite of what we need to do (halving the
>>> efforts and doubling the community

Re: [Wikidata-l] Wikidata for Wiktionary

[Gerard Meijssen]

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:

> 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, etc. sounds like a smart move. Also, the Item-data and the
> Lexical-data would be much tighter connected than with any other project,
> and queries should be able to seamlessly work between them.
>
> The only reason Commons is proposed to have its own instance is because
> the actual multimedia files are there, and the community caring about those
> files is there and should work in one place. If there was only a single
> Wiktionary project, it might also be worth to consider having the
> structured data there - but since there are more than 150 editions of
> Wiktionary, a centralized place makes more sense. And since we already have
> Wikidata for that, I don't see the advantage of splitting the potential
> communities.
>
>
> On Fri, May 8, 2015 at 8:35 AM Luca Martinelli 
> wrote:
>
>> 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 cases)
>> link
>> > to each other all the time in a constructive division of labour. It
>> makes no
>> > sense to make connections between them harder.
>>
>>
>> I start from here, since Nemo got the point IMHO: the fact that every
>> project has its own scope doesn't imply that the whole of the
>> community works on different scopes - we just decided to split up our
>> duties among ourselves. But it's not just that.
>>
>> TL;DR: Wikidata and Wiktionary deal with the same things (concepts),
>> therefore are best-suited for each other, given some needed
>> adaptations. Structured Data and Structured Wikiquote deal with
>> different things (objects), therefore are not to be considered good
>> examples.
>>
>> Long version here:
>>
>> In theory, one might just agree that a separate instance of Wikibase
>> might be the best solution for Wiktionary, but Structured Data and
>> Structured Wikiquote are different from a theoretical "Structured
>> Wiktionary", because they respectively deal with images, quotes and
>> words.
>>
>> Images and quotes are describable *objects*, as the Wiki*
>> articles/pages are, and there are billions and billions of those
>> objects out there. This is the main, if not just the only, reason why
>> we *have* to put up a separate instance of Wikibase to deal with them:
>> thinking that Wikidata might deal with such an infinite task is just
>> nuts.
>>
>> Words, on the other hands, are describable *concepts*, not objects.
>> They can be linked one another by relation, they have synonyms and
>> opposites, they can be regrouped or separated, etcetera, which is
>> exactly what we're currently doing with Wikidata items.
>>
>> I know, words are even more than images and quotes, so it would be
>> even more nuts to think to deal with this just with Wikidata - but
>> Wikidata is *already* structured for dealing with concepts, making it
>> the best choice for integrating data from Wiktionary.
>>
>> In other words, Wikidata and Wiktionary both work with *concepts*,
>> while all the other projects work with *objects*. From a more
>> practical point of view, why should I have a Wikidata item about, say,
>> present tense[1] *AND* a completely similar item on "Structured
>> Wiktionary"? It's the same concept, why should I have it in two
>> different-yet-linked databases, belonging to and maintained by the
>> very same community? Why can't we work something out to keep all
>> informations just in one database?
>>
>> This is why I think that setting up a separate Wikibase for Wiktionary
>> might end up in doubling our efforts and splitting our communities,
>> which is exactly the opposite of what we need to do (halving the
>> efforts and doubling the community).[2]
>>
>> Sorry for the long post. :)
>>
>>
>> [1] https://www.wikidata.org/wiki/Q192613
>> [2] Not sure if I have to remark this, but please, PLEASE, note this
>> is just an exaggeration for argument's sake, I have of course no data
>> that might confirm factually that the WD community will surge by 100%.
>> I just want to make clear my concept (heh).
>>
>> --
>> Luca "Sannita" Martinelli
>> http://it.wikipedia.org/wiki/Utente:Sannita
>>
>> ___
>> Wikidata-l mailing list
>> Wikidata-l@lists.wikimedia.org
>> http

[Wikidata-l] Forthcoming editathons

[Andy Mabbett]

I am hosting some editathons:


Thurs 28 May, Birmingham:

   
https://en.wikipedia.org/wiki/Wikipedia:GLAM/Royal_Society_of_Chemistry/BH-2015

at Birmingham Museums Collection centre (only rarely open to the
public!). We'll enjoy a 'backstage tour and the opportunity to
photograph objects, as well,of course, writing articles.


Weds 29 July, London

   
https://en.wikipedia.org/wiki/Wikipedia:GLAM/Royal_Society_of_Chemistry/BH-2015

   in the library of the Royal Society of Chemistry. The focus will be
on chemistry-related topics; including both scientific and
non-scientific content (the latter including biographies, for
example). I hope we'll have someone there from the ChemSpider team.


Sat 8 August, North Cheshire

Watch this space (and keep the date free)!


In each case, lunch and refreshments will be provided; there will be
support for new editors (maybe you can help?) and we'll work on sister
projects such as Wikimedia Commons, Wikidata and Wikisource, as well
as Wikipedia.

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

-- 
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] Wikidata for Wiktionary

[Federico Leva (Nemo)]

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 articles) connect well to Commons categories, Wikiquote 
articles (authors/themes/works), Wikisource authors; they don't 
necessarily connect well to the building blocks (pages), like individual 
files, quotations, chapters.	Similarly, Wiktionary is in large majority 
very overlapping and connected with the other projects, as long as you 
consider a subset of it (say, nominative form of nouns).
	The fact that Wiktionary contains an impressive mass of "other stuff" 
doesn't make it *so* special as to force a separate install, even though 
more aggressive/complete implementations of structured data might 
require one. Just like Wikiquote and Commons currently benefit (from) 
Wikidata even though one can imagine broader uses with different 
technical requirements.


Nemo

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

Re: [Wikidata-l] Wikidata for Wiktionary

[Paul Houle]

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 thing I tried was (more or less) Wikidata+Wordnet and I found the
Wordnet part was difficult to apply.  Where Wikidata concepts match text
chunks it works OK,  but trying to deal with the verbs and prepositions and
all that stuff is labor intensive,  hard to do correctly,  and doesn't
contribute much to machine readable semantics.  It is more useful to model
verb functions in terms of discontinuous chunks which form templates,  i.e.
often the verb and associated prepositions together are a good unit of
modelling.

Super-Wordnet,  however,  will still be interesting to humans who might
want to pin down exact word senses in a contract.

On Fri, May 8, 2015 at 11:35 AM, Luca Martinelli 
wrote:

> 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 cases)
> link
> > to each other all the time in a constructive division of labour. It
> makes no
> > sense to make connections between them harder.
>
>
> I start from here, since Nemo got the point IMHO: the fact that every
> project has its own scope doesn't imply that the whole of the
> community works on different scopes - we just decided to split up our
> duties among ourselves. But it's not just that.
>
> TL;DR: Wikidata and Wiktionary deal with the same things (concepts),
> therefore are best-suited for each other, given some needed
> adaptations. Structured Data and Structured Wikiquote deal with
> different things (objects), therefore are not to be considered good
> examples.
>
> Long version here:
>
> In theory, one might just agree that a separate instance of Wikibase
> might be the best solution for Wiktionary, but Structured Data and
> Structured Wikiquote are different from a theoretical "Structured
> Wiktionary", because they respectively deal with images, quotes and
> words.
>
> Images and quotes are describable *objects*, as the Wiki*
> articles/pages are, and there are billions and billions of those
> objects out there. This is the main, if not just the only, reason why
> we *have* to put up a separate instance of Wikibase to deal with them:
> thinking that Wikidata might deal with such an infinite task is just
> nuts.
>
> Words, on the other hands, are describable *concepts*, not objects.
> They can be linked one another by relation, they have synonyms and
> opposites, they can be regrouped or separated, etcetera, which is
> exactly what we're currently doing with Wikidata items.
>
> I know, words are even more than images and quotes, so it would be
> even more nuts to think to deal with this just with Wikidata - but
> Wikidata is *already* structured for dealing with concepts, making it
> the best choice for integrating data from Wiktionary.
>
> In other words, Wikidata and Wiktionary both work with *concepts*,
> while all the other projects work with *objects*. From a more
> practical point of view, why should I have a Wikidata item about, say,
> present tense[1] *AND* a completely similar item on "Structured
> Wiktionary"? It's the same concept, why should I have it in two
> different-yet-linked databases, belonging to and maintained by the
> very same community? Why can't we work something out to keep all
> informations just in one database?
>
> This is why I think that setting up a separate Wikibase for Wiktionary
> might end up in doubling our efforts and splitting our communities,
> which is exactly the opposite of what we need to do (halving the
> efforts and doubling the community).[2]
>
> Sorry for the long post. :)
>
>
> [1] https://www.wikidata.org/wiki/Q192613
> [2] Not sure if I have to remark this, but please, PLEASE, note this
> is just an exaggeration for argument's sake, I have of course no data
> that might confirm factually that the WD community will surge by 100%.
> I just want to make clear my concept (heh).
>
> --
> Luca "Sannita" Martinelli
> http://it.wikipedia.org/wiki/Utente:Sannita
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>



-- 
Paul Houle

*Applying Schemas for Natural Language Processing, Distributed Systems,
Classification and Text Mining and Data Lakes*

(607) 539 6254paul.houle on Skype   ontolo...@gmail.com
https://legalentityidentifier.info/lei/lookup

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

Re: [Wikidata-l] Wikidata for Wiktionary

[Denny Vrandečić]

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, etc. sounds like a smart move. Also, the Item-data and the
Lexical-data would be much tighter connected than with any other project,
and queries should be able to seamlessly work between them.

The only reason Commons is proposed to have its own instance is because the
actual multimedia files are there, and the community caring about those
files is there and should work in one place. If there was only a single
Wiktionary project, it might also be worth to consider having the
structured data there - but since there are more than 150 editions of
Wiktionary, a centralized place makes more sense. And since we already have
Wikidata for that, I don't see the advantage of splitting the potential
communities.


On Fri, May 8, 2015 at 8:35 AM Luca Martinelli 
wrote:

> 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 cases)
> link
> > to each other all the time in a constructive division of labour. It
> makes no
> > sense to make connections between them harder.
>
>
> I start from here, since Nemo got the point IMHO: the fact that every
> project has its own scope doesn't imply that the whole of the
> community works on different scopes - we just decided to split up our
> duties among ourselves. But it's not just that.
>
> TL;DR: Wikidata and Wiktionary deal with the same things (concepts),
> therefore are best-suited for each other, given some needed
> adaptations. Structured Data and Structured Wikiquote deal with
> different things (objects), therefore are not to be considered good
> examples.
>
> Long version here:
>
> In theory, one might just agree that a separate instance of Wikibase
> might be the best solution for Wiktionary, but Structured Data and
> Structured Wikiquote are different from a theoretical "Structured
> Wiktionary", because they respectively deal with images, quotes and
> words.
>
> Images and quotes are describable *objects*, as the Wiki*
> articles/pages are, and there are billions and billions of those
> objects out there. This is the main, if not just the only, reason why
> we *have* to put up a separate instance of Wikibase to deal with them:
> thinking that Wikidata might deal with such an infinite task is just
> nuts.
>
> Words, on the other hands, are describable *concepts*, not objects.
> They can be linked one another by relation, they have synonyms and
> opposites, they can be regrouped or separated, etcetera, which is
> exactly what we're currently doing with Wikidata items.
>
> I know, words are even more than images and quotes, so it would be
> even more nuts to think to deal with this just with Wikidata - but
> Wikidata is *already* structured for dealing with concepts, making it
> the best choice for integrating data from Wiktionary.
>
> In other words, Wikidata and Wiktionary both work with *concepts*,
> while all the other projects work with *objects*. From a more
> practical point of view, why should I have a Wikidata item about, say,
> present tense[1] *AND* a completely similar item on "Structured
> Wiktionary"? It's the same concept, why should I have it in two
> different-yet-linked databases, belonging to and maintained by the
> very same community? Why can't we work something out to keep all
> informations just in one database?
>
> This is why I think that setting up a separate Wikibase for Wiktionary
> might end up in doubling our efforts and splitting our communities,
> which is exactly the opposite of what we need to do (halving the
> efforts and doubling the community).[2]
>
> Sorry for the long post. :)
>
>
> [1] https://www.wikidata.org/wiki/Q192613
> [2] Not sure if I have to remark this, but please, PLEASE, note this
> is just an exaggeration for argument's sake, I have of course no data
> that might confirm factually that the WD community will surge by 100%.
> I just want to make clear my concept (heh).
>
> --
> Luca "Sannita" Martinelli
> http://it.wikipedia.org/wiki/Utente:Sannita
>
> ___
> 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] Wikidata for Wiktionary

[Luca Martinelli]

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 cases) link
> to each other all the time in a constructive division of labour. It makes no
> sense to make connections between them harder.


I start from here, since Nemo got the point IMHO: the fact that every
project has its own scope doesn't imply that the whole of the
community works on different scopes - we just decided to split up our
duties among ourselves. But it's not just that.

TL;DR: Wikidata and Wiktionary deal with the same things (concepts),
therefore are best-suited for each other, given some needed
adaptations. Structured Data and Structured Wikiquote deal with
different things (objects), therefore are not to be considered good
examples.

Long version here:

In theory, one might just agree that a separate instance of Wikibase
might be the best solution for Wiktionary, but Structured Data and
Structured Wikiquote are different from a theoretical "Structured
Wiktionary", because they respectively deal with images, quotes and
words.

Images and quotes are describable *objects*, as the Wiki*
articles/pages are, and there are billions and billions of those
objects out there. This is the main, if not just the only, reason why
we *have* to put up a separate instance of Wikibase to deal with them:
thinking that Wikidata might deal with such an infinite task is just
nuts.

Words, on the other hands, are describable *concepts*, not objects.
They can be linked one another by relation, they have synonyms and
opposites, they can be regrouped or separated, etcetera, which is
exactly what we're currently doing with Wikidata items.

I know, words are even more than images and quotes, so it would be
even more nuts to think to deal with this just with Wikidata - but
Wikidata is *already* structured for dealing with concepts, making it
the best choice for integrating data from Wiktionary.

In other words, Wikidata and Wiktionary both work with *concepts*,
while all the other projects work with *objects*. From a more
practical point of view, why should I have a Wikidata item about, say,
present tense[1] *AND* a completely similar item on "Structured
Wiktionary"? It's the same concept, why should I have it in two
different-yet-linked databases, belonging to and maintained by the
very same community? Why can't we work something out to keep all
informations just in one database?

This is why I think that setting up a separate Wikibase for Wiktionary
might end up in doubling our efforts and splitting our communities,
which is exactly the opposite of what we need to do (halving the
efforts and doubling the community).[2]

Sorry for the long post. :)


[1] https://www.wikidata.org/wiki/Q192613
[2] Not sure if I have to remark this, but please, PLEASE, note this
is just an exaggeration for argument's sake, I have of course no data
that might confirm factually that the WD community will surge by 100%.
I just want to make clear my concept (heh).

-- 
Luca "Sannita" Martinelli
http://it.wikipedia.org/wiki/Utente:Sannita

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

Re: [Wikidata-l] Wikidata for Wiktionary

[Federico Leva (Nemo)]

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). (Cc Wikiquote-l.)


Nemo

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

Re: [Wikidata-l] Wikidata for Wiktionary

[Federico Leva (Nemo)]

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 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 cases) 
link to each other all the time in a constructive division of labour. It 
makes no sense to make connections between them harder.


Nemo

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

Re: [Wikidata-l] Last Call for Papers/Posters: IEEE Technically Sponsored SAI Intelligent Systems Conference (IntelliSys 2015)

[Lydia Pintscher]

On Fri, May 8, 2015 at 2:38 PM, Markus Krötzsch
 wrote:
> Spam. The address "Dear Colleague" sent to this mailing list is giving it
> away, I know, but for less obvious cases, a good general guideline is to
> avoid "research" conferences that ask you to pay for each paper you publish
> there. Legit research events decouple paper selection from financial aspects
> to avoid the impression that you are paying for the acceptance of your work.
> This conference even charges students more if they have a paper accepted. In
> all reputed conferences I know of, it is usually the other way around:
> scholarships are available to support students, and student authors have a
> higher chance of getting such support.

Will ban.


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

Re: [Wikidata-l] Last Call for Papers/Posters: IEEE Technically Sponsored SAI Intelligent Systems Conference (IntelliSys 2015)

[Markus Krötzsch]

Spam. The address "Dear Colleague" sent to this mailing list is giving 
it away, I know, but for less obvious cases, a good general guideline is 
to avoid "research" conferences that ask you to pay for each paper you 
publish there. Legit research events decouple paper selection from 
financial aspects to avoid the impression that you are paying for the 
acceptance of your work. This conference even charges students more if 
they have a paper accepted. In all reputed conferences I know of, it is 
usually the other way around: scholarships are available to support 
students, and student authors have a higher chance of getting such support.


Markus


On 08.05.2015 13:19, Supriya Kapoor wrote:

Dear Colleague,

Just following up on the below.

Please don't forget – you may submit your papers/posters/demo proposals
for the SAI Intelligent Systems Conference 2015 (IntelliSys 2015) on or
before May 15, 2015.
Online Submission System: www.SAIConference.com/IntelliSys2015/Submit


Thanks, we really appreciate your contribution.
Best,
Supriya Kapoor
Conference Manager
SAI Intelligent Systems Conference 2015 (IntelliSys 2015)
www.SAIConference.com/IntelliSys2015


___

We invite you to submit your papers for the upcoming SAI Intelligent
Systems Conference 2015 (IntelliSys 2015) to be held on November 10 &11,
2015 in London, UK, technically sponsored by IEEE.
This conference will focus in areas of intelligent systems and
artificial intelligence and how it applies to the real world. It is an
opportunity for researchers in this field to meet and discuss solutions,
scientific results, and methods in solving intriguing problems in this
field.
The conference programme will include paper presentations, poster
sessions and project demonstrations, along with prominent keynote
speakers and industrial workshops.
Important Dates: Regular Submission
* Paper Submission Due: May 15, 2015 (Extended)
* Acceptance Notification : May 30, 2015 (Extended)
* Author Registration : July 01, 2015
* Camera Ready Submission : August 01, 2015
* Conference Dates : November 10-11, 2015
IntelliSys 2015 Website: www.SAIConference.com/IntelliSys2015

Online Submission System: www.SAIConference.com/IntelliSys2015/Submit

All IntelliSys 2015 presented papers will be published in the conference
proceedings and submitted to IEEE Xplore, Scopus, Inspec, Google Scholar
and more. Past SAI Conference proceedings are already indexed in these
databases. The IEEE proceedings will be published under an ISBN number
(and an IEEE Catalog number). Authors of selected outstanding papers
will be invited to submit extended versions of their papers for
consideration of publication in various international journals and books
including a Springer book.
Looking forward to your contributions.
Regards,
Steering Committee
SAI Intelligent Systems Conference 2015 (IntelliSys 2015)
www.SAIConference.com/IntelliSys2015

facebook.com/SAIConference  |
twitter.com/SAIConference 


___
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] Wikidata for Wiktionary

[Romaine Wiki]

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 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-associated)
> symbols/characters)?
>
> Regardless, I think that doing Task 1 is a very worthwhile idea. The rest
> of the tasks, however, should probably wait until much later.
>
> On Thu, May 7, 2015 at 8:28 AM, Lydia Pintscher <
> lydia.pintsc...@wikimedia.de> wrote:
>
>> 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 right thing. And it's good to give that time. So please do
>> read the latest proposal Denny posted. It even has some mockups to
>> make it easier to understand what it'd look like in practice. If we
>> can get rough consensus that this is the way forward things will fall
>> into place. And we'll not abandon the things I mentioned that are
>> right now more important.
>>
>>
>> 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
>>
>
>
> ___
> 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] Wikidata for Wiktionary

[Romaine Wiki]

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 into the mix.
>
> --
> 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] Wikidata for Wiktionary

[Markus Krötzsch]

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 instances this can be confusing as
well if not well done.

Is this a community issue ? Different project, different communities,
different site ? I really don't like it as it tends to make several
groups who can have difficulties to talk to each other and go on the
other site. I think as Wikidata community is already constituted and
tends to try to grow and advocate for the project, considering its
central situation in the ecosystem and that community tends to learn how
to make interproject social links, it would be beneficial imho to
continue to grow and to learn from here. There is strong connections
between words and senses.

I think in that global scheme, one or several instance is a mostly
technical detail that is not really important and that both solutions
can accommodate to distinct (or not) pages or distinct (or not) communities.


That's what I was thinking as well. As far as I see, whether it's one 
site or two sites would not make much difference for users, other than 
that the domain part of the URL would change and the menu/logo on the 
left would be different. But the accounts would be the same, the 
individual page contents would look the same, and the cross-links 
between dictionary content and data content would also be the same. 
Things would probably work fine either way.


Regards,

Markus



2015-05-08 11:15 GMT+02:00 Bene* mailto:benestar.wikime...@gmail.com>>:

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 introduces new entity types for
lexemes, forms, and senses. The data model is mostly based on
lexical ontologies that we surveyed, like LEMON and others.


I think a separate Wikibase installation would be much better than
adding lexical knowledge on Wikidata. Wikidata is about things in
the first place and Wiktionary is about words etc. 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. It would still be connected to Wikidata in
ways like accepting items from Wikidata as values in statements and
having access to their data. However, we should separate lexical
knowledge and Wikidata also wiki-wise.

Best regards,
Bene


___
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] Wikidata for Wiktionary

[Ricordisamoa]

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.

https://wiki.openstreetmap.org/wiki/Wikidata



Also, we should throw WikiSpecies into the mix.



This reminds me of some old discussions... [1] 
 
[2] 
 
[3] 
 
etc.
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

[Wikidata-l] Last Call for Papers/Posters: IEEE Technically Sponsored SAI Intelligent Systems Conference (IntelliSys 2015)

[Supriya Kapoor]

Dear Colleague,

Just following up on the below.

Please don't forget – you may submit your papers/posters/demo proposals for
the SAI Intelligent Systems Conference 2015 (IntelliSys 2015) on or before
May 15, 2015.
Online Submission System: www.SAIConference.com/IntelliSys2015/Submit

Thanks, we really appreciate your contribution.

Best,
Supriya Kapoor
Conference Manager
SAI Intelligent Systems Conference 2015 (IntelliSys 2015)
www.SAIConference.com/IntelliSys2015

___
We invite you to submit your papers for the upcoming SAI Intelligent
Systems Conference 2015 (IntelliSys 2015) to be held on November 10 &11,
2015 in London, UK, technically sponsored by IEEE.

This conference will focus in areas of intelligent systems and artificial
intelligence and how it applies to the real world. It is an opportunity for
researchers in this field to meet and discuss solutions, scientific
results, and methods in solving intriguing problems in this field.

The conference programme will include paper presentations, poster sessions
and project demonstrations, along with prominent keynote speakers and
industrial workshops.

Important Dates: Regular Submission
* Paper Submission Due: May 15, 2015 (Extended)
* Acceptance Notification : May 30, 2015 (Extended)
* Author Registration : July 01, 2015
* Camera Ready Submission : August 01, 2015
* Conference Dates : November 10-11, 2015

IntelliSys 2015 Website: www.SAIConference.com/IntelliSys2015
Online Submission System: www.SAIConference.com/IntelliSys2015/Submit

All IntelliSys 2015 presented papers will be published in the conference
proceedings and submitted to IEEE Xplore, Scopus, Inspec, Google Scholar
and more. Past SAI Conference proceedings are already indexed in these
databases. The IEEE proceedings will be published under an ISBN number (and
an IEEE Catalog number). Authors of selected outstanding papers will be
invited to submit extended versions of their papers for consideration of
publication in various international journals and books including a
Springer book.

Looking forward to your contributions.

Regards,
Steering Committee
SAI Intelligent Systems Conference 2015 (IntelliSys 2015)
www.SAIConference.com/IntelliSys2015
facebook.com/SAIConference | twitter.com/SAIConference
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Wikidata for Wiktionary

[Daniel Kinzler]

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 assumes meanings. Though, it seems to me reasonably 
> possible.

The idea is to do this by having both lexical entries reference the same Q-item
as one of their meanings.


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

Re: [Wikidata-l] Wikidata for Wiktionary

[Thomas Douillard]

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
done.

Is this a community issue ? Different project, different communities,
different site ? I really don't like it as it tends to make several groups
who can have difficulties to talk to each other and go on the other site. I
think as Wikidata community is already constituted and tends to try to grow
and advocate for the project, considering its central situation in the
ecosystem and that community tends to learn how to make interproject social
links, it would be beneficial imho to continue to grow and to learn from
here. There is strong connections between words and senses.

I think in that global scheme, one or several instance is a mostly
technical detail that is not really important and that both solutions can
accommodate to distinct (or not) pages or distinct (or not) communities.

2015-05-08 11:15 GMT+02:00 Bene* :

> 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 introduces
>> new entity types for lexemes, forms, and senses. The data model is mostly
>> based on lexical ontologies that we surveyed, like LEMON and others.
>>
>
> I think a separate Wikibase installation would be much better than adding
> lexical knowledge on Wikidata. Wikidata is about things in the first place
> and Wiktionary is about words etc. 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. It would still be connected to
> Wikidata in ways like accepting items from Wikidata as values in statements
> and having access to their data. However, we should separate lexical
> knowledge and Wikidata also wiki-wise.
>
> Best regards,
> Bene
>
>
> ___
> 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] Wikidata for Wiktionary

[Magnus Manske]

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 require a different data schema. This is why the
> > proposal introduces new entity types for lexemes, forms, and senses.
> > The data model is mostly based on lexical ontologies that we surveyed,
> > like LEMON and others.
>
> I think a separate Wikibase installation would be much better than
> adding lexical knowledge on Wikidata. Wikidata is about things in the
> first place and Wiktionary is about words etc. 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. It would
> still be connected to Wikidata in ways like accepting items from
> Wikidata as values in statements and having access to their data.
> However, we should separate lexical knowledge and Wikidata also wiki-wise.
>
> +1
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Wikidata for Wiktionary

[Bene*]

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 introduces new entity types for lexemes, forms, and senses. 
The data model is mostly based on lexical ontologies that we surveyed, 
like LEMON and others.


I think a separate Wikibase installation would be much better than 
adding lexical knowledge on Wikidata. Wikidata is about things in the 
first place and Wiktionary is about words etc. 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. It would 
still be connected to Wikidata in ways like accepting items from 
Wikidata as values in statements and having access to their data. 
However, we should separate lexical knowledge and Wikidata also wiki-wise.


Best regards,
Bene

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

Re: [Wikidata-l] Wikidata for Wiktionary

[Markus Krötzsch]

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 coding, but to me
it looks like running a DB server with only one database and only one
table - why not use separation that already comes for free with another
instance? We still can reuse any code we like.


API features must support entity type selection anyway, and I think the 
same holds for most other cases you mention. One would not start a new 
Wikibase from scratch but build on the existing code. Therefore, it 
would be necessary to extend Wikibase with the new features. This will 
not be a fork, but an extension of the existing system. Therefore, it 
will be unavoidable to implement it in a way that would work when using 
all the features on one site. This implies that all of the problems you 
mentioned will have to be solved anyway.


Regards,

Markus




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

Re: [Wikidata-l] Wikidata for Wiktionary

[Lydia Pintscher]

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 the place to go to for structured data
>> around Wikimedia now. And we probably do want easy connecting between
>
> All this is true, but I don't see why this implies running only one
> instance of wikibase. We could run another instance under the same
> Wikidata umbrella, connect them (just as we are connecting other wikis
> with Wikidata), share relevant documentation, etc. - neither of that
> mandates running everything within the same database. 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 ;-)

>> items/properties/lexems etc. As we're talking about different entity
>> types the data is easy enough to keep apart for those who want to.
>
> I'm not sure how easy that would be - I've seen a lot of code that
> assumes certain things work with all entities, now this code needs to be
> reworked to work with only two types of entities, or support many other
> types that behave very differently. And it's very easy to miss something
> and not discover it until we launch it and tools start to break because
> Lexems get into code that assumes something is either Item or Property.
> And I'm not talking about internal PHP code only - there's a lot of
> tools out there that neither WMF nor WMDE maintains. It's one thing to
> make new service (which btw I think is an awesome idea, just wanted to
> say it so that it would be clear than I am not criticizing the whole
> idea, just this aspect of it) and another add subtle changes to an
> existing one.

Yeah there are a lot of those indeed. The assumptions around entities
need to go away anyway as we are tackling Commons support. So we'll
have to bite that bullet one way or another.


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

Re: [Wikidata-l] Wikidata for Wiktionary

[Stas Malyshev]

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 server with only one database and only one
table - why not use separation that already comes for free with another
instance? We still can reuse any code we like.
-- 
Stas Malyshev
smalys...@wikimedia.org

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

Re: [Wikidata-l] Wikidata for Wiktionary

[Markus Krötzsch]

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 - virtually all
added value Wikidata has now is working with the assumption of the
semantics of Wikidata values and properties. Everything that pertains to
lexemes, forms, etc. will have to be built separately, so why do it
within the same site and have all the mechanics act as a split brain? I
would think having parallel instance of Wikibase would serve the same
goal much better, while preserving all the benefits of using the
Wikibase toolkit and basic data model. Ultimately, it's the same as
having separate databases vs. having one huge database (or even one huge
table) with columns marking virtual partitions - the former is much
easier to handle if the sets are completely disjoint, as we'd have
between Wikidata and Wiktionary, as far as I can see. Maybe I am missing
some benefit joint structure would produce?


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. And we probably do want easy connecting between
items/properties/lexems etc. As we're talking about different entity
types the data is easy enough to keep apart for those who want to.


+1

Other technical solutions can be found for keeping content apart when 
needed (e.g., separate dumps by entity types).


Cheers,

Markus


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

Re: [Wikidata-l] Wikidata for Wiktionary

[Stas Malyshev]

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. And we probably do want easy connecting between

All this is true, but I don't see why this implies running only one
instance of wikibase. We could run another instance under the same
Wikidata umbrella, connect them (just as we are connecting other wikis
with Wikidata), share relevant documentation, etc. - neither of that
mandates running everything within the same database. 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.

> items/properties/lexems etc. As we're talking about different entity
> types the data is easy enough to keep apart for those who want to.

I'm not sure how easy that would be - I've seen a lot of code that
assumes certain things work with all entities, now this code needs to be
reworked to work with only two types of entities, or support many other
types that behave very differently. And it's very easy to miss something
and not discover it until we launch it and tools start to break because
Lexems get into code that assumes something is either Item or Property.
And I'm not talking about internal PHP code only - there's a lot of
tools out there that neither WMF nor WMDE maintains. It's one thing to
make new service (which btw I think is an awesome idea, just wanted to
say it so that it would be clear than I am not criticizing the whole
idea, just this aspect of it) and another add subtle changes to an
existing one.
-- 
Stas Malyshev
smalys...@wikimedia.org

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