DanNet resources on the web

[simongray]

The DanNet-specific resources/entities should be resolvable via their URI.

Navigating to the URI should result in some form of content negotiation and the return of either a data structure (JSON, EDEN, TTL) or perhaps a basic HTML web page. The data comes directly from an instance of a TDB graph. This is in line with recommendations for linked data.

The new DanNet OWL schema should also resolve. This is a more specific case (effectively just serving static data).

[simongray]

Basic rate limiting should also be in place so that the website does not become a public API for any external client website, but not much that it limits the individual user.

[simongray]

As of c66a246 there is a unfinished search endpoint, translations for everything except the UI and the GWA relations, and an unused autocompletion endpoint.

Now it seems possible that the project could benefit from being turned into a SPA, since the autocompletion )and probably several future features) will require some JS anyway and my prior SPA-making experience will make this process a lot smoother. However, this does entail setting up shadow-cljs for the project, maybe setting up frontend routing, converting the Hiccup in use to real reagent components, making more API-endpoints + extending the functionality of existing ones... so not a small task.

It's probably an advantage in the long run, especially considering the fact that I will eventually have to make an editor as well to replace the obsolete Python one.

[simongray]

The basic web app architecture has been document at https://github.com/kuhumcst/DanNet/blob/master/doc/web.md

[simongray]

Currently waiting for a reply from the representative from DSL that Sanni has out me in touch with.

[simongray]

Awaiting KU-IT for domain transfer. Hopefully it works out this time.

[simongray]

As of 0780566 the basic Docker setup seems to use ~1.4GB when relatively idle. I need to look into whether 2GB is enough for rebuilding the database. Still needs Caddy, but I'm sure that won't add much.

In any case, sounds like maybe 3GB is needed for the virtual server to ensure that it keeps running smoothly, although it would be fantastic if it could run on only 2GB.

[simongray]

Attempting to run a rebuild using a 2GB limit results in a lot of swapping, so the limit for the Java process unfortunately still needs to be set at 3GB. This would mean that idle period require ~2GB and the occasional rebuilds maybe ~4GB of memory from the server.

[simongray]

Currently waiting for KU-IT to create a server. Closing this issue for now, since the basic setup is done.