Re: [Wikidata] Deleting properties / items in test.wikidata.org

[Legoktm]

Hi,

On 09/08/2016 08:54 AM, Loic Dachary wrote:
> Hi,
> 
> But I was not able to figure out how to remove them afterwards, to not 
> clutter test.wikidata.org.

You would just use the normal MediaWiki API delete feature[1]. Pywikibot
abstracts it as Page.delete(...).

[1] https://www.mediawiki.org/wiki/API:Delete

-- Legoktm

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

Re: [Wikidata] Request for Property help (Schema.org mapping taskforce)

[Thad Guidry]

Federico,

Yes they are incompatible concepts.  However, one is typically treated as a
subclass of the other.
Its that https://www.wikidata.org/wiki/Q26869695 (nutritional diet) is a
subclass of https://www.wikidata.org/wiki/Q474191 (biological needs diet)
Which is correctly stated now with that 'subclass of' statement on
https://www.wikidata.org/wiki/Q26869695

Yes, it looks like Wikidata did not have the nutritional concept of a Diet,
but only had the biological needs concept.
Thanks to your creation of the nutritional concept of a Diet, this helps
everyone, Schema.org as well as dieticians, nutritionists, and other
scientists.

TODO: We just need to figure out what to do with 'external subclasses' and
a few other things concerning Schema.org mapping.  And that's part of our
Agenda on this Friday's Google Hangout with Lydia and folks.

Thanks again Federico for the bit of help!

Thad
+ThadGuidry 
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Request for Property help (Schema.org mapping taskforce)

[Federico Leva (Nemo)]

Thad Guidry, 13/09/2016 19:38:

There is no need, therefore, to replicate those same definitions in
Wikidata by creating a new Wikidata item (topic / entity) for each
external vocabulary class or subclass or property.

Instead, the best practice is to simply POINT to those external
definitions, such as those in Schema.org, DBPedia.org, MusicBrainz,
etc., etc.


Agreed. If the external definition is compatible, just link it. A 
specific item needs to be created only where the two definitions are 
incompatible. I would define two items to be equivalent iff swapping 
them doesn't change the truthness of any statement or inference on 
Wikidata 
(https://en.wikipedia.org/wiki/Equivalence_relation#Well-definedness_under_an_equivalence_relation 
). Makes sense?


I don't know if Q474191 and Q26869695 are incompatible definitions; I 
understood you claimed they were. If the two definitions are compatible, 
we can merge the two items and just consider Q474191 equivalent to 
SchemaOrg's definition of "Diet".


Nemo

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

Re: [Wikidata] Request for Property help (Schema.org mapping taskforce)

[Thad Guidry]

Hi Gerard,

Good question.  lolol.  And good point, you did ask about 'how it helps'
and I didn't directly answer that, so here it is.

Schema.org provides a set of guidelines for publishing structured data on
the web in various formats.  You can read more detail on our website.

The answer Part 1 :  Schema.org helps publishers, small and large, even
folks like you and me that might have small websites with important data,
that can be crawled by bots, public scraping scripts, etc. to harvest more
public data for Wikidata to absorb, as well as helping to reconcile data
and even load the Primary Sources tool, Reasonator, or any tool eventually
if we wanted.  Adding references could in theory just be done by a bot that
was smart enough to understand Schema.org markup (there are already many
Python, Ruby, Java libraries that exist for this).

The answer Part 2:  By having Schema.org properties and classes aligned to
existing Wikidata properties and classes.  Both sides benefit to help
understand that structured data even moreand once a machine understands
it better, than those machines can be programmed to gather even more data,
or validate the quality of the existing data.

This mapping effort is not just limited to Schema.org however in the long
term.  Notice that we already have many mappings in Wikidata for external
vocabularies, but its very rudimentary.  We want to help Wikidata have a
more full understanding of data, and that requires a few more properties to
be added to support that effort.

Lydia understands this.  In fact, she was one of the motivators to have us
encourage us to perform the mapping on both sides, inside Wikidata and
inside Schema.org (both will be done, but first it was deemed necessary for
Wikidata).  In addition, she understands the struggle to bring in more
quality data for Wikidata and to help tool authors and publishers, which in
doing so helps with Goal 1b of WMDE's future plans.  Lydia and a few of us
from Schema.org will be having a Google Hangout to discuss a few more
details this Friday.  The entire effort and comments are being tracked
here:  https://github.com/schemaorg/schemaorg/issues/280

Thad
+ThadGuidry 
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Deleting properties / items in test.wikidata.org

[Loic Dachary]

Hi,

It looks like the wikibase API[1] does not provide a way to delete an item. To 
remove an item / propery on http://test.wikidata.org a script would have do web 
scrapping and use the same interface people attending the deletion requests 
do[2]. Unfortunately a regular user does not seem to have permission to do that 
on test.wikidata.org. Would it be possible to upgrade the user permissions to 
allow deletion of items / property on test.wikidata.org ?

Cheers


[1] https://www.mediawiki.org/wiki/Wikibase/API
[2] https://www.wikidata.org/wiki/Wikidata:Requests_for_deletions

On 08/09/2016 17:54, Loic Dachary wrote:
> Hi,
> 
> I'd like to write integration tests for 
> https://www.wikidata.org/wiki/User:FLOSSbot and use test.wikidata.org for 
> that. I figured out how to create properties[1] with pywikibot and search for 
> them[2]. But I was not able to figure out how to remove them afterwards, to 
> not clutter test.wikidata.org. The 
> https://www.mediawiki.org/wiki/Wikibase/API page does not show anything 
> obvious.
> 
> Any idea ?
> 
> Cheers
> 
> [1] 
> import pywikibot
> site = pywikibot.Site("test", "wikidata")
> print(str(site.editEntity({'new': 'property'}, {'datatype':'item',
> "labels":
>  {"en":
>   
> {"language":"en","value":"FLOSS3property"}
>  }
> })))
> 
> [2]
> import pywikibot
> site = pywikibot.Site("test", "wikidata")
> for e in site.search_entities('FLOSS', 'en', type='property'):
> print(str(e))
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


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

[Wikidata] Stable interfaces policy updated

[Daniel Kinzler]

The stable interface policy has now been updated, see



Am 13.09.2016 um 16:58 schrieb Daniel Kinzler:
> Tomorrow I plan to apply the following update to the Stable Interface Policy:
> 
> https://www.wikidata.org/wiki/Wikidata_talk:Stable_Interface_Policy#Proposed_change_to_to_the_.22Extensibility.22_section
> 
> Please comment there if you have any objections.
> 
> Thanks!


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikidata] Let's move forward with support for Wiktionary

[Marco Fossati]

Hi everyone,

FYI, there is an ongoing Wikimedia IEG project (main grantee in CC), 
which seems to be following a related direction:

https://meta.wikimedia.org/wiki/Grants:IEG/A_graphical_and_interactive_etymology_dictionary_based_on_Wiktionary

Its first phase will translate Wiktionary into machine-readable data.
I think it is worth to consider reusing its outcome if possible, since 
it may fit into the Wikidata data model:

https://meta.wikimedia.org/wiki/Grants_talk:IEG/A_graphical_and_interactive_etymology_dictionary_based_on_Wiktionary#Translation_to_the_Wikidata_Data_Model

Cheers,

Marco

On 9/14/16 10:51, Léa Lacroix wrote:

Hello,

Thanks a lot for your questions and feedbacks. Here are some answers, I
hope these will be useful.

/- How wikidata and wiktionary databases will be synchronized?/
New entity types will be created in Wikidata database, with new ids (ex.
L for lexemes). A Wiktionary will have the possibility to include data
from Wikidata in their pages (the complete entity or only some chosen
statements, as the community decides)

/- Will editing wiktionary change?/
Yes, changes will happen, but we're working on making editing Wiktionary
easier. Soon as we can provide some mockups, we will share them with you
for collecting feedbacks.

/- Will bots be allowed/able to edit wiktionary pages after the support
of wikidata in wiktionary?/
Yes, of course, we want the data to be machine-readable and editable,
and with the new structure, bots will be able to edit data stored in
Wikidata and still Wiktionary pages.

/- Can an edit in a wiktionary A break wiktionary B?/
Data about lexemes will be stored on Wikidata, and Wiktionaries will
choose if they want to use this data, which part of it and how. Yes, if
an information stored in Wikidata and displayed on several Wiktionaries
is modified, via Wikidata or a Wiktionary interface, this will affect
all the pages where the information is included.
Because Wikidata is a multilingual project, we already have to deal with
the language issue, and we hope that with the increase of the numbers of
editors coming from Wikidata and Wiktionaries, it will become easier to
find people with at least one common language to communicate between the
different projects.

/- What else can provide wikidata to wiktionary?/
Machine-readable data will allow users to create new tools, useful for
editors, based on the communities' needs. By helping the different
communities (Wiktionaries and Wikidata) working together on the same
project, we expect a growth of the number of people editing the
lexicographical data, providing more review and a better quality of the
data. Finally, when centralized and structured, the data will be easily
reusable by third parties, other websites or applications... and give a
better visibility of the volunteers' work.

On 13 September 2016 at 22:53, Amirouche Boubekki
mailto:amirou...@hypermove.net>> wrote:

Héllo,

I am very happy of this news.

I a wiki newbie interested in using wikidata to do text analysis.
I try to follow the discussion here and on french wiktionary.

I take this as opportunity to try to sum up some concerns that are
raised on french wiktionary [0]:

- How wikidata and wiktionary databases will be synchronized?

- Will editing wiktionary change? The concern is that this will make
editing wiktionary more difficult for people.

- Also, what about bots. Will bots be allowed/able to edit
wiktionary pages after the support of wikidata in wiktionary?

- Another concern is that if edits are done in some wiktionary and
that edit has an impact on another wiktionary. People will have
trouble to reconcil their opinion given they don't speak the same
language. Can an edit in a wiktionary A break wiktionary B?

I understand that wikidata requires new code to support the
organisation of new relations between the data. I understand that
with wikidata it will be easy to create interwiki links and
thesaurus kind of pages but what else can provide wikidata to
wiktionary?

[0] https://fr.wiktionary.org/wiki/Projet:Coop%C3%A9ration/Wikidata


Thanks,

i⋅am⋅amz3


On 2016-09-13 15:17, Lydia Pintscher wrote:

Hey everyone :)

Wiktionary is our third-largest sister project, both in term of
active
editors and readers. It is a unique resource, with the goal to
provide
a dictionary for every language, in every language. Since the
beginning of Wikidata but increasingly over the past months I have
been getting more and more requests for supporting Wiktionary and
lexicographical data in Wikidata. Having this data available openly
and freely licensed would be a major step forward in automated
translation, text analysis, text generation and much more. It will
enable and ease research. And most im

Re: [Wikidata] Let's move forward with support for Wiktionary

[Daniel Kinzler]

Am 14.09.2016 um 10:51 schrieb Léa Lacroix:
> /- What else can provide wikidata to wiktionary?/
> Machine-readable data will allow users to create new tools, useful for 
> editors,
> based on the communities' needs. By helping the different communities
> (Wiktionaries and Wikidata) working together on the same project, we expect a
> growth of the number of people editing the lexicographical data, providing 
> more
> review and a better quality of the data. Finally, when centralized and
> structured, the data will be easily reusable by third parties, other websites 
> or
> applications... and give a better visibility of the volunteers' work.

Here are some examples of things that will become possible with the new 
structure:

* the fact that the English word "sleeper" may refer to a railway tie, and in
which regions this is the case, only has to be entered once, not separately in
each Wiktionary.

* the fact that "Stuhl" is the German translation of (a specific sense of) the
English word "chair" only has to be entered once, not separately in each 
Wiktionary.

* by connecting lexeme-sense to concepts (items), it will become possible to
automatically search for potential synonyms and translations to other languages.

* by providing a statement defining the morphological class of a lexeme, it
becomes possible to automatically generate derived forms for display and search

* different representations (spellings, scripts) of a lexeme can be covered by a
single entry, information about word senses does not have to be repeated.

* the search interface will know about languages and word types, so you can
search specifically for "french verb dormir" (or perhaps more technical "lang:fr
a:Q24905 dormir")

* Similarly, you can search for or filter by epoch, region, linguistic
convention or methodology, etc.


> - Will editing wiktionary change?
> Yes, changes will happen, but we're working on making editing Wiktionary
> easier. Soon as we can provide some mockups, we will share them with you for
> collecting feedbacks.

The question is if you consider editing wikitext with complex nested templates
"easy" or not. With wikidata, editing would be form-based, with input fields and
suggestions. This makes it a lot easier especially for new editors. And even for
experienced editors, I think it's more convenient for editing individual bits of
information.

The form-based approach is less convenient when you want to enter a lot of
information at once. The solution is to identify the use cases for this, and
provide a specialized interface for that use case. This does not have to depend
on Wikibase developers, it can also be done by wiki users using gadgets,
Labs-based tools, or even bots.


> Because Wikidata is a multilingual project, we already have to deal with the
> language issue, and we hope that with the increase of the numbers of editors
> coming from Wikidata and Wiktionaries, it will become easier to find people 
> with
> at least one common language to communicate between the different projects.

Interestingly, we found that on wikidata there is rarely a conflict about
whether a statement about an item should say X or Y, e.g. whether Chelsea
Manning's gender should be given as "transgender female" or just "female" or
even "male". The conflict does not arise because you can and should simply add
all three, and use qualifiers and source references to specify who claimed which
of these, and for which period of time.

Long discussions do take place about the overall organization of information on
wikidata, about which properties to have and how to use them, about whether
substances like "ethanol" should be considered subclasses or instance of classes
like "alcohol".

I agree however that cross-lingual discussions are indeed an issue, and finding
techniques and strategies to help with communication between  the speakers of
different languages will be a challenge. But isn't the Wiktionary community
perfectly equipped for just that challenge? Isn't it just the crowd you would
ask if you had to solve a problem like this? I would (along perhaps with the
folks from translatewiki.net).


-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

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

Re: [Wikidata] Dynamic Lists, Was: Re: List generation input

[Magnus Manske]

On Wed, Sep 14, 2016 at 10:07 AM Luca Martinelli 
wrote:

> Il 05 set 2016 11:43, "Jan Dittrich"  ha
> scritto:
> > - What are current workflows with Listeria? I think I remember that
> people in our interviews (thanks to everyone who participated!) mentioned
> that the generation process currently needs to be triggered manually. Is
> that just because there is no automatic way or does it provide you with
> advantages, too?
>
> Just one thing on this issue. Based on my short experience, the necessity
> of a manual trigger is half true: ListeriaBot updates every 24 hours or so
> every automated list. If you change things and you want to see those
> changes immediately THEN you can ask manually to update now. I don't see
> this much of a disadvantage actually.
>
> Yes, that's how I set it up.

I contemplated having a bot look through recent changes to update manually
changed lists (e.g. query was changed) but it would probably be a few
minutes for some lists until they update, which might be more confusing.

A proper extension would likely regenerate the list as part of the edit, so
this wouldn't be an issue.

I found people opposed to Listeria lists (in article namespace) for two
main reasons:

* The list is wikitext, so it /looks/ like one can edit it, but then it
gets overwritten by a bot. If the wikitext representation of a list were
just a parser function or extension tag, that problem would not appear
(nothing to edit)

* Handcrafted lists. A lot of time went into some of the lists, and while
the raw data can often be regenerated from Wikidata, some manually curated
lists have fields for notes, special formats for coordinates etc. that are
hard to replicate. Allowing custom templates can solve the bespoke
rendering, but especially the "notes" column is essentially not
reproducible with Wikidata, as it is. A tag-based MediaWIki extension could
offer notes per item, maybe, in wikitext.

My 2 Eurocent,
Magnus
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Dynamic Lists, Was: Re: List generation input

[Luca Martinelli]

Il 05 set 2016 11:43, "Jan Dittrich"  ha scritto:
> - What are current workflows with Listeria? I think I remember that
people in our interviews (thanks to everyone who participated!) mentioned
that the generation process currently needs to be triggered manually. Is
that just because there is no automatic way or does it provide you with
advantages, too?

Just one thing on this issue. Based on my short experience, the necessity
of a manual trigger is half true: ListeriaBot updates every 24 hours or so
every automated list. If you change things and you want to see those
changes immediately THEN you can ask manually to update now. I don't see
this much of a disadvantage actually.

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

Re: [Wikidata] [Wikitech-l] Wikidata Query Service demo video

[camelia boban]

Very nice, I need it.
Thank you, CAmelia



--

*Camelia Boban*Freelance developer | Aissa Technologies

T. +39 0670301772 | M. +39 3383385545
camelia.bo...@gmail.com
*Wikipedia  | *Twitter
 | *Google Plus
* | *LinkedIn*




2016-09-06 21:47 GMT+02:00 Info WorldUniversity <
i...@worlduniversityandschool.org>:

> Thanks - helpful tutorial.
>
> Scott
>
> On Tue, Sep 6, 2016 at 12:32 PM, Pine W  wrote:
>
> > Video demo of Wikidata Query Service: https://www.youtube.com/watch?
> > v=1jHoUkj_mKw
> >
> > Pine
> >
> > ___
> > Wikidata mailing list
> > Wikidata@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikidata
> >
> >
>
>
> --
>
> - Scott MacLeod - Founder & President
>
> - http://worlduniversityandschool.org
>
> - 415 480 4577
>
> - PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516
>
> - World University and School - like Wikipedia with best STEM-centric
> OpenCourseWare - incorporated as a nonprofit university and school in
> California, and is a U.S. 501 (c) (3) tax-exempt educational organization.
>
>
> World University and School is sending you this because of your interest in
> free, online, higher education. If you don't want to receive these, please
> reply with 'unsubscribe' in the body of the email, leaving the subject line
> intact. Thank you.
> ___
> Wikitech-l mailing list
> wikitec...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Let's move forward with support for Wiktionary

[Léa Lacroix]

Hello,

Thanks a lot for your questions and feedbacks. Here are some answers, I
hope these will be useful.

*- How wikidata and wiktionary databases will be synchronized?*
New entity types will be created in Wikidata database, with new ids (ex. L
for lexemes). A Wiktionary will have the possibility to include data from
Wikidata in their pages (the complete entity or only some chosen
statements, as the community decides)

*- Will editing wiktionary change?*
Yes, changes will happen, but we're working on making editing Wiktionary
easier. Soon as we can provide some mockups, we will share them with you
for collecting feedbacks.

*- Will bots be allowed/able to edit wiktionary pages after the support of
wikidata in wiktionary?*
Yes, of course, we want the data to be machine-readable and editable, and
with the new structure, bots will be able to edit data stored in Wikidata
and still Wiktionary pages.

*- Can an edit in a wiktionary A break wiktionary B?*
Data about lexemes will be stored on Wikidata, and Wiktionaries will choose
if they want to use this data, which part of it and how. Yes, if an
information stored in Wikidata and displayed on several Wiktionaries is
modified, via Wikidata or a Wiktionary interface, this will affect all the
pages where the information is included.
Because Wikidata is a multilingual project, we already have to deal with
the language issue, and we hope that with the increase of the numbers of
editors coming from Wikidata and Wiktionaries, it will become easier to
find people with at least one common language to communicate between the
different projects.

*- What else can provide wikidata to wiktionary?*
Machine-readable data will allow users to create new tools, useful for
editors, based on the communities' needs. By helping the different
communities (Wiktionaries and Wikidata) working together on the same
project, we expect a growth of the number of people editing the
lexicographical data, providing more review and a better quality of the
data. Finally, when centralized and structured, the data will be easily
reusable by third parties, other websites or applications... and give a
better visibility of the volunteers' work.

On 13 September 2016 at 22:53, Amirouche Boubekki 
wrote:

> Héllo,
>
> I am very happy of this news.
>
> I a wiki newbie interested in using wikidata to do text analysis.
> I try to follow the discussion here and on french wiktionary.
>
> I take this as opportunity to try to sum up some concerns that are raised
> on french wiktionary [0]:
>
> - How wikidata and wiktionary databases will be synchronized?
>
> - Will editing wiktionary change? The concern is that this will make
> editing wiktionary more difficult for people.
>
> - Also, what about bots. Will bots be allowed/able to edit wiktionary
> pages after the support of wikidata in wiktionary?
>
> - Another concern is that if edits are done in some wiktionary and that
> edit has an impact on another wiktionary. People will have trouble to
> reconcil their opinion given they don't speak the same language. Can an
> edit in a wiktionary A break wiktionary B?
>
> I understand that wikidata requires new code to support the organisation
> of new relations between the data. I understand that with wikidata it will
> be easy to create interwiki links and thesaurus kind of pages but what else
> can provide wikidata to wiktionary?
>
> [0] https://fr.wiktionary.org/wiki/Projet:Coop%C3%A9ration/Wikidata
>
> Thanks,
>
> i⋅am⋅amz3
>
>
> On 2016-09-13 15:17, Lydia Pintscher wrote:
>
>> Hey everyone :)
>>
>> Wiktionary is our third-largest sister project, both in term of active
>> editors and readers. It is a unique resource, with the goal to provide
>> a dictionary for every language, in every language. Since the
>> beginning of Wikidata but increasingly over the past months I have
>> been getting more and more requests for supporting Wiktionary and
>> lexicographical data in Wikidata. Having this data available openly
>> and freely licensed would be a major step forward in automated
>> translation, text analysis, text generation and much more. It will
>> enable and ease research. And most importantly it will enable the
>> individual Wiktionary communities to work more closely together and
>> benefit from each other’s work.
>>
>> With this and the increased demand to support Wikimedia Commons with
>> Wikidata, we have looked at the bigger picture and our options. I am
>> seeing a lot of overlap in the work we need to do to support
>> Wiktionary and Commons. I am also seeing increasing pressure to store
>> lexicographical data in existing items (which would be bad for many
>> reasons).
>>
>> Because of this we will start implementing support for Wiktionary in
>> parallel to Commons based on our annual plan and quarterly plans. We
>> contacted several of our partners in order to get funding for this
>> additional work. I am happy that Google agreed to provide funding
>> (restricted to work on Wikidata). With this we can re