Figure out a way we might front our triplestore

[amoeba]

To integrate linked open data into existing web views and services, we likely don't want to expose, say, a SPARQL endpoint. If we did, we might at least want to point it at a read replica.

Another approach would be to put something in front of the SPARQL endpoint to constrain the types of queries that can be constructed by users without direct access to the SPARQL endpoint. There must be some solutions already out there, though I think building something specific to our use case isn't out of scope.

One example is https://github.com/UKGovLD/linked-data-api/blob/wiki/Specification.md

[amoeba]

I built something that serves at least my needs for now: A basic web app that can return linked data about a given DataONE PID. I don't have anywhere to host it at the moment but it lives alongside our other deployment configs in https://github.com/DataONEorg/slinky/tree/feature_update_graph_pattern/deploy/docker/web.

[amoeba]

Related, we might expose http://yasgui.triply.cc/ instead of the Virtuoso interface.

[ThomasThelen]

After the Jan 13th salmantics call we decided on something akin to geolink with rdfsurveyor and yasgui. I'm currently refactoring the code linked above in the feature_update_graph_pattern branch to link to the various components of Slinky. Virtuoso will direct the user to either the main virtuoso landing page or to the sparql endpoint.
Browse will direct the user to the rdfsurveyor page.
Home is the application root which will live at the slinky root (ie https://api.test.dataone.org/slinky)

I'm going to include a few yasqui queries on the main landing page, shown below. The changes so far include utilizing the starlette templating engine, css files and, integration with docker-compose & kubernetes.

[ThomasThelen]

The code from the comment above was merged in #68 and has since been deployed on the development server. It's not a particularly warming interface, but might be enough to close this issue.

[amoeba]

Thanks @ThomasThelen, this improves things.

We still need to come up with a high-level API for DataONE services to rely on. Two examples of high level APIs are:

1. A linked data service that would be responsible for our DataONE PURIs (e.g., https://dataone.org/datasets/foo). This would deal with content negotiation and do things like redirections or return linked data as response bodies when appropriate.
2. A lookup service for dataset landing pages that would take a dataset ID and a free-text person/organization description, i.e., lookup(dataset_id, name) -> ["https://dataone.org/person/bar"].

Maybe (1) and (2) are the list of high level APIs we want right now and we just need to document and implement those in the slinky webapp.