ISSUE-172 Update YASGUI to Triply.cc version

[lewismc]

Hi @carueda this PR makes a start at the upgrade. It looks pretty good. It's been interesting learning more about the YASGUI and associated API's. Loads of interesting things we can do here. Also, I hope that whatever we do here, we can re-use when we decide to implement the new GUI.

As you can see, I'm going to add multiple tabs which will provide example SPARQL queries to the user. I still have some work to do but you will get the idea.

Do you know how to get around the CORS issue with regards to executing the query against COR?

[carueda]

Do you know how to get around the CORS issue with regards to executing the query against COR?

Can you elaborate? Traditionally the setup of the agraph proxypass in the MMI instance but I'm pretty sure also in the COR, has included CORS enabling AFAICR. Maybe it's not actually working in COR? If you are testing things locally can you retry against MMI ORR sparql endpoint as a way of quick verification?

[lewismc]

Can you elaborate?

Yes see screenshot below. I'm experiencing this when running on this branch and executing gulp try_dist --localConfig --base=/orrportal/ then navigating to the http://localhost:9001/orrportal/sparql/

[carueda]

@lewismc I figured this out -- It is a YASQUI issue, which I now remember I mentioned to you a while ago:

YASGUI stores a bunch of stuff in local storage (which is not necessarily bad per se), but some of the saved settings start to take precedence over others, in particular the desired SPARQL endpoint!!!

Look at this while reproducing the error:

As shown at the top, the configured endpoint is http://cor.esipfed.org/sparql. However, as shown in the console, the error refers to https://mmisw.org/sparql !!

Look at the local storage:

I've highlighted in yellow entries still referring to https://mmisw.org/sparql (surely from previous local testing against MMI, which might be also your case), and with green some other entries having http://cor.esipfed.org/sparql.

So, kind of messy IMO.

I should probably have reported this long ago to YASGUI but it seems I didn't have the time (want to go ahead?).

The workaround is "simply" to remove the YASGUI entries from local storage (well, at least the ones referring to endpoints).

I just did that and the query against COR completes just fine:

[carueda]

LGTM, keeping in mind the eventual need for the mentioned workaround when doing local development and assuming you are succesffuly doing such local testing as well with the new triply version (which I haven't tried btw).

Thanks @lewismc for your work!

[lewismc]

Thanks for the review here @carueda I would like to cover this at the next COR meeting... why? Because I would like to pre-populate some tab's with example queries. I would like to think about how we do that in a 'generic' manner which could benefit all ORR deployments.

[carueda]

@lewismc Just tried your branch:

Using http://cor.esipfed.org/sparql as sparql endpoint in my local.config.js and running with gulp try_dist --localConfig --base=/orrportal/ this is failing:

Since COR SPARQL's endpoint is both up and CORS-enabled(*), then it seems like the parameter is not being properly passed to yasgui?

---

(*) I reverified this by running the same sequence after checking out current master: