Check 3D visualizations from entity schemas

[labra]

I tried to visualize E37 in 3D but it failed: https://wikishape.weso.es/schema?id=E37

[ulitol97]

Some Wikidata schemas still behave weirdly or return slightly different data (note that not all of them, i.e.: https://wikishape.weso.es/schema?id=E21), further research and more user-friendly error handling is needed.

[ulitol97]

Now that I think about it, maybe @fidalgoLXXVI can shed us some light on the issue and why it happens on some of the schemas 🤔

[ExarcaFidalgo]

3DShex works in the latest version, so it is a matter of updating. Seems that when fixing the latest error in RDFShape such update was rolled back, so it is still pending.

Shumlex does indeed crash, in a rather uninteresting way: unsupported character (#). Mermaid has always been a pain in that regard.

[ulitol97]

I've updated 3DShex in both RDFShape and WikiShape and deployed the new versions. Results are certainly different but I'd say they are still not right.
I'll remain on standby, just in case there's anything I can help with.

[ExarcaFidalgo]

In the demo:

Package should be up to date, so I'm guessing it has to do with the way it is called in the sites. Now, i'd like to test it locally, but the following happens.

Is there any way to fool around?

[ExarcaFidalgo]

New version of shumlex, by the way.

[ulitol97]

For what I can see in the screenshots, the API server is not launched in your local environment, thus the network error. If the API is down, the validations/conversions are not attempted (even if performed locally like 3dshex, shumlex, etc.).

What I normally do for testing purposes is using RDFShape API's docker image to have it locally running in the background in port 8080. This does the trick:

docker run --name api -d -p 8080:8080 ghcr.io/weso/rdfshape-api:stable

By default, clients fetch the API in port 8080 so no files should be changed.

EDIT: Another possibility is that errors are indeed occurring but the client defaults to show the ambiguous Network error instead because the error cause is not found. Anyway, I'd first give it a shot with the API on.

[ExarcaFidalgo]

After fixing a small error, i have tried using the package in a web of my own and works nicely. RDFShape still produces huge nodes because of the following:

Since nodes are HTML. Adding a .node-label should do the trick, i think.

[ulitol97]

Well, then it is even more crear than before that 3dshex works perfectly and that the issues probably lie in how we're styling the visualization in RDFShape to fit it inside a container (instead of using 100% of the screen).
Anyway, have you tried using 3dshex in custom-sized containers? Or is this and RDFShape-exclusive problem?

It'd be great if you could take a look and try to diagnose what the CSS issue is, I mean, you are more acquainted with 3dshex than anyone. I'd be glad to help (maybe arrange a call) troubleshooting too.

[ExarcaFidalgo]

Through the library itself, we are able to set a custom container size for the graph. So i have added a new parameter for such purpose:

sh3.shExTo3D("shex", "id", {width: 650, height: 650});

Now, we'd need to call this one with the proper values and remove whatever measures were being taken later. For that I'll need your help

[ulitol97]

Thanks a ton, I'll keep you updated through this issue