First draft of shui:readOnlyGraph

[robert-david]

• See this document rendered online here

[danielbeeke]

Looks good to me. I think in the further conversation about it we can talk about conformance. For now I think it is okay.

[smessie]

I had hoped to see this discussion in an issue first, but I can still share my thoughts in this PR.

My primary concern, or rather question, is why we need this feature.
Currently, I understand that we have all the necessary inputs (such as data graphs, shapes graphs, scoring graphs, etc.) as parameters on a software level.
Supporting a read-only graph in the SHACL UI would simply mean adding another input parameter that is a read-only graph.

Could you please clarify the purpose of this additional global configuration parameter?

[danielbeeke]

its a good question.

I think there are at least the following alternatives:

• Add an argument "Read only graphs" to various interfaces that required a list of IRIs such that when quads are handled implementers can check if the quad in question is part of a read only graph
• Add an argument "Read only graphs" to various interfaces that required a list of Graphs (similar to data graph and shapes graph, implementations could use rdfjs store etc.) such that these specific graphs can be only used when we for example are doing autocomplete search.

[edmondchuc]

I am in favour of a read-only graph for the following use cases, some of which have already been mentioned by @robert-david and @danielbeeke in this PR.

A read-only graph would allow applications to use non-editable triples as contextual information, whether that's for autocomplete search, facts produced by reasoning, or contextual information that the user has the permission to read but not edit.

However, I also agree with you, @smessie, that this should probably be another input parameter to the SHACL Renderer rather than a global configuration parameter.

[bergos]

We're overcomplicating this. We should simply define the property and allow each implementation to decide how it's used.

[robert-david]

I had hoped to see this discussion in an issue first, but I can still share my thoughts in this PR.

My primary concern, or rather question, is why we need this feature. Currently, I understand that we have all the necessary inputs (such as data graphs, shapes graphs, scoring graphs, etc.) as parameters on a software level. Supporting a read-only graph in the SHACL UI would simply mean adding another input parameter that is a read-only graph.

Could you please clarify the purpose of this additional global configuration parameter?

Sorry for not opening an issue first. Is was mixed up with #869. I created #1197 for this now.

The reason for the readonly-graph is to have a configuration to point out read-only data to the UI. Given that SHACL only defines a data graph, i think we should specify how such read-only data can be communicated to SHACL UI to keep it uneditable, i.e. manage such data accordingly. The main use case is inferred data, since SHACL defines to be compatible with reasoning, such as defined by the OWL profiles.

[danielbeeke]

Did I understood correct that we intent to make it an input argument: readOnlyGraph, containing all the triples that are read-only? I had the impression in the meeting we converged on that. The current PR is about configuration. Maybe I misunderstood.

[danielbeeke]

Robert and I had a call, I now understand that resolving part is outside of the specification, similar to how that is for a SHACL validation engine, it does not specify how the triples arrive in the data graph.

This changes my perspective.
I am fine with the current state, I still have a slight preference to make the readOnlyGraph an argument to SHACL renderer, but both are fine with me. I also have a use case for this functionality.

[edmondchuc]

It's still not clear to me what we gain by defining this as part of the global configuration rather than as an input to the SHACL Renderer.

The SHACL UI specification already describes the renderer in terms of graph inputs:

A SHACL Renderer operates on a data graph and a shapes graph, and may also take a focus node and a node shape.

Conceptually, it seems to me that a read-only graph fits more naturally alongside those inputs: an additional graph input that identifies the triples the renderer should treat as read-only.

I'm also not clear on why shui:readOnlyGraph is represented as a SHACL list of graph IRIs. That seems to introduce an assumption that the application has some mechanism for interpreting those IRIs as graphs, for example, as references to named graphs in an RDF dataset.

I think it would be cleaner for the specification to define the read-only graph as a conceptual input to the SHACL Renderer, independently of how an application stores, identifies, or constructs that graph.

This is similar to the abstraction used for the data graph in SHACL Core.

A data graph is one of the inputs to the SHACL processor for validation. SHACL processors treat it as a general RDF graph and makes no assumption about its nature. For example, it can be an in-memory graph or a named graph from an RDF dataset or a SPARQL endpoint.

I think the same principle would be useful here. An application could construct the conceptual read-only graph from one or more concrete graphs or other sources without exposing that implementation detail to the renderer.

If we also want an RDF configuration mechanism for applications that identify read-only data using graph IRIs, shui:readOnlyGraph could perhaps be defined separately as one way of identifying the sources used to construct the read-only graph input. That would keep the abstract renderer interface independent of the application's storage model. In that case, the mechanism defined in this PR would still be useful, but its role would be to help construct the renderer input rather than to define the renderer interface itself.