What is it?

Cross-Origin Resource Sharing (CORS) is a specification which enables javascript access to resources on other domains. Not all endpoints are CORS-enabled, meaning they do not set the Access-Control-Allow-Origin: * header in their response. As a results these endpoints are not accessible via your browser (i.e. javascript)directly, unless these endpoints are on the same domain as YASGUI (i.e. and the endpoint is using the same port as YASGUI (e.g. port 80). A CORS-disabled endpoints are accessible via other non-browser based tools such as command-line tools or java / python / php / etc.

How does YASGUI deal with CORS-disabled endpoints?

YASGUI prefers accessing endpoints via javascript as this decreases latency. Whenever you enter your endpoint in the YASGUI interface, YASGUI detects whether this endpoint is CORS-enabled. When it is, every query is executed via javascript directly. When the endpoint is CORS-disabled, the YASGUI server acts as a proxy. The YASGUI server is able to access a CORS-disabled endpoint, which is why we use this as a middle-man in accessing the CORS-disabled endpoint.

How can I access CORS-disabled endpoints which are installed locally?

Using this proxy is a great solution in accessing all public SPARQL endpoints. However, when you have a CORS-disabled endpoint installed locally on your computer, the YASGUI server is not able to access this endpoint from the outside. To access these endpoints, choose one of the options below
If possible, we recommend this approach. Several endpoints support enabling or disabling cross-domain javascript access via a simple configuration setting.


Change the config file (locate in /etc/4store.conf), and add (under the default category) cors = true. More about CORS-enabling 4Store here.


To CORS-enable virtuoso via their web interface, follow the steps described here.
A simple CORS proxy around uses node-js: CORS-Proxy. After installing and running this proxy, you can use this proxy like this: http://localhost:9292/localhost:3000/query, where http://localhost:9292 is the location of the proxy, and localhost:3000/query is the CORS-disable endpoint.
Possible the easiest way of accessing CORS-disabled endpoints is by installing a browser extension. Such browser extensions can modify the response headers, and add the CORS headers automatically for all responses the browser receives.


Download and install the firefox browser addon here. After restarting the browser, make sure you have the addons bar enabled (via View → Toolbars → Add-on Bar). To enable cross-domain access to all endpoints, click on the CORS button in the bottom-right of your screen.


Download and install the chrome browser extension here. To enable cross-domain access to all endpoints, click on the CORS button in the top-right of your screen.
Forcing cross-domain access for all responses, reduces your browser security. Only enable these plugins during the period you use the CORS-disable endpoints

Property Autocompletion


Start typing a predicate/class (either prefixed or as a complete URI). Then, press CTRL-<space>(or COMMAND-<space> for apple). This results in a autocompletion dialogue with up to three different kind of colour-coded suggestions. Below, we explain each type of suggestion in detail.


YASGUI uses three different methods for autocompleting properties and classes. Each of these methods have their own advantages and disadvantages:

1. Cached from previous SPARQL queries

The properties/classes are fetched from previous SPARQL queries. A property is stored whenever it occurs in the predicate position, and a class is stored whenever a triple pattern shows either the object or object + subject are classes (how?). This results in reliable autocompletion suggestions. Suggestions fetched are (almost) guaranteerd to be available in the endpoint you are using. A downside of this method is that the queries (most probably) do not cover all possible properties in this endpoint.
For properties, this cached list is the lazy and incomplete equivalent of querying for predicates. However, this way of retrieving properties is not feasible for most endpoints, as such queries are very expensive.

2. Fetched from querying the dataset

This type of autocompletion suggestion is fetched by issueing a rdf:property query or rdf:type query, and storing the results on the YASGUI server. The major advantage of this type of query is that it is fast, and might result in a relatively complete set of properties. The downsides are:
  • for properties:
    • Not all endpoints define their properties as being of type rdf:property
    • The list of fetched properties might not correspond with the list of properties occuring in the predicate position. (e.g. a rdf:property in DBPedia has a trailing _, where the predicate equivalent does not have this trailing _)
  • in general:
    • The resultset of this query can be too large to fetch via SPARQL. Something which is the case for DBPedia. (Why?)

3. Properties and classes fetched from Linked Open Vocubulary (LOV)

LOV hosts a large set of Linked Data vocabularies. The LOV API provides an autocompletion service for all the properties and classes defined in these vocabularies. The advantage of this approach is the availability of vocabularies, regardless of the used endpoint. However, the suggestions provided from LOV are not necessarily in the endpoint being queried, making the precision of this approach low.

How these methods relate to each other

When a URI is suggested by more than 1 autocompletion method, the suggestion is shown as coming from the method with the highest 'reliability' (with reliability we mean the chance of this property actually occuring in the dataset). In other words, when method 1 and method 2 provide the same property as a suggestion, we show this property as coming from method 1.