A quick RDF viewer (browser). Layout copied from LodView.
Install Rust including Cargo and clone this repository.
Binaries and prebuild Docker images will be available in the future.
Alternatively, you can cargo install rickview.
Default configuration is stored in data/default.toml, which you can override with a custom data/config.toml or environment variables.
Configuration keys are in lower_snake_case, while environment variables are prefixed with RICKVIEW_ and are in SCREAMING_SNAKE_CASE.
For example, namespace = "http://hitontology.eu/ontology/" in config.toml is equivalent to RICKVIEW_NAMESPACE=http://hitontology.eu/ontology/ as an environment variable.
You need to provide a knowledge base in RDF Turtle format, whose default path is data/kb.ttl.
If you don't, RickView will show a minimal example knowledge base.
Compile and run with cargo run and then open http://localhost:8080` in your browser.
cargo run
cargo build --release
docker build . -t rickview
docker run --mount "type=bind,src=$PWD/data/kb.ttl,target=/app/data/kb.ttl" --network="host" rickview
services:
ontology:
build: ./ontology
volumes:
- rdf:/ontology/dist
rickview:
build: ./rickview
environment:
- RICKVIEW_KB_FILE=/rdf/hito.ttl
- RICKVIEW_BASE_PATH=/ontology
- RICKVIEW_TITLE=HITO
- RICKVIEW_SUBTITLE=Health IT Ontology
- RICKVIEW_EXAMPLES=Study SoftwareProduct ApplicationSystemTypeCatalogue
- RICKVIEW_HOMEPAGE=https://hitontology.eu
- RICKVIEW_ENDPOINT=https://hitontology.eu/sparql
- RICKVIEW_GITHUB=https://github.com/hitontology/ontology
- RICKVIEW_DOC=https://hitontology.github.io/ontology/index-en.html
volumes:
- rdf:/rdf
ports:
- "127.0.0.1:8104:8080"
restart: unless-stopped
The default log level is "info" for RickView and "error" for libraries. Change the log level of RickView with the loglevel configuration key or the RICKVIEWLOGLEVEL environment variable. Override this setting using the RUSTLOG env var to configure the log levels of dependencies, see the env_logger documentation, for example:
RUST_LOG=rickview=debug cargo run
Existing RDF browsers like LodView look great but use too much hardware ressources as they are based on interpreted or garbage collected languages. This leads to long wait times and out of memory errors on typical small scale research VMs with dozens of docker containers for longtime archival of finished research projects, whose results should still be available to enable reproducible science.
Implement a basic RDF browser similar to LodView in Rust with the following goals:
All values approximated are are measured on an Intel i9-12900k (16 cores, 24 threads) with 32 GB of DDR5-5200 RAM on Arch Linux, standard kernel 5.18.
There is no page cache but there could still be internal caching benefits so this should be more elaborate in the future.
$ wrk -t 24 -c 24 -d 30 http://localhost:8080/SoftwareProduct -H "Accept: text/html"
Running 30s test @ http://localhost:8080/SoftwareProduct
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 9.79ms 3.25ms 26.92ms 56.40%
Req/Sec 102.36 36.17 212.00 66.74%
73590 requests in 30.02s, 1.04GB read
Requests/sec: 2451.31
Transfer/sec: 35.43MB
$ docker run --network=host -v $PWD/ontology/dist/hito.ttl:/app/data/kb.ttl rickview
$ wrk -t 24 -c 24 -d 30 http://localhost:8080/SoftwareProduct
Running 30s test @ http://localhost:8080/SoftwareProduct
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 13.96ms 4.74ms 37.20ms 55.04%
Req/Sec 71.77 26.17 121.00 66.43%
51572 requests in 30.02s, 567.72MB read
Requests/sec: 1717.72
Transfer/sec: 18.91MB
For comparison, here are the stats for the LodView RDF browser, written in Java and Swing.
As data is loaded after page load via JavaScript, real world performance may worse.
$ wrk -t 24 -c 24 -d 30 http://localhost:8104/ontology/SoftwareProduct
Running 30s test @ http://localhost:8104/ontology/SoftwareProduct
24 threads and 24 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 1.97ms 2.40ms 44.84ms 88.08%
Req/Sec 713.62 353.46 1.24k 38.76%
511567 requests in 30.03s, 1.61GB read
Socket errors: connect 0, read 1, write 0, timeout 0
Non-2xx or 3xx responses: 511567
Requests/sec: 17037.90
Transfer/sec: 55.07MB
LodView was not able to serve 24 threads and 24 connections, so try it with only 1 thread and 1 connection:
$ wrk -t 1 -c 1 -d 30 http://localhost:8104/ontology/SoftwareProduct
Running 30s test @ http://localhost:8104/ontology/SoftwareProduct
1 threads and 1 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 2.90ms 13.30ms 250.66ms 97.34%
Req/Sec 715.41 251.08 1.48k 69.46%
21227 requests in 30.01s, 68.61MB read
Non-2xx or 3xx responses: 21227
Requests/sec: 707.24
Transfer/sec: 2.29MB
Even a single thread and a single connection cause the container to report errors, this will be investigated in the future.
According to Hitzler 2021, mainstream adoption of the Semantic Web field has stagnated due to a lack of freely available performant, accessible, robust and adaptable tools. Instead, limited duration research grants motivate the proliferation of countless research prototypes, which are not optimized for any of those criteria, are not maintained after the project ends and finally compete for resources on crowded servers if they do not break down completely.
As RickView is still in the prototype stage, I would be very interested in hearing from you using it for your knowledge bases and am happy to assist you setting it up. Feature and pull requests are welcome, however the goal of RickView is to stay minimalistic and not serve every use case.
I think this would be overkill, as there is already a default configuration file, a custom configuration file, environment variables and Docker Compose supports .env out of the box as well.
So my assumption is that you use the configuration file for local development and .env with Docker Compose.
However if you need .env support outside of Docker Compose, just create an issue with a motivation and I may implement it.
RickView is not designed for large knowledge bases (many GB) such as the complete DBpedia, as it holds the knowledge base in RAM. In those cases, traditional RDF browsers based on a SPARQL endpoint are the better solution. However I do plan to test and if possible support knowledge bases up to around 2 GB of compressed size.