RickView RDF Browser Survey
Please state whether you fully disagree (1), fully agree (5) or anything in between with the following statements about RickView and RDF browsers in general.

RickView is an RDF browser, i.e. a web application where users can browse datasets published as Linked Open Data, also known as knowledge base or knowledge graph. In the following we use the term knowledge graph (KG) and include ontologies.

If a statement doesn't apply to you, please leave it blank.
Sign in to Google to save your progress. Learn more
There should be dereferencable human-readable (HTML) information about each individual URI in a knowledge graph.

Clarification example 1: The KG DBpedia contains the URI http://dbpedia.org/resource/Leipzig. A user dereferences this URI by entering it in a browser address bar and receives a website that describes that resource.
The DBpedia RDF browser thus satisfies this criterion.

Counterexample: Entering " http://www.w3.org/2000/01/rdf-schema#label" in a browser results in the download of the RDF Turtle serialization of RDFS.
Clear selection
There should be dereferencable machine-readable information (e.g. RDF Turtle, N-Triples) about each individual URL in a knowledge graph
Clear selection
Users should be able to override the default format and manually specify one (e.g. HTML, RDF-Turtle, N-Triples) using a GET-parameter, for example https://example.com/mykb/elefant?format=ntriples
Clear selection
The default format should not be HTML but instead be automatically selected using content negotiation. For example, a human user with a web browser would receive HTML, but someone using curl with the accept header set to N-Triples would receive N-Triples.
Clear selection
A KG should be available for download as a dump file (serialized RDF, for example as N-Triples or HDT).
Clear selection
It is enough (or even better than deploying an RDF browser) to publish a dump file or an HTML summary of the complete KG at the namespace URI of a KG.
Clear selection
RDF browsers are a solved problem, I am fully satisfied with the current options (excluding RickView).
Clear selection
Short downtimes of an RDF browser can have a negative effect on the usage of the dataset (e.g. interlinking, citations, choice as vocabulary for a specific purpose).
Clear selection
Prolonged downtimes of an RDF browser can have a negative effect on the usage of the dataset (e.g. interlinking, citations, choice as vocabulary for a specific purpose).
Clear selection
An RDF browser should be able to use a SPARQL endpoint as its data source.
Clear selection
... load serialized RDF from a file, e.g. mygraph.ttl.
Clear selection
... load serialized RDF from a URL, e.g. https://mydomain.com/mygraph.ttl.
Clear selection
... load compressed archives of serialized RDF, such as mygraph.ttl.zip
Clear selection
... load serialized RDF in the compressed Header Dictionary Triples (HDT) format
Clear selection
... map blank nodes into the namespace and display them
Clear selection
... as an option export a static HTML page for each resource
Clear selection
... map and compact common constructs that are modelled using multiple resources into a single resource page. For example statements about blank nodes, RDF lists, sets, bags, OWL restrictions and axioms and more.
Clear selection
A KG should have a public SPARQL endpoint that is maintained indefinitely after the project ends.
Clear selection
A KG should have a public RDF browser that is maintained indefinitely after the project ends.
Clear selection
Server RAM usage is a constraint for me. (only check if you deploy services on servers)
Clear selection
Server CPU usage is a constraint for me. (only check if you deploy services on servers)
Clear selection
Web application client performance (CPU, RAM, latency) is important to me. (only check if you deploy web applications)
Clear selection
I care about whether an RDF browser looks great
Clear selection
An RDF browser should...
1
2
3
4
5
hide as much technical RDF details as possible.
be so intuitive that it can be used without problems by users that have no experience with Linked Data technologies.
reflect changes to the underlying KG without a restart on the server.
allow edits, inserts and deletions into the KG
be generic and work with all kinds of KG
be closely tied in design and functionality to a specific KG
Clear selection
In order to adapt and deploy an RDF browser for a new KG it is acceptable to
1
2
3
4
5
fork the repository and modify the source code
create a configuration file
use environment variables
run a single executable file
run a Docker Compose Setup with multiple components
build and run a single Dockerfile
run a single Dockerfile from a public registry
Clear selection
I currently deploy the following RDF browsers
For a future project I would consider the following RDF browsers
My favourite RDF browser is
Please try the RickView installation at https://www.snik.eu/ontology/ and rate the following attributes from 1 (fully dissatisfied) to 5 (fully satisfied with RickView in regards to that attribute)
1
2
3
4
5
Speed
Design
Intuitiveness
Functionality
Clear selection
Did you encounter any errors? If yes, please write them down below.
Did you miss any important features? If yes please write them down below.
Thank you very much for taking the time out of your probably busy day, it is much appreciated! If you have any further comments, feel free to share them below.
Submit
Clear form
Never submit passwords through Google Forms.
This content is neither created nor endorsed by Google. Report Abuse - Terms of Service - Privacy Policy
Google Forms