[Wikidata-tech] dashes - in JSON keys - suck

[Thad Guidry]

"mainsnak": {
  "snaktype": "value",
  "property": "P31",
  "hash": "d679b35e7a9523b92903b52661a9e4c15d8d76d3",
  "datavalue": {
"value": {
  "entity-type": "item",
  "numeric-id": 112826905,
  "id": "Q112826905"
},
"type": "wikibase-entityid"
  },
  "datatype": "wikibase-item"
},

One of the constant pain points that I have heard and run across is this:

Any chance Wikidata's JSON format might be a little more developer friendly
> for tooling in general?  Like why do they sometimes have "entity-type" and
> "numeric-id" as keys with dashes, when a lot of the world and our parsing
> libraries have sorta standardized around at least only camelCase or
> snake_case in JSON.  I mean, look at what they did with "snaktype" and
> "entity-type" !  Can you find out, Thad ?


So I said to them, sure. 
(granted I know all characters are allowed for object property names in
JSON and someone likely in the team at the time said, "eh, doesn't matter,
it's JSON, it eats anything".)

Thad
https://www.linkedin.com/in/thadguidry/
https://calendly.com/thadguidry/
___
Wikidata-tech mailing list -- wikidata-tech@lists.wikimedia.org
To unsubscribe send an email to wikidata-tech-le...@lists.wikimedia.org

[Wikidata-tech] Re: Cirrus Search on Wikidata

[Thad Guidry]

DONE!  Here's the new ticket I created:
https://phabricator.wikimedia.org/T289428

Thad
https://www.linkedin.com/in/thadguidry/
https://calendly.com/thadguidry/


On Fri, Aug 20, 2021 at 11:28 AM Lydia Pintscher <
lydia.pintsc...@wikimedia.de> wrote:

> On Sun, Aug 15, 2021 at 4:26 AM Thad Guidry  wrote:
> >
> > I thought that "," comma was being added to the Elasticsearch token
> filter as a stopword and excluded from simple search now?
> > Or did I miss something?
> >
> >
> >
> > Or NO and U+002C comma was decided against being added, and we must use
> the Advanced Search on Wikidata or the API ?
> >
> > I noticed that the string "foot locker inc" will not show the entity in
> the dropdown, but only "foot locker, inc." ?
> > (I've since added the full legal name into the alias to improve
> searchability, but still would like to know the stopword decision)
> >
> > Thad
> > https://www.linkedin.com/in/thadguidry/
> > https://calendly.com/thadguidry/
> > ___
> > Wikidata-tech mailing list -- wikidata-tech@lists.wikimedia.org
> > To unsubscribe send an email to wikidata-tech-le...@lists.wikimedia.org
>
> Hi Thad :)
>
> I don't think we've made any changes to this in quite a while. And I
> don't think we ever removed commas from the entity search input.
> Could you file a ticket please if you'd like to see this changed? Thanks!
>
> 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/029/42207.
> ___
> Wikidata-tech mailing list -- wikidata-tech@lists.wikimedia.org
> To unsubscribe send an email to wikidata-tech-le...@lists.wikimedia.org
>
___
Wikidata-tech mailing list -- wikidata-tech@lists.wikimedia.org
To unsubscribe send an email to wikidata-tech-le...@lists.wikimedia.org

[Wikidata-tech] Re: Cirrus Search on Wikidata

[Thad Guidry]

Hi Antonin,

No, that's not correct, that was changed a few years ago.
I've been keeping up (well, trying to!).
Here's the post from Stas from 4 years ago.
https://lists.wikimedia.org/hyperkitty/list/wikid...@lists.wikimedia.org/thread/CPGZSC55XFU5HPSRJNZWDQOKLZDHKJSA/#S7J5EZG5TIBNFXRRWVHGCXC4X6RSZ65Q

The reason I asked about the comma token is that I seemed to recall,
perhaps in last 3 years? that it would not affect the simple search (aka
wbsearchentities API, aka suggestion dropdown box)

Also, I tried to find something about that on Phabricator, but quickly got
into the weeds since I don't know the labels that the team uses.
The closest ones I found were these:
https://phabricator.wikimedia.org/search/query/64FG3L6BYauX/#R
but I have no way in the Phabricator Advanced Search to say, only those
after the date of Stas' post.

Thad
https://www.linkedin.com/in/thadguidry/
https://calendly.com/thadguidry/


On Sun, Aug 15, 2021 at 1:47 AM Antonin Delpeuch (lists) <
li...@antonin.delpeuch.eu> wrote:

> Hi Thad,
>
> This suggestion box does not use ElasticSearch, it uses a simple prefix
> search on labels and aliases, run directly against the SQL database, I
> think. ElasticSearch is only used when you go to Special:Search.
>
> Best,
>
> Antonin
> On 15/08/2021 04:25, Thad Guidry wrote:
>
> I thought that "," comma was being added to the Elasticsearch token filter
> as a stopword and excluded from simple search now?
> Or did I miss something?
>
> [image: image.png]
>
> Or NO and U+002C comma was decided against being added, and we must use
> the Advanced Search on Wikidata or the API ?
>
> I noticed that the string "foot locker inc" will not show the entity in
> the dropdown, but only "foot locker, inc." ?
> (I've since added the full legal name into the alias to improve
> searchability, but still would like to know the stopword decision)
>
> Thad
> https://www.linkedin.com/in/thadguidry/
> https://calendly.com/thadguidry/
>
> ___
> Wikidata-tech mailing list -- wikidata-tech@lists.wikimedia.org
> To unsubscribe send an email to wikidata-tech-le...@lists.wikimedia.org
>
> ___
> Wikidata-tech mailing list -- wikidata-tech@lists.wikimedia.org
> To unsubscribe send an email to wikidata-tech-le...@lists.wikimedia.org
>
___
Wikidata-tech mailing list -- wikidata-tech@lists.wikimedia.org
To unsubscribe send an email to wikidata-tech-le...@lists.wikimedia.org

[Wikidata-tech] Cirrus Search on Wikidata

[Thad Guidry]

I thought that "," comma was being added to the Elasticsearch token filter
as a stopword and excluded from simple search now?
Or did I miss something?

[image: image.png]

Or NO and U+002C comma was decided against being added, and we must use the
Advanced Search on Wikidata or the API ?

I noticed that the string "foot locker inc" will not show the entity in the
dropdown, but only "foot locker, inc." ?
(I've since added the full legal name into the alias to improve
searchability, but still would like to know the stopword decision)

Thad
https://www.linkedin.com/in/thadguidry/
https://calendly.com/thadguidry/
___
Wikidata-tech mailing list -- wikidata-tech@lists.wikimedia.org
To unsubscribe send an email to wikidata-tech-le...@lists.wikimedia.org

Re: [Wikidata-tech] Sunsetting Wikibase 1.35 Docker Images

[Thad Guidry]

Hi Mohammed,


> However, we haven’t quite finalized the details of the release strategy.
> The main goal is to provide tested services in both docker, and non-docker
> form that are compatible with one another.
>
> Are you using the existing images in FROM statements to build your own
> custom images? If so we’d be interested in hearing about the alterations
> you’re making and your use case.
>
>
In one custom image, Yes, where I layer in an additional custom extension
and sets of modified files because I need to change the experience of
view/edit for a client.

Thad
https://www.linkedin.com/in/thadguidry/
https://calendly.com/thadguidry/
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Sunsetting Wikibase 1.35 Docker Images

[Thad Guidry]

Hi Mohammed & Wikibase Tech team,

Going forward it sounds like the team has decided to adopt the practice
(not debating best or otherwise, but here only a practice that has been
choosen) of "stable tags" also known as "tagging a servicing release".
https://stevelasker.blog/2018/03/01/docker-tagging-best-practices-for-tagging-and-versioning-docker-images/

I.E.  1.36 is a hypothetical stable tag (a service release).  Some small
bugs need to be fixed, and are non-breaking changes.  The team pushes an
updated 1.36 service release (the tag remains the same, but the image has
been updated and incorporates the small fixes).  A company or service that
uses 1.36 tag can expect not to have to update their FROM line in a
Dockerfile (hopefully) since the expectation is that 1.36 is considered
"stable".

Is that the practice or strategy that the teams have decided to do going
forward?

Thad
https://www.linkedin.com/in/thadguidry/
https://calendly.com/thadguidry/


On Tue, Apr 13, 2021 at 9:58 AM Mohammed Sadat Abdulai <
mohammed.sa...@wikimedia.de> wrote:

> Hello,
>
>
> This is to announce that the existing Wikibase Docker images will be
> sunset and that the most recently released Docker 1.35 images are the last
> versions that we will publish from the wikibase-docker github repository
> . If for some reason you need
> them, these previous Docker images will remain available for a period of
> approximately 6 months, officially sunsetting on September 30, 2021.
>
> Please note that tags for these docker images have always been, and
> remain, mutable. This means if you want to be sure that you’re getting the
> same image you should specify the exact image hash.
>
> This is a result of the ongoing “Release Strategy and Infrastructure”
> initiative which will culminate in a Spring release with new 1.35 Docker
> images which should be used going forward. We will make another
> announcement shortly with the exact date of this new release and all
> relevant information.
>
> If you have any questions please do not hesitate to let us know.
>
> Cheers,
>
> --
> Mohammed Sadat
> *Community Communications Manager for Wikidata/Wikibase*
>
> Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
> Phone: +49 (0)30 219 158 26-0
> https://wikimedia.de
>
> Keep up to date! Current news and exciting stories about Wikimedia,
> Wikipedia and Free Knowledge in our newsletter (in German): Subscribe now
> .
>
> Imagine a world in which every single human being can freely share in the
> sum of all knowledge. Help us to achieve our vision!
> https://spenden.wikimedia.de
>
> Wikimedia Deutschland – Gesellschaft zur Förderung Freien Wissens e. V.
> Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
> der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
> Körperschaften I Berlin, Steuernummer 27/029/42207.
> ___
> Wikidata-tech mailing list
> Wikidata-tech@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Merge Wizard silent for Lexeme merging

[Thad Guidry]

Sure  Léa !

GET Response:

{"JSON":{"entities":{"L184508":{"pageid":68161624,"ns":146,"title":"Lexeme:L184508","lastrevid":1019399562,"modified":"2019-09-24T20:01:21Z","type":"lexeme","id":"L184508","lemmas":{"en":{"language":"en","value":"bow"}},"lexicalCategory":"Q1084","language":"Q1860","claims":{},"forms":[{"id":"L184508-F1","representations":{"en":{"language":"en","value":"bow"}},"grammaticalFeatures":["Q110786"],"claims":[]},{"id":"L184508-F2","representations":{"en":{"language":"en","value":"bows"}},"grammaticalFeatures":["Q146786"],"claims":[]}],"senses":[{"id":"L184508-S1","glosses":{"en":{"language":"en","value":"forward
part of the hull of a
ship"}},"claims":{"P5137":[{"mainsnak":{"snaktype":"value","property":"P5137","hash":"9a7cdeaf3f9b9a8ebeadb262d9fe90c94fab6f15","datavalue":{"value":{"entity-type":"item","numeric-id":301897,"id":"Q301897"},"type":"wikibase-entityid"}},"type":"statement","id":"L184508-S1$2697ab0f-4a9a-24bf-b7fe-1df5b1eabead","rank":"normal"}]}},{"id":"L184508-S2","glosses":{"en":{"language":"en","value":"act
of bending at the hip to show respect or
thanks"}},"claims":[]}]},"L14699":{"pageid":56171930,"ns":146,"title":"Lexeme:L14699","lastrevid":1118806304,"modified":"2020-02-20T00:00:17Z","type":"lexeme","id":"L14699","lemmas":{"en":{"language":"en","value":"bow"}},"lexicalCategory":"Q24905","language":"Q1860","claims":{},"forms":[{"id":"L14699-F1","representations":{"en":{"language":"en","value":"bow"}},"grammaticalFeatures":["Q3910936"],"claims":[]},{"id":"L14699-F2","representations":{"en":{"language":"en","value":"bows"}},"grammaticalFeatures":["Q3910936","Q51929447"],"claims":[]},{"id":"L14699-F3","representations":{"en":{"language":"en","value":"bowed"}},"grammaticalFeatures":["Q1230649","Q1392475"],"claims":[]},{"id":"L14699-F4","representations":{"en":{"language":"en","value":"bowing"}},"grammaticalFeatures":["Q10345583"],"claims":[]}],"senses":[{"id":"L14699-S1","glosses":{"en":{"language":"en","value":"forward
part of the hull of a
ship"}},"claims":{"P5137":[{"mainsnak":{"snaktype":"value","property":"P5137","hash":"9a7cdeaf3f9b9a8ebeadb262d9fe90c94fab6f15","datavalue":{"value":{"entity-type":"item","numeric-id":301897,"id":"Q301897"},"type":"wikibase-entityid"}},"type":"statement","id":"L14699-S1$49FE7361-CF41-45E4-875B-1763CD0C4256","rank":"normal"}]}},{"id":"L14699-S2","glosses":{"en":{"language":"en","value":"ranged
weapon system consisting of an elastic launching device and long-shafted
projectiles"}},"claims":{"P5137":[{"mainsnak":{"snaktype":"value","property":"P5137","hash":"a1b79b0ad43924054fc0deac67d874ebb0438b5d","datavalue":{"value":{"entity-type":"item","numeric-id":46311,"id":"Q46311"},"type":"wikibase-entityid"}},"type":"statement","id":"L14699-S2$A4029C71-574A-461A-B6A2-0C21906FA2BF","rank":"normal"}]}}]}},"success":1},"Response
Payload":{"EDITOR_CONFIG":{"text":"{\"entities\":{\"L184508\":{\"pageid\":68161624,\"ns\":146,\"title\":\"Lexeme:L184508\",\"lastrevid\":1019399562,\"modified\":\"2019-09-24T20:01:21Z\",\"type\":\"lexeme\",\"id\":\"L184508\",\"lemmas\":{\"en\":{\"language\":\"en\",\"value\":\"bow\"}},\"lexicalCategory\":\"Q1084\",\"language\":\"Q1860\",\"claims\":{},\"forms\":[{\"id\":\"L184508-F1\",\"representations\":{\"en\":{\"language\":\"en\",\"value\":\"bow\"}},\"grammaticalFeatures\":[\"Q110786\"],\"claims\":[]},{\"id\":\"L184508-F2\",\"representations\":{\"en\":{\"language\":\"en\",\"value\":\"bows\"}},\"grammaticalFeatures\":[\"Q146786\"],\"claims\":[]}],\"senses\":[{\"id\":\"L184508-S1\",\"glosses\":{\"en\":{\"language\":\"en\",\"value\":\"forward
part of the hull of a
ship\"}},\"claims\":{\"P5137\":[{\"mainsnak\":{\"snaktype\":\"value\",\"property\":\"P5137\",\"hash\":\"9a7cdeaf3f9b9a8ebeadb262d9fe90c94fab6f15\",\"datavalue\":{\"value\":{\"entity-type\":\"item\",\"numeric-id\":301897,\"id\":\"Q301897\"},\"type\":\"wikibase-entityid\"}},\"type\":\"statement\",\"id\":\"L184508-S1$2697ab0f-4a9a-24bf-b7fe-1df5b1eabead\",\"rank\":\"normal\"}]}},{\"id\":\"L184508-S2\",\"glosses\":{\"en\":{\"language\":\"en\",\"value\":\"act
of bending at the hip to show respect or

[Wikidata-tech] Merge Wizard silent for Lexeme merging

[Thad Guidry]

The only clue that I get that there is a problem is that the
mediawiki-api-error field says "failed-modify" ?

Here's my Request URL shown in the GET just before the POST :

https://www.wikidata.org/w/api.php?action=wbgetentities=json=L14699%7CL184508

and here's the screenshot of the Response:

[image: image.png]

Thad
https://www.linkedin.com/in/thadguidry/
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

[Wikidata-tech] Freebase Sets

[Thad Guidry]

I recently asked 
a Freebase colleague @narphorium to graciously spend some time to write up
what was once a very cool Freebase app that many of us used in Freebase to
see overlap of Freebase Properties (like WD statements) between 1-5
Freebase Topics (like WD Items) that then ran a query to find other Topics
that matched that overlapping set.

I thought that sharing this knowledge would allow others to get inspired
and learn and possibly build a similar shape tool for Wikidata; if not
already existing.

Freebase Sets
https://github.com/narphorium/freebase-sets

Best of luck WD engineers!
Thad
https://www.linkedin.com/in/thadguidry/
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Quick Search using ApostropheFilter ?

[Thad Guidry]

DONE !

https://phabricator.wikimedia.org/T237645

Thad
https://www.linkedin.com/in/thadguidry/


On Thu, Nov 7, 2019 at 3:14 AM David Causse  wrote:

> Hi,
>
> On Tue, Nov 5, 2019 at 9:15 PM Thad Guidry  wrote:
>
>> Hi Team,
>>
>> I often see missed results in the Quick Search input box when phrases
>> sometimes are indexed with an apostrophe, but its missed because we
>> sometimes just type simple titles or simple names like so:
>>
>> "no mans sky"
>> (no results)
>>
>> but when I click "containing... no mans sky"
>> then the results page displays
>> <https://www.wikidata.org/w/index.php?search=no%20mans%20sky=Special%3ASearch=1=1=1=1=1=1=1=1=1=1>
>> and shows the video game correctly.
>>
>> It seems this might be because of an indexing choice for the Quick Search
>> input box?
>> (I know that Lucene-Solr can handle this for English input preference
>> https://github.com/apache/lucene-solr/blob/master/lucene/analysis/common/src/java/org/apache/lucene/analysis/tr/ApostropheFilterFactory.java
>> )
>>
>
> The reason you find "no man's sky" when searching "no mans sky" using
> Special:Search is simply because "mans" is matched somewhere in the
> document (could be because of the stemmer or for example the Quora topic id
> No-*Mans*-Sky-5).
>
> The ApostropheFilter that you mention unfortunately has been designed for
> the turkish language and would remove everything after the apostrophe which
> is not what we want in general.
>
> Completion (quick search input box) and Special:Search use very different
> techniques, what we do for apostrophe in completion is transforming it into
> a space.
> Should we do something different for apostrophes in completion search? I
> have no clue and this would require some evaluation, if you believe this is
> important as it causes much annoyance feel free to file a task in
> phabricator so that we can discuss about it.
>
> David.
> ___
> Wikidata-tech mailing list
> Wikidata-tech@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

[Wikidata-tech] Quick Search using ApostropheFilter ?

[Thad Guidry]

Hi Team,

I often see missed results in the Quick Search input box when phrases
sometimes are indexed with an apostrophe, but its missed because we
sometimes just type simple titles or simple names like so:

"no mans sky"
(no results)

but when I click "containing... no mans sky"
then the results page displays

and shows the video game correctly.

It seems this might be because of an indexing choice for the Quick Search
input box?
(I know that Lucene-Solr can handle this for English input preference
https://github.com/apache/lucene-solr/blob/master/lucene/analysis/common/src/java/org/apache/lucene/analysis/tr/ApostropheFilterFactory.java
)

Thad
https://www.linkedin.com/in/thadguidry/
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Installing Wikibase Cirrus Search

[Thad Guidry]

Hi Michael,

It's the official signup page here?
https://lists.wikimedia.org/mailman/listinfo/Wikimedia-search

If not, then perhaps there needs to be a bit of cleanup on the Mailing
lists page:  https://meta.wikimedia.org/wiki/Mailing_lists/Overview
where I saw a few mentions of "discovery".

Thad
https://www.linkedin.com/in/thadguidry/


On Fri, Oct 4, 2019 at 8:29 AM Michael Holloway 
wrote:

> Hello Kevin,
>
> Yes, WikibaseCirrusSearch can be tricky to install.  I'd recommend asking
> your question again on the Search and Discovery mailing list (
> discov...@lists.wikimedia.org), where it's more likely to reach a member
> of the Wikimedia Search Platform Team, who are most likely to be able to
> help.
>
> Good luck!
> Michael
>
> On Mon, Sep 30, 2019 at 11:27 AM Kévin Bois <
> kevin.b...@biblissima-condorcet.fr> wrote:
>
>> Hello,
>>
>> I'm having a hard time setting up Cirrus Search on my Mediawiki /
>> Wikibase instance, I'm quite confused so I thought I could ask for some
>> help. :)
>>
>> First, I followed the instructions to install both CirrusSearch and
>> WikibaseCirrusSearch (WBCS) extensions, but I don't really know what my
>> LocalSettings.php config file should look like.
>> On one hand, CirrusSearch asks for this option`$wgSearchType =
>> 'CirrusSearch';`, on the other hand WBCS asks for `$wgWBCSUseCirrus =
>> true;`. When I put them both, I get a php error : 
>> `mediawiki/extensions/CirrusSearch/includes/Profile/SearchProfileService.php:
>> A profile repository type rescore named wikibase_base is already registered.
>> `
>> 1/ So, do I need only one of them or is something else missing in my
>> config file ? I might have missed a step in the installation ?
>> 2/ The weird thing is, if I remove one of the two option, the search is
>> somewhat working and is different than before using CirrusSearch, but
>> autocompletion seems off, as it autocomplete only strings like "Item:QXXX"
>> where XXX is the QID. I would have expected an autocomplete on item labels,
>> not on QIDs like on Wikidata
>> 3/ I'm not sure either if I have to fire some CirrusSearch maintenance
>> scripts when I'm toying around with WBCS options in LocalSettings.php,
>> because it appears that WBCS extension doesn't have any.
>>
>> I apology in advance because I'm pretty sure this is a confusing post,
>> but there are quite a lot of questions in my head. :)
>>
>> Kevin
>> ___
>> Wikidata-tech mailing list
>> Wikidata-tech@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>>
>
>
> --
> Michael Holloway
> Software Engineer, Product Infrastructure
> ___
> Wikidata-tech mailing list
> Wikidata-tech@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

[Wikidata-tech] ShEx help on recursive definition & cardinality

[Thad Guidry]

*ShEx experts, *

I've got https://www.wikidata.org/wiki/EntitySchema:E126 mostly working now
thanks to the examples and note on
https://www.wikidata.org/wiki/Wikidata:WikiProject_ShEx/How_to_get_started%3F

specifically about

> N.B. E97  only makes sure
> that an item has at least one class. The constraint that at least one class
> is an organization (Q43229)  or a 
> subclass
> of (P279)  organization
> (Q43229)  requires a more complex
> recursive definition and is found here
> 
>  and
> in E98 .


Would love some help about the cardinality errors I'm getting when using
E126  with example query
or any of the other example queries in comments in E126
 :

 SELECT ?winner WHERE {
  ?winner wdt:P166 ?prize.
  ?prize (wdt:P361|wdt:P31|wdt:P279) wd:Q7191.
 }


Errors from ShEx2 Online Validator :

✗wd:Q106471@!START

validating http://www.wikidata.org/entity/Q106471 as
//www.wikidata.org/wiki/Special:EntitySchemaText/nobel_winner:
validating http://www.wikidata.org/entity/Q44585: exceeds cardinality

✗wd:Q110947@!START

validating http://www.wikidata.org/entity/Q110947 as
//www.wikidata.org/wiki/Special:EntitySchemaText/nobel_winner:
validating http://www.wikidata.org/entity/Q44585: exceeds cardinality


Thad
https://www.linkedin.com/in/thadguidry/
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] wbEntity config value to be dropped on July 24th

[Thad Guidry]

Thanks Amir... I'm perfectly fine.   I am just wondering and worrying about
"others" that might not get the hint on what/where the error is coming from
and how to resolve.

Thad
https://www.linkedin.com/in/thadguidry/


On Mon, Jul 22, 2019 at 12:10 PM Amir Sarabadani <
amir.sarabad...@wikimedia.de> wrote:

> Unfortunately not, this is due to technical limitations plus the fact that
> it has been giving depreciation warning and link to the hook for two years
> now (you can try it by running me.config.get('wbEntity') in your console).
> It's time to pull the plug.
>
> Javascript code is explicitly mentioned as an unstable interface (while
> javascript hooks are considered stable) in the public interface policy.
>
> Best
> On Mon, Jul 22, 2019, 18:57 Thad Guidry  wrote:
>
>> Will the error mention to users they need to use the hook and point them
>> to a wiki page for more information?
>>
>> Thad
>> https://www.linkedin.com/in/thadguidry/
>>
>>
>> On Mon, Jul 22, 2019 at 3:52 AM Léa Lacroix 
>> wrote:
>>
>>> Hello all,
>>>
>>> This message is important for people who still use the config value 
>>> mw.config.get(
>>> 'wbEntity') in their tools or scripts. This value, deprecated for two
>>> years, will be completely dropped on July 24th.
>>>
>>> The config value mw.config.get( 'wbEntity') has been deprecated in
>>> order to improve the page load time, especially on large Items. Currently,
>>> a significant proportion of the HTML on every entity page is generated by
>>> this value. Dropping wbEntity completely will make the first paint (time
>>> needed to load the page) faster, and will better utilize the server and
>>> client cache.
>>>
>>> If your code is still using
>>> <https://phabricator.wikimedia.org/T85499#5330372> mw.config.get(
>>> 'wbEntity'), you can replace it by the hook
>>> wikibase.entityPage.entityLoaded (see an example here
>>> <https://github.com/wikimedia/mediawiki-extensions-Wikibase/blob/47952b3b22a4550f3b2677b96c820e559123864c/repo/resources/wikibase.entityPage.entityLoaded.js#L13>).
>>>
>>>
>>> On Wednesday, July 24th, we will drop mw.config.get( 'wbEntity') from
>>> Wikidata’s codebase and calling the value will result in an error.
>>>
>>> If you have any questions or need help, feel free to leave a comment
>>> under the related task <https://phabricator.wikimedia.org/T85499>.
>>>
>>> Thanks for your understanding,
>>> Cheers,
>>> --
>>> Léa Lacroix
>>> Project Manager Community Communication 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/029/42207.
>>> ___
>>> Wikidata-tech mailing list
>>> Wikidata-tech@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>>>
>> ___
>> Wikidata-tech mailing list
>> Wikidata-tech@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>>
> ___
> Wikidata-tech mailing list
> Wikidata-tech@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] JSON-LD now on beta

[Thad Guidry]

H U G E  ! ! !

Thad
https://www.linkedin.com/in/thadguidry/


On Mon, Jul 8, 2019 at 8:53 AM Léa Lacroix  wrote:

> Hello all,
>
> Some time after the deployment on beta, JSON-LD is now live on
> Wikidata.org. You can see an example here
> .
> If you have any question or concern, feel free to raise them in the
> related ticket .
>
> Cheers, Léa
>
> On Tue, 16 Oct 2018 at 15:08, Léa Lacroix 
> wrote:
>
>> Hello all,
>>
>> We’re planning to add JSON-LD as a serialization format for Wikidata.
>> This will allow for example an easier access to RDF data from Javascript.
>>
>> This is now deployed on https://wikidata.beta.wmflabs.org. Example:
>> https://wikidata.beta.wmflabs.org/wiki/Special:EntityData/Q64.jsonld
>>
>> As with the other formats we already support (like turtle or rdf/xml),
>> content negotiation is used if the format is not indicated by a suffix like
>> .jsonld. The MIME type that can be used in the Accept header to request
>> JSON-LD output is application/ld+json.
>>
>> If you’re interested in this feature, please test it, and let us know if
>> you find any issues. The related ticket is this one
>> . If everything goes as
>> planned, we will enable it to wikidata.org on October 31st.
>>
>> Cheers,
>> --
>> Léa Lacroix
>> Project Manager Community Communication 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/029/42207.
>>
>
>
> --
> Léa Lacroix
> Project Manager Community Communication 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/029/42207.
> ___
> Wikidata-tech mailing list
> Wikidata-tech@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Q11629 crashes Firefox sometimes

[Thad Guidry]

And one more...

https://www.wikidata.org/wiki/Q11633

-Thad

On Mon, Jul 9, 2018 at 8:53 PM Thad Guidry  wrote:

> So this seems like it stems from the many wrongful assertions of "creator"
> via primary sources tooling ?
>
> Who can mass fix this ?
>
> -Thad
>
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

[Wikidata-tech] Q11629 crashes Firefox sometimes

[Thad Guidry]

So this seems like it stems from the many wrongful assertions of "creator"
via primary sources tooling ?

Who can mass fix this ?

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

Re: [Wikidata-tech] Query data type using WDQS

[Thad Guidry]

Thanks Lucas !

With that I was able to find and tweak another example ( since you showed
me it's a wikibase parameter itself ! thanks so much !)

This gives me my list of all the Properties that are of " propertyType
wikibase: Url "

https://query.wikidata.org/#%23Properties%20of%20type%20URL%0A%23%20Make%20a%20list%20of%20properties%20of%20the%20type%20Url%0ASELECT%20%3Fproperty%20%3FpropertyLabel%20%3FpropertyDescription%20WHERE%20%7B%0A%20%20%3Fproperty%20wikibase%3ApropertyType%20wikibase%3AUrl%20.%0A%09SERVICE%20wikibase%3Alabel%20%7B%0A%09%09bd%3AserviceParam%20wikibase%3Alanguage%20%22en%22%20.%0A%09%7D%20%20%20%20%20%20%20%20%20%20%0A%7D%20ORDER%20BY%20%3FpropertyLabel


On Thu, Jun 7, 2018 at 4:28 PM Lucas Werkmeister 
wrote:

> The property type is available under the wikibase:propertyType predicate:
> https://query.wikidata.org/#%23Subproperties%20of%20URL%20%28P2699%29%0ASELECT%20DISTINCT%20%3FsubProperties%20%3FsubPropertiesLabel%20%3FpropertyType%20WHERE%20%7B%0A%20%20%3FsubProperties%20wdt%3AP1647%2a%20wd%3AP2699%3B%0A%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20wikibase%3ApropertyType%20%3FpropertyType.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D
> Cheers, Lucas
>
>
> On 07.06.2018 17:01, Thad Guidry wrote:
>
> 1. Ok, after 1 hour, I have given up trying to find some good
> documentation on Data Type querying with Sparql and asking for assistance
> from experts.
>
> Many properties have a Data Type locked in with URL as shown on this Wiki
> maintenance page:
> https://www.wikidata.org/wiki/Category:Properties_with_url-datatype
>
> However, I don't quite understand how to get at the Data Type itself in
> Sparql ?
>
> https://query.wikidata.org/#%23Subproperties%20of%20URL%20%28P2699%29%0ASELECT%20DISTINCT%20%3FsubProperties%20%3FsubPropertiesLabel%20WHERE%20%7B%0A%20%20%3FsubProperties%20wdt%3AP1647%2a%20wd%3AP2699.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D
>
> 2. Should equivalent property
> <https://www.wikidata.org/wiki/Property:P1628> and equivalent class
> <https://www.wikidata.org/wiki/Property:P1709> both be a subproperty of
> URL (I have applied this assumption to both, but wondering if I might have
> missed some other way of expressing that or if not needed since the Data
> Type is set, but having difficulty querying that in 1.)
>
> I'm looking to query subjects having a statement where the property is a
> Data Type = URL and filtered by contains("world")  (don't ask why, hahaha)
>
> Thanks in advance for direction and help,
> -Thad
>
>
> ___
> Wikidata-tech mailing 
> listWikidata-tech@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
>
> ___
> Wikidata-tech mailing list
> Wikidata-tech@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

[Wikidata-tech] Query data type using WDQS

[Thad Guidry]

1. Ok, after 1 hour, I have given up trying to find some good documentation
on Data Type querying with Sparql and asking for assistance from experts.

Many properties have a Data Type locked in with URL as shown on this Wiki
maintenance page:
https://www.wikidata.org/wiki/Category:Properties_with_url-datatype

However, I don't quite understand how to get at the Data Type itself in
Sparql ?
https://query.wikidata.org/#%23Subproperties%20of%20URL%20%28P2699%29%0ASELECT%20DISTINCT%20%3FsubProperties%20%3FsubPropertiesLabel%20WHERE%20%7B%0A%20%20%3FsubProperties%20wdt%3AP1647%2a%20wd%3AP2699.%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%7D

2. Should equivalent property 
and equivalent class  both be
a subproperty of URL (I have applied this assumption to both, but wondering
if I might have missed some other way of expressing that or if not needed
since the Data Type is set, but having difficulty querying that in 1.)

I'm looking to query subjects having a statement where the property is a
Data Type = URL and filtered by contains("world")  (don't ask why, hahaha)

Thanks in advance for direction and help,
-Thad
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Tabular data and its limits

[Thad Guidry]

Hi John,

Can you give an example of 1 of the datasets your trying to remap with ?
That would help clarify.
Are you a Statistician or Programmer or Both ?

Quick Notes:
JSON-stat format and semantics seems to be easily transferable to JSON-LD
(upon a quick inspection from my eyes)
JSON-LD is already used on Data.gov and upcoming on Data.gov.uk and others.

Maybe working with Gregg Kellogg on a transform tool and processor between
JSON-stat and JSON-LD ?
https://json-ld.org/playground/
https://github.com/digitalbazaar/jsonld.js

Perhaps also http://w3c.github.io/csvw/primer/ is interesting or useful for
you ?

Finally, OpenRefine 2.8 (download and check it out )
has new Wikidata / Metadata features, but we still have more work to do in
other areas, here's just one
https://github.com/OpenRefine/OpenRefine/issues/1269

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

Re: [Wikidata-tech] Diacritic insensitive search not working?

[Thad Guidry]

AH !

The issue was that I had a special search mode that I had remembered for
future searches.  MAIN was not checked :(
I've resolved that now :)

I hope that the main search in the top right corner does not use special
search or my search preferencesuntil I click on the "containing..." at
the bottom of the dropdown list ?  or does that search input box always use
my preferences (currently MAIN and PROPERTY) ?
[image: Capture.PNG]

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

[Wikidata-tech] Diacritic insensitive search not working?

[Thad Guidry]

I am not able to successfully get results on topics that have diacritics in
their label while logged in and searching Wikidata.

Searching for "Marc Marquez" this morning did not show any results.  I
began to create an entry for this motorcycle road racer and later
discovered that he already had an entry.  I noticed that the "Also known
as" for English only had a diacritic label "Marc Márquez i Alentà  ".  I
then added another "Also known as" Marc Marquez and this resolved the
problem of finding the correct original topic.  I merged my erroneous new
topic into the original https://www.wikidata.org/wiki/Q40615

Is there an effort already in progress to fix diacritic insensitive search
or investigate why it might not be working for logged in English users ?

I only found this older Phabricator issue for Autocomplete during data
entry, and not main search: https://phabricator.wikimedia.org/T49114

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

Re: [Wikidata-tech] Linking RDF resources for external IDs

[Thad Guidry]

Ok, thanks Daniel.

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

Re: [Wikidata-tech] Last call for objections against DataModel changes.

[Thad Guidry]

Daniel,

Perusing through phabricator, looks like there was too much effort in
discussion of this, than there was with actual experiments!.  That's a
shame.

My suggestion is EXPERIMENT MORE..."just do it"... early scientists did not
argue to much or even ask for last calls in their laboratories, they got
out there in their field and performed experiments to prove things were
right or wrong, or slower or faster, etc
And if it did not work well, they changed a variable and tried again.

Do not lose the scientific process.  PLAY first.  Then discuss.

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

Re: [Wikidata-tech] Wikidata Query Backend Update (take two!)

[Thad Guidry]

Nik,

Will you be incorporating MapGraph, as well, with GPU hardware as part of
the scope of the Wikidata Query Service ?  Or is that out of scope until
you know what the load limits will be and just use BlazeGraph as is with
CPU-bound memory ?

What are the scalability plans for also using MapGraph with GPU's and their
memory in the future, in case the need for faster graph traversal arises ?

Thad
+ThadGuidry https://www.google.com/+ThadGuidry
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

Re: [Wikidata-tech] Reconciling with Wikidata (was Freebase)

[Thad Guidry]

Thad
+ThadGuidry https://www.google.com/+ThadGuidry

On Fri, Jan 2, 2015 at 5:46 PM, Jeroen De Dauw jeroended...@gmail.com
wrote:

 Hey Thad,

 You can get the full data of a set of entities as follows:
 https://www.wikidata.org/w/api.php?action=wbgetentitiesids=Q64|Q65|Q183format=jsonfm

 I'm not aware of a way to get full entities as part of a search (which
 does not mean there is none, I'm not that familiar with the MediaWiki API).
 Given the size of entities, I'm not sure this is what you'd want though.
 Can you provide more details on how you want to specify for which entities
 you want info, and what info you want to get from them?


I want the Statements (Claims), so that I can tell which Paris is located
in France...and which Paris is located in Texas.


 Cheers

 --
 Jeroen De Dauw - http://www.bn2vs.com
 Software craftsmanship advocate
 Evil software architect at Wikimedia Germany
 ~=[,,_,,]:3

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


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