One possibility with Entity Explosion is to help developers to see the json code available for a source.... Today I cheat using Third party Property:P3303 "third-party formatter URL"

Is there a better solution?

E:g

• Property:P4963 "Dictionary about Swedish women"

  • JoyZanden article
  • has json JoyZanden.json

• Property:P4819 "Swedish Portrait Archive"

  • picture
  • has json

• Eionet bathingWaterIdentifier (P9616)

  • WD: Q106707012
    • has 2 different API api/testlocationprofile/SE0441278000000136 / detail
    • has a vocabulary concept view

• Property:P8024 "Nobel Laureate API-ID"

  • WD;Q7186
  • has Nobel Laureate API-ID 6 --> JSON version 2.1 with same as WD / JSON version 1

• Property:P8024 "Nobel Laureate API-ID"
  

• Property:P4819 "Swedish Portrait Archive"
  

Example how WikiAPIConnector is designed were Andrew Lih looks into define different GLAM APIs in YAML i.e. there is a need to easier access the API...

Alvin is Uppsala University Property:P6821

• Wikidata Q65095532 has property P6821 alvin-person:51603

  • his landing page is then http://www.alvin-portal.org/alvin/view.jsf?pid=alvin-person%3A51603&dswid=9290 and EE works

  • if you do a search and land on the landing page the URL looks like https://www.alvin-portal.org/alvin/view.jsf?dswid=9290&searchType=PERSON&query=D%C3%BCsterbach%2C+Hans&aq=%5B%5B%7B%22free_text%22%3A%22D%C3%BCsterbach%2C+Hans%22%7D%5D%5D&aqe=%5B%5D&af=%5B%5D&pid=alvin-person%3A51603&c=1 - dont Work

  • https://www.alvin-portal.org/alvin/view.jsf?dswid=-784&pid=alvin-person%3A51603 - dont Work

Any way to better set up the property to support this?

• we have format as a regular expression ^alvin-(record|person|place|organisation|work):[1-9]\d{0,6}$

**Wikicommons ** can we sport them?

• P7847 is used for identificator for pictures -->
  • P7847 = 021018866980 --> Wikicommons M107139335 / json

Environment

• addon version: v0.9.1
• browser: Firefox v102.0

Issue

The addon blocks the browser for more than 1s at every URL change, as matchpattern_match runs its 5000+ regexes on the new URL. From the addon logs:

matchpattern_match false on about:addons took 1345ms

It might be that some of those regexes are particularly slow, or just that there are too many of them to run fast

The context

I have noticed that in Deezer, when visiting the page of a album, the URL contains the language the page is being displayed in. For example, all of the following URLs correspond to the album "Everyday Life" of "Coldplay" in the Deezer database. The Wikidata item that corresponds to this album is Q72087708

https://www.deezer.com/us/album/119673702
https://www.deezer.com/ru/album/119673702
https://www.deezer.com/mx/album/119673702
https://www.deezer.com/es/album/119673702
https://www.deezer.com/fr/album/119673702
https://www.deezer.com/en/album/119673702

The problem

As of the time of this writing, the current revision of the property contain the following values for P1630, "formatter URL"

https://www.deezer.com/album/$1
https://www.deezer.com/us/album/$1
https://www.deezer.com/ru/album/$1

This makes the first two links (in the group of links shown above) to be matched with the album in Wikidata.

https://www.deezer.com/us/album/119673702
https://www.deezer.com/ru/album/119673702

but the other URLs won't be matched to the album

https://www.deezer.com/mx/album/119673702
https://www.deezer.com/es/album/119673702
https://www.deezer.com/fr/album/119673702
https://www.deezer.com/en/album/119673702

The proposed solution

The problem would be solved if the value for P8966 would be used instead. The value is shown below.

^https?:\/\/www\.deezer\.com\/(?:[a-z]{2}\/)?album\/([1-9]\d+)

All of the following URLs shown above are matched by this regular expression. See this test at regex101.com for more information (a screenshot of regex101.com is shown below)

Personal thoughts

• I think if EntityExplosion only used P2723, "formatter URL", we would need to add all language code to all properties that point to a website that show the language code in its URLs. A flaw of doing this is that some websites might support some languages codes will others not. Therefore, ensuring that "formatter URL" is complete in a property is a non-trivial task, and doesn't seem to be a bot doing this arduous task.
• I concluded that the current implementation of EntityExplosion doesn't use P8966 because I searched P8966 in the root folder of the source code using grep and no match was found.

I have played around see #15

When on page http://api.nobelprize.org/2.1/laureate/1002 --> I get wrong person

cc: @VisbyStar

Suggestion Add Graph query link

One way to visualize a WD object is a graph

• Gadget MediaWiki:Gadget-EasyQuery.js is doing this in a nice way that I suggest is an option in Entity Explorer
  ** can also be activated in the UI mw-prefsection-gadgets

• Example
  ** Albert Einstein Q937 you click on the 3 dots and get https://w.wiki/4ENd

** Toby Hudson Q48669311 --> https://w.wiki/4ENf

Hello,
Thank you a lot for your project, it gives me many ideas.

I discovered that the person ID for France Culture (wd:P5301) is not working in Entity Explosion. By exploring the code, it turns out that the query:

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT DISTINCT ?prop ?regex ?formatter_url WHERE {
{?prop wdt:P1630 ?formatter_url .}
UNION
{?prop wdt:P3303 ?formatter_url .}
FILTER (CONTAINS( ?formatter_url, "$1" ) )
?prop wdt:P1793 ?regex .
SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } .
}

does not return the entity wd:P5301, since it has no regex defined using the property wdt:P1793. But it has a regex defined by the path ?prop <http://www.wikidata.org/prop/P2302> ?o. ?o <http://www.wikidata.org/prop/qualifier/P1793> ?regex. and reformulating the above query as:

PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX wd: <http://www.wikidata.org/entity/>
PREFIX wdt: <http://www.wikidata.org/prop/direct/>
SELECT DISTINCT ?prop ?regex ?formatter_url WHERE {
{?prop wdt:P1630 ?formatter_url .}
UNION
{?prop wdt:P3303 ?formatter_url .}
FILTER (CONTAINS( ?formatter_url, "$1" ) )
?prop <http://www.wikidata.org/prop/P2302> ?o.
?o <http://www.wikidata.org/prop/qualifier/P1793> ?regex.
SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } .
}

allows to obtained wd:P5301 in the answer set. It also returns more answers: 5660 against 4428 with the previous query. The answers may be different anyway.

What do you think of changing the first query by the second one ?

When loading in Firefox, the following warning is shown:

Reading manifest: Warning processing background.persistent: Event pages are not currently supported. This will run as a persistent background page.

It doesn't seem to affect operation.

According to web-ext lint, the icons should be square:

ERRORS:

Code                                 Message           Description                        File            Line   Column
ICON_NOT_SQUARE                      Icons must be     Icon at "EE-grey-38.png" must be   manifest.json                
                                     square.           square.                                                         

Both browsers say the same (although they helpfully don't actually say 'square', but all the examples are square):

• https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/icons
• https://developer.chrome.com/extensions/manifest/icons

It looks plausible that the cached languages list is outlasting version upgrades (even when they change the query!). Tipoff here: https://www.wikidata.org/w/index.php?title=Wikidata_talk%3AEntity_Explosion&type=revision&diff=1507369321&oldid=1507223474

More aggressive updating of the cached data looks necessary.

Code illustrating sunset clauses on cached data here: https://stackoverflow.com/questions/31766467/how-do-i-cache-data-in-chrome-extension

https://uk.flightaware.com/live/airport/YAMN
The query isn't specific enough.

dont know if it is a good pattern but its used when we have support for more languages in the external sources

• https://www.wikidata.org/wiki/Property:P7704#P1630
• https://www.wikidata.org/wiki/Property:P4963#P1630

If you go to page en/article/NaimaSahlbom and try Entity Explosion I get two entries for Svenskt kvinnobiografiskt lexikon that is what I want

• SKBL page
  • english https://www.skbl.se/en/article/NaimaSahlbom
  • swedish https://www.skbl.se/sv/artikel/NaimaSahlbom
• SKBL Json page https://www.skbl.se/en/article/NaimaSahlbom.json
• Wikidata property Property:P4963

Question:
Have I set up P4963 correct as you think we should to get the best usage of Entity Explorer??

Hi Toby

I need help how to set up Property:P8168 that is a Wikibase database for historical research we try to match with WIkidata see Task T266745

• Factgrid Item:Q176477 is same as Wikidata Q15695036 but it fails?!?!?
• the other way around is no problem see video

As this is an extension in development I guess we should have a version number easy available