[OpenLink Structured Data Editor] Linking to ontologies CORS error?

I am trying to use OpenLink Structured Data Editor (OSDE) to populate an RDF graph using a specific ontology as a TBox (as suggested in topic “Editing forms based on RDF/OWL classes?”) but I get a CORS error.

I have uploaded my ontology to be used as my documents’ TBox with base URI http://purl.org/myontology.owl in my local virtuoso instance, using its base URI as the graph name. Please note that this URI is also resolvable through a web browser, to the respective GitHub repository.

I create a new document in my OSDE instance and my first step would be to link my uploaded TBox ontology. When I try to add it (clicking the + button at the “Linked Vocabularies” section), I add a prefix (e.g. myontology) and the graph’s URI and finally get a CORS error message

CORS Error: http://linkeddata.uriburner.com/proxy?url=http%3A%2F%2Fpurl.org%2Fmyontology.owl&output-format=turtle&force=rdf failed to load - this could be related to missing CORS settings on the server… Do you want an empty ontology to be added?"

Questions:

  1. Is the ODSE trying to resolve my URL on internet or try to get the local virtuoso graph? If it tries to get it through internet, it would reach github which could of course prevent CORS and this is out of my reach.
  2. Is there a way to link a locally hosted ontology? Please note that I have already enabled CORS requests of local instance of Virtuoso.
  3. Is there a guide to OSDE (apart from the overview youtube video)?

@patsiavas: I presume you have installed the RDF Editor VAD on a local Virtuoso instance, as detailed in the documentation?

I note that site references an older RDF Editor VAD (0.17_git142) from 2017, with which I do get the CORS error you report with, but does not occur with the latest RDF Editor VAD (0.17_git181).

This please upgrade to this latest version …

Unfortunately, the error remains. I have updated to version: 0.17_git181 and restarted my vm but still I get the exact same error. I do not understand why http://linkeddata.uriburner.com/ is called. Please note that I have also tested it starting chrome with no CORS protection. Therefore, it must be a server side problem, and it should be somehow related with the virtuoso endpoint asked for the graph, (which seems to be http://linkeddata.uriburner.com/).

I would kindly ask again my questions:

  1. Is the OSDE trying to resolve my URL on internet or try to get the local virtuoso graph? If it tries to get it through internet, it would reach github which could of course prevent CORS and this is out of my reach.
  2. Is there a way to link a locally hosted ontology? Please note that I have already enabled CORS requests of local instance of Virtuoso.
  3. Is there a guide to OSDE (apart from the overview youtube video)?

Here is an example of an OSDE URL for retrieving an RDF document and displaying its content using the “Statements Viewer” UI:

https://linkeddata.uriburner.com/rdf-editor/#/editor?uri=https://kidehen5.solid.openlinksw.com:8444/profile/card&view=statements

If you are running your own OSDE instance, then of course it would work with CORS enabled. Even better, there is an OSDE Browser extension available from the Chrome Store.

Yes, see the OSDE Home Page.

I hope this helps.

Obviously, I miss something fundamental and therefore I cannot really translate your answer successfully to my setting. Using chrome plugin, I do not get a CORS error, but still I cannot import my ontology. Therefore, I will use chrome plugin to make things a little simpler but still they are not clear for me.

Let me rephrase my question setting and kindly insist on asking.

I have an ontology stored on a local virtuoso instance accessible on virtuoso_url:8890 (i.e. virtuoso_url:8890/conductor would be its administration interface and virtuoso_uri:8890/sparql would be the SPARQL endpoint). My ontology is stored on an RDF graph named graph_uri and the ontology’s base uri is base_uri. I can ask SPARQL queries on my ontology and get answers through the default HTML interface on virtuoso_uri:8890/sparql.

  1. What would be the URI I should add to the “Linked Vocabularies” section of the OSDE to import my ontology concepts and use it as a reference terminology?
  2. Since I can access my ontology through SPARQL endpoint (i.e. virtuoso_uri:8890/sparql), and ask SPARQL queries I suppose that I do not have to do anything else to “publish” my graph. Is this correct or do I have to do something?

PS. Thank you very much for your time. I really appreciate your help.

The issue here is that CORS needs to be enabled on the server on which the imported Ontology is deployed, from which it is retrieved.

OSDE is a Single-Page App (SPA) deployed using HTML, so the CORS sandbox in your browser takes control over HTTP requests that it issues.

A work around is as follows:

  1. Open the RDF document associated with Ontology
  2. Copy its content to your clipboard
  3. Use the “Direct Input” feature and paste in the content

If, on the other hand, you are simply trying to use terms from a remote Ontology for RDF creation in OSDE, we can take a look at adding the “Direct Input” or some override to the Vocabulary binding feature too.

/cc @hwilliams

Actually, “direct import” is not suitable for my use case as it would allow end-users to modify the reference ontology statements.

I would suggest adding a way to reference a locally hosted vocabulary (either hosted in a file or in virtuoso).

Should I add a github issue?

Thank you once more.

Okay, I suggest a new Github issue regarding the ability to import local ontologies using file: scheme URIs as a way to negate CORS issues afflicting some shared ontologies and vocabularies.

This is an enhancement to the Ontology/Vocabulary binding UI component.

/cc @hwilliams

I added a ticket in github as you suggested to be able to use locally hosted ontologies as linked vocabularies.

Is there a way to upload my ontology in a repository (perhaps a public repository, or
linkeddata uriburner ) and then use it as a “linked vocabulary” to reference its concepts?

We are looking into the CORS enablement issues on the URIBurner instance.

/cc @hwilliams