Wikidata talk:Entity Explosion

Videos

@99of9: I created an item for this extension (Q98398855). It would be nice if you could upload your videos to Commons, and perhaps the logo too. I'd also recommend licensing your videos on YouTube under a CC BY license (YT allows you to). NMaia (talk) 12:59, 15 August 2020 (UTC)

Thanks! I've done the uploads and found where to change the license. --99of9 (talk) 02:37, 16 August 2020 (UTC)

Supported browsers

Do I understand correctly that this works only on Chrome? It doesn't say so, but there is no mention here of any other browser. - Jmabel (talk) 17:21, 15 August 2020 (UTC)

@Jmabel: I am ignorant on such things, this is the first extension I've ever written, and almost the first Javascript I've written. So I wrote it for Chrome as a first pass. I still hope to port it to others once I've sorted out any issues arising from the wide scale Chrome testing. However, some who know about these things have already tried dumping the code into other browsers, and apparently Firefox works ok @Samwilson:, as do Brave and Edge @Peteforsyth:. They can probably tell you how if you use those browsers.--99of9 (talk) 02:36, 16 August 2020 (UTC)

@Jmabel, 99of9: Yep, it seems to work fine in Firefox! Load it by getting the code from Github, then it via about:debugging, and 'Load temporary add-on…'. Select the manifest.json file, and it'll be loaded. There seems to be a bit of a glitch (I'll make a bug report soon) where it doesn't show the dropdown menu unless you've clicked in the page to focus it first. Sam Wilson 03:02, 16 August 2020 (UTC)

@Samwilson: Thanks. Project page should say that, no? - Jmabel (talk) 04:10, 16 August 2020 (UTC)

@Jmabel: probably, but it might be better to wait for 99of9 to get it released for Chrome, then maybe released for Firefox. Installing manually should really only be a developer thing, it's much nicer for end users to just use the browser store. —Sam Wilson 00:30, 17 August 2020 (UTC)

@Samwilson, Jmabel: It's already released on Chrome - see link in page. I've gone with a hybrid between your suggestions. The page now clearly states that it's a Chrome extension (for now), but also points to this talk page for reported off-label use if anyone is code-savvy. --99of9 (talk) 01:02, 17 August 2020 (UTC)

@Jmabel, Samwilson, 99of9: FWIW, there seems to be another add-on for Firefox. See [1]. NMaia (talk) 05:11, 19 August 2020 (UTC)

@Jmabel, Samwilson, 99of9, NMaia: It's now up on the Firefox Browser Add-On site: https://addons.mozilla.org/en-US/firefox/addon/entity-explosion/ --99of9 (talk) 14:40, 22 August 2020 (UTC)

• Thanks! - Jmabel (talk) 17:20, 22 August 2020 (UTC)

Dropdown URL matcher

I'm working on improving the dropdown URL matcher. I'll put the improved draft here in case others want to help. Feel free to test against URLs that don't get matched (just place the one you care about in one of the VALUES brackets).

SELECT DISTINCT ?iri ?prop ?propLabel ?id_uncut ?id ?lcid ?regex ?item ?itemLabel ?test_url ?formatter_url WHERE {
  hint:Query hint:optimizer "None".
  VALUES ( ?test_url0 ) { 
            ( "http://plantnet.rbgsyd.nsw.gov.au/cgi-bin/NSWfl.pl?page=nswfl&lvl=sp&name=Hibbertia~spanantha" )
            ( "https://www.lions.com.au/players/7" )
            ( "https://reiseauskunft.bahn.de/bin/bhftafel.exe/en?input=8400285&boardType=dep&time=actual&productsDefault=1111101&start=yes" )
            ( "https://www.inaturalist.org/taxa/47582-Ostreidae" )
            ( "https://twitter.com/BarackObama" )
  }
  BIND( IRI(?test_url0) AS ?iri ).
  {?prop p:P1630/ps:P1630 ?formatter_url0 .}
  UNION
  {?prop p:P3303/ps:P3303 ?formatter_url0 .}
  
  BIND (REPLACE(?test_url0,"^https://","") AS ?test_url1)
  BIND (REPLACE(?test_url1,"^http://","") AS ?test_url2)
  BIND (REPLACE(?test_url2,"^www.","") AS ?test_url)
  BIND (REPLACE(?formatter_url0,"^https://","") AS ?formatter_url1)
  BIND (REPLACE(?formatter_url1,"^http://","") AS ?formatter_url2)
  BIND (REPLACE(?formatter_url2,"^www.","") AS ?formatter_url)
  
  FILTER (CONTAINS( ?formatter_url, "$1" ) ) 
  BIND (STRBEFORE( ?formatter_url, "$1" ) AS ?f_url_start )
  BIND (STRAFTER( ?formatter_url, "$1" ) AS ?f_url_end )
  FILTER(STRSTARTS( ?test_url, ?f_url_start ))
  FILTER(STRENDS( ?test_url, ?f_url_end ))
  BIND ( SUBSTR( ?test_url, 1+STRLEN(?f_url_start), STRLEN(?test_url)-STRLEN(?f_url_start)-STRLEN(?f_url_end) ) AS ?id_uncut)
  ?prop p:P1793/ps:P1793 ?regex .
  BIND ( REPLACE (?id_uncut, CONCAT("(",?regex,").*"),"$1","i") AS ?id )
  BIND ( LCASE(?id) AS ?lcid)
  ?prop wikibase:directClaim ?propRel .
  {?item ?propRel ?id .}
  UNION
  {?item ?propRel ?lcid .}
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en" } .
}

Try it!

This should now also catch:

• all URL formatters and regex, not just the "truthy" ones.
• when Wikidata (incorrectly?) has only the lowercase version of the identifier, as is common on bot-imported Twitter handles
• when URLs and formatters have different variants of http / https / www. (this chops them all off the start of the URL)

--99of9 (talk) 14:10, 18 August 2020 (UTC)

The world's moved on from http

I have found a few sites not recognised by EE because the related formatter URLs in wikidata start http and the world has (rightly) moved on to https. I wonder if there is a query that can identify these so someone can check each of them out and change the string to https or should EE ignore the http or https at the start of the string? Back ache (talk) 12:11, 20 August 2020 (UTC)

@Back ache: Yes, that would be good. I've submitted an update (version 0.7.0) which for the dropdown query just cuts off the initial pieces of the URL: "http://" or "https://" and then "wwww." (see the section above this). So from that version forward, it shouldn't matter to EE if our data is out of date on this, but even still, it would be nice to be up to date. --99of9 (talk) 14:23, 20 August 2020 (UTC)

Retrieve identifiers from HTML <meta> tag

EE doesn't return anything interesting on web pages for many academic articles because the URL a user is likely to land on is not in Wikidata, nor can it be easily generated form the URL formatter rules. Specifically, if an article has a DOI, such as Making Mosquito Taxonomy Useful: A Stable Classification of Tribe Aedini that Balances Utility with Current Knowledge of Evolutionary Relationships (Q21003923) (DOI 10.1371/JOURNAL.PONE.0133602) this corresponds to the URL https://doi.org/10.1371/JOURNAL.PONE.0133602, which after a few redirects gets me to https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0133602 .

This behaviour is typical of an identifier that relies on redirection, that is, the identifier or URL that you cite (e.g., https://doi.org/10.1371/JOURNAL.PONE.0133602 ) is merely a pointer to the actual URL.

For academic papers with DOIs, a solution is to extract the DOI from the <meta> tag that most publishers will include in the <head> of the web page (e.g., so that search engines like Google Scholar (Q494817) will find them). For example,

<meta name="citation_doi" content="10.1371/journal.pone.0133602">

There is code on how to query <meta> tags on Stack Overflow (Q549037), e.g. http://stackoverflow.com/questions/7524585/how-do-i-get-the-information-from-a-meta-tag-with-javascript.

Of course, publishers have all sorts of different ways of including DOIs, putting the DOI in tags with the name citation_doi, dc.Identifier, DC.identifier, DC.identifier.DOI, etc.

Anyway, I think this would be a nice additional feature that would enhance EE. Querying the HTML for a page would also open up the option of extracting canonical URLs, which may be different from those shown in the web browser but which might correspond to an identifier used in Wikidata. --Rdmpage (talk) 10:16, 25 August 2020 (UTC)

Slowed my browser horribly

I tried it on Firefox. It slowed my browser horribly. Factor of at least 3 on most sites. Made Facebook absolutely unusable. While some might consider that last a benefit, I've decided not to experiment further. - Jmabel (talk) 23:02, 26 August 2020 (UTC)

@Jmabel: Wow, thanks for the report. The FF version is a bit newer and has about double the number of formatters. Speed probably scales with formatters. Can I check that you experienced this slowdown even without clicking the icon? This is probably in the pretesting of each new url to turn it red. I'll investigate this before I release that update to Chrome! I'll also ping you if I find a way to speed it up a lot. --99of9 (talk) 09:43, 27 August 2020 (UTC)

Not sure what you mean by "clicking the icon". Assuming the icon shows up in the web page, I never saw one. This was about pages taking forever to load. - Jmabel (talk) 15:20, 27 August 2020 (UTC)

@Jmabel: Thank you so much for reporting this. After I doubled the number of formatters, even in Chrome it was taking up to 1000 ms whenever the tab was switched. I've now overhauled this regex testing (which determines whether the icon goes red) with a binary search and some other optimisations, and it has improved by a factor of ~100. The new version (0.8.1) is under review for Firefox, and I'll submit it to Chrome now. --99of9 (talk) 13:29, 27 August 2020 (UTC)

And now already approved on FF. They are quick! Would you mind giving it another go? --99of9 (talk) 13:44, 27 August 2020 (UTC)

@99of9: That seems to be much better.

This was so drastic it's amazing no one reported it before me. - Jmabel (talk) 15:23, 27 August 2020 (UTC)

Lookup websites

When it fails to find anything, how about it looks to see if it has a match for the website itself, in other words if I go to microsoft.com EE does a lookup for a matching entry using "official website" P856

A use-case could be that when on a site that is talking about medicine, you could see who is behind the site so as to help you make a decision about their reputation in regards to what they are talking about.

Back ache (talk) 08:18, 8 September 2020 (UTC)

Yes, I've written some test queries for this, and it seems fast enough. So this is definitely in the pipeline. --99of9 (talk) 14:01, 10 September 2020 (UTC)

@Back ache: This is now implemented and live. Feel free to test it out and see if it's working as you expected. --99of9 (talk) 12:34, 17 October 2020 (UTC)

@99of9: Looks good, I'll enjoy trying it out, thanks for doing it Back ache (talk) 07:30, 21 October 2020 (UTC)

Can we put a wildcard on somehow

I notice EE recognises https://www.imdb.com/name/nm0136797 but not when IMDB puts some junk on the end https://www.imdb.com/name/nm0136797/?ref_=nv_sr_srsg_0

Can we get EE to ignore the extra stuff somehow? Back ache (talk) 12:51, 10 September 2020 (UTC)

Some random string insertions are harder than others. The example you've given is one of the easiest categories. I think it is doable. Some other categories might require me to propose a new supporting property. I haven't finished thinking them through. Feel free to experiment with the SPARQL if you're that way inclined. --99of9 (talk) 14:08, 10 September 2020 (UTC)

vglist and PCGamingWiki IDs not being found?

vglist video game ID (P8351) and PCGamingWiki ID (P6337) don't seem to be working for whatever reason. For example, the PCGW Half-Life 2 article should link to Half-Life 2 (Q193581) and the vglist.co Half-Life 2 page should also link to Half-Life 2 (Q193581). I confirmed the extension works with Spotify album IDs, but I'm not sure if there's an obvious reason for vglist and PCGW not to work?

The extension seems really neat, so I'd like to use it if I can :) I'm on Firefox, fwiw. Nicereddy (talk) 05:24, 11 October 2020 (UTC)

@99of9: I spent a while trying to debug this and I can't figure out what's wrong with it (it doesn't help that Firefox's extension debugger is a PITA). It happens in both Chrome and Firefox, fwiw. The regex seems to be valid and _should_ match the URL for any given vglist game page, but somewhere in the process it fails to find anything and I'm not sure why. Nicereddy (talk) 18:35, 11 October 2020 (UTC)

Is it only returning items where the property has a third party formatter URLs? That'd be the best explanation I have. Nicereddy (talk) 18:55, 11 October 2020 (UTC)

Figured it out, the property needs a format as a regular expression (P1793) for the query to find it. I added one for vglist video game ID (P8351) and it started working. The property already had a regular expression format, but it was under the property constraints. Now there are two separate places where the regex is defined, which isn't great, but I guess it solves the problem. The extension should probably handle this situation better than it currently does. Nicereddy (talk) 19:14, 11 October 2020 (UTC)

Thanks User:Nicereddy. --99of9 (talk) 23:30, 11 October 2020 (UTC)

Use for updating Wikidata

This would be marvelous for updating Wikidata. The source is readily available and could be added to the statement without effort. – Susanna Ånäs (Susannaanas) (talk) 10:07, 1 December 2020 (UTC)

@Susannaanas: Can you expand on your vision? Do you mean creating new items with the ID of the page you are at? If so, my concern is that it will be a pretty bare item, and I'll be lucky to even guess the page title correctly from the HTML. --99of9 (talk) 07:52, 19 May 2021 (UTC)

Sorry I had not noticed this message earlier. I did not think thoroughly what kind of information could be gathered. I will look into the following example to see what information they are able to dig out. Cheers, Susanna Ånäs (Susannaanas) (talk) 15:20, 7 January 2022 (UTC)

@Susannaanas: If you want to update Wikidata (as well as see data from it) Wikidata for Firefox has those features so that maybe the right tool for your purpose Back ache (talk) 12:10, 7 January 2022 (UTC)

This seems quite interesting! I will have a closer look at the data mining option as well. Cheers, Susanna Ånäs (Susannaanas) (talk) 15:23, 7 January 2022 (UTC)

Tap into "URL match pattern" property?

I'm not sure if this extension is still in active development, but do you think it's possible to also utilize URL match pattern (P8966) as another way of matching the URL to the corresponding Wikidata page? So far I've also been using Wikidata for Web (Q99894727) that taps into this property, and it seems to deal well with URLs that have extra human-readable slugs or query strings in them (provided the URL match pattern for the relevant ID property accounts for such cases appropriately). --Btcprox (talk) 03:50, 10 February 2021 (UTC)

@Btcprox: Thanks for the note. It's likely to be a long-term low-intensity development. I've submitted a couple of improvements recently, now including thumbnails if an image is set in WD. Yes, I was consulted during the proposal of URL match pattern (P8966) and do plan to use it. EE already has some heuristics to get rid of some appended slugs, but I agree that a regex will tighten things up.--99of9 (talk) 07:57, 19 May 2021 (UTC)

Configure Wikibase

Is it possible to configure local Wikibase to take advantage of EE? Our entity will have a property for Wikidata ID if available. What do we need to do in Wikibase to enable your EE to connect and pull down Wikidata description? (see attached image) Thank you. jshieh (talk) 19:03, 2 August 2021 (UTC)

EE & Wikibase

At the moment it can't unless the link goes in the other direction (i.e. WD links to your Wikibase). I'll try to think about how it might be possible in the long term. This problem is a little bit like DOIs appearing within the page but not in the URL string. --99of9 (talk) 23:59, 2 August 2021 (UTC)

wd

Hello. Let's say I'm visiting this URL, which is the vanilla one for the webpage World Aquatics (Q189289) maintains about Florent Manaudou (Q137575). Entity Explosion is not able to do anything from there, and yet we have World Aquatics athlete ID (P3408) set on the French swimmer's Wikidata item. That's because we willingly store as IDs for that property the shorter numerical parts – here 1031569 – of what are otherwise longer alphanumerical bits – here 1031569/florent-manaudou. The thing is, most of the time, whenever a formatter URL has a bunch of characters that needs to be there but can be randomly generated, we use wd as a subtle key in formatter URL (P1630). Entity Explosion could probably take avantage of that to do its job even from URLs that do not match the exact vanilla URLs met on a given website. Here, in our example, https://www.fina.org/athletes/1031569/florent-manaudou would be understood as an equivalent to https://www.fina.org/athletes/1031569/wd, from where Entity Explosion does work already. Can someone take time to implement this? It will be useful for about 50 external identifiers that happen to use that feature, 50 being a wild guess of mine. Thierry Caro (talk) 00:07, 17 August 2021 (UTC)

Yes, this is a good idea. Personally I prefer using "_" instead of "wd", because it's less likely to be part of a normal URL word. But either way, EE should figure out how to strip it with careful SPARQL. As suggested a couple of items above, another way to do this would be to implement URL match pattern (P8966). --99of9 (talk) 03:51, 17 August 2021 (UTC)

Expand URL that using Q#

This WADE project has ended unfortunately, before the EE was launched I think. Will the API be able to make use of a URL that references Wikidata Q#? https://art.wikidata.link/item/Q20441431. Thank you. jshieh (talk) 20:14, 13 September 2021 (UTC)

@ShiehJ: At the moment EE can't link either from or to URLs like this. I certainly want to. Recognizing these URLs will probably happen first. Linking to them needs more thought, because such sites don't usually cover every Wikidata item, but just those from a select domain (e.g. artworks). --99of9 (talk) 06:33, 26 September 2021 (UTC)

@99of9: Thank you so much for your response. In the case of this site, it's a subset of Wikdiata for art. The site pulls in additional data from local database, in this case provenance data from SAAM.

Is the interface translatable?

Is the interface translatable, if so where? --Sabelöga (talk) 00:20, 25 September 2021 (UTC)

@Sabelöga: Great question. At the moment only the interactive bits (the labels for the language and the entity) are auto-translated. I'd like to translate some of the other strings, but I don't know any other languages, and I don't know how to use community translation sites. The code is open source if you know something about this and would like to help. --99of9 (talk) 06:26, 26 September 2021 (UTC)

@99of9: As a first iteration, I think even GitHub pull requests would suffice to handle new translations. In the long run, I think the best would be to use translatewiki.net, as that’s what Wikimedia translators are used to, although as far as I see, it doesn’t currently support WebExtensions’ i18n file format.

By the way, I couldn’t find Hungarian in the language selector dropdown—is it because of the LIMIT 500 in the SPARQL query? Why do you use SPARQL in the first place, instead of e.g. the API telling the languages known to Wikibase? —Tacsipacsi (talk) 16:39, 26 September 2021 (UTC)

@Tacsipacsi: Thanks for the note. It wasn't the LIMIT, it was a query bug (wdt:P279*/wdt:P31 instead of wdt:P31/wdt:P279*) - already fixed in the next version, which picks up an extra 14 languages bringing EE to 301. To be honest I didn't know about the API. But since I want to be a little selective, and draw in labels for the autotranslation, I'm happy that I can do it and customise it in SPARQL (currently https://w.wiki/48KQ). --99of9 (talk) 01:06, 27 September 2021 (UTC)

@99of9: Actually I didn’t know about the API either, but I thought that there should be one. There are two problems with the SPARQL solution: first, it almost certainly contains a different set of languages than those that are actually supported by Wikibase (and I don’t speak about query bugs, but rather languages that have Wikidata items but aren’t supported by Wikibase, or are supported by Wikibase, but their items don’t exist/contain the appropriate P31 statement); second, the autonyms are a total mess: some languages’ items’ labels contain the translations of “language” (српски језик), others don’t (slovenščina); some are properly lower cased (français), others are capitalized even though they aren’t normally capitalized in the middle of a sentence (Occitan). —Tacsipacsi (talk) 00:02, 28 September 2021 (UTC)

@Tacsipacsi: Fundamentally, one reason I'm at Wikidata is because I want open user-maintained data to be better. So although you rightly point out some problems with the SPARQL-generated interface, I simply see that as highlighting places where our data can be improved. Soon after it is improved, the interface will improve. One of my hopes for EE is that it will drive users toward editing for reasons exactly like this (or perhaps more commonly, when property labels are not translated into a user's language). You'll be interested to know that I've just released an update which at least shows you which Wikimedia language code (P424) each dropdown label corresponds to (and makes clearer what is being used to order the list). I'd be interested to hear your thoughts, especially if you're testing in Hungarian! --99of9 (talk) 12:41, 1 October 2021 (UTC)

@99of9: I think Wikidata labels are simply not suitable for this purpose, there are many other points to consider when setting labels (Wikipedia article title, name used when speaking about the language in running text etc.), this could lead in extreme case to edit wars between EE users and others, who consider the other points, which are more important for non-EE users. If there was a property that consistently contains the autonym used in language dropdowns, I’m not against using Wikidata in principle, though.

I see the language codes in the new version, but Hungarian is still not there (in contrast to Greek, which is present twice, once as Ελληνικά and once as Νέα ελληνική γλώσσα)—please update the actual query as well, not only the comments… —Tacsipacsi (talk) 21:49, 2 October 2021 (UTC)

@Tacsipacsi: Thanks for your help. I see Hungarian (Q9067) there, listed as "[hu] magyar". Can you check again, or is there another bug? It looks like the actual query got fixed a while back, it was just my comments that were out of date. --99of9 (talk) 04:10, 3 October 2021 (UTC)

@99of9: I see, I checked just the most recent commit. :) No, I still don’t see Hungarian—is by chance the result cached from before the query was fixed? You should invalidate the cache whenever you change the query. (For example you could store a serial number or the hash of the query string next the cached data, and throw the cache away if the serial number/hash doesn’t match.) By the way, you should regularly clear the cache (and certainly not keep it for over a year) even without any query changes, otherwise users won’t see improvements to the data… Maybe you should not cache the data at all—it results in poorer performance, but it’s (AFAIK) the only way to make sure that users immediately see the improvements they’ve just made. —Tacsipacsi (talk) 10:56, 3 October 2021 (UTC)

@Tacsipacsi: Oooh, that is possible. I assumed that the cached data would always be scrapped each time a new version of the extension was uploaded (every few months). But this could be wrong. I've filed an issue at https://github.com/99of9/Entity-Explosion/issues/14 to make sure I fix this. Thank you again! --99of9 (talk) 11:56, 3 October 2021 (UTC)

By the way, what about the translation of static pieces of text? It’s good that we found this bug, but the original question was about translating the interface, not about how many languages are there in the dropdown. —Tacsipacsi (talk) 12:30, 3 October 2021 (UTC)

@Sabelöga, Tacsipacsi: As of version 0.9.5 I've finally done i18n localization of all the static text into all the languages that Chrome supports (including sv and hu - feel free to suggest or submit changes). Thanks for suggesting this. Sorry it took so long! I'd appreciate any further feedback you have. --99of9 (talk) 02:01, 3 May 2024 (UTC)

Wonderful! Better late than never.  Like Sabelöga (talk) 07:57, 3 May 2024 (UTC)

URL match pattern

With so much work done to add "URL match pattern" to propertys, could support be added to draw down on that too as a way to identify Q's?

For example EE doesn't know what to do with https://portal.issn.org/resource/issn/2398-8762 however the regex in the "URL match" in ISSN does and would lead to Q25631122 Back ache (talk) 12:03, 22 November 2021 (UTC)

Yes, absolutely! The last update implemented this for the red-icon flagging, but not for the actual dropdown search. (In your example, because the issn site redirects to portal.issn, I think it's best for us to put it in our formatter url. So I think this specific site will now be recognized by EE. But the issue you raise has been on my list for ages, and is not yet fully implemented. Thanks for the reminder.) --99of9 (talk) 00:06, 23 November 2021 (UTC)

Why's it not matching?

I was on the website of the https://goodlawproject.org/ but EE didn't find a match.

I can see Q106244373 has an official website with that URL in it, so why no match? Back ache (talk) 09:29, 28 November 2021 (UTC)

It was related to the trailing slash. I took it off the WD property and it now resolves (although someone may quite fairly revert me). Clearly EE needs to be able to deal with either. I think this is the same issue as is now tracked in [2]. --99of9 (talk) 02:31, 3 May 2024 (UTC)

Add new identifier source?

I recently came across EE that recognizes identifiers from external, see screenshot. Is a way for user of the EE to add new ID sources like the one in Zhihu topic ID (P3553)? Or this can only be accomplished by you the app creator? I am especially keen to be able to connect Smithsonian resource ID (P7851) to an item, e.g., Portrait of the Qianlong emperor as the bodhisattva Manjushri (Q110917158). Thank you so very much for your insights. jshieh (talk) 20:15, 15 March 2022 (UTC)

source

I'm seeing the relevant Smithsonian resource ID show up for EE on both the Item page https://www.si.edu/object/fsg_F2000.4 and https://www.wikidata.org/wiki/Q110917158 when looking at EE on those pages? I'm not sure what you are asking to do with EE. Editing by adding value associated with the Property you want to display in EE on the related Q would display the ID, possibly with a slight delay to let the change propagate. Wolfgang8741 (talk) 17:51, 16 March 2022 (UTC)

@ShiehJ, Wolfgang8741: If the Smithsonian ID is shown in English but not in Spanish, it's because there is no Spanish label for the property (on Smithsonian resource ID (P7851)). If this causes people to add labels for all the properties in their language, I would like that very much! Here is the list of the properties missing descriptions in Spanish: [3].--99of9 (talk) 23:48, 16 March 2022 (UTC)

I did not realize that SI ID is already recognized by EE!

As for the Smithsonian resource ID (P7851) label in more than just English, we need to work on it! Thank you so very much for alerting us! jshieh (talk) 13:38, 17 March 2022 (UTC)