The scope of SHACL-UI

[tpluscode]

I would like to discuss the goals of this task force and what is the desired outcome. Having looked at the diagram shared on the kick-off call I got the impression that it may be trying to gather too many aspects as potential points of interest. By saying that, I do not mean priorities. Of course, we could not work on everything at once and on everything from the beginning. What I mean, is that I interpret it as going too much into defining implementation interfaces.

Some have already asked at that kick-off call about potential contention points around layouts, validation, sourcing shapes, etc. I would add actual interface for components and how they are loaded. Not to mention design choices specific to libraries such as react, vue, angular, or even other, non-JS stacks. And from my experience building shaperone I can expect many more issues which could be very hard to resolve in an universal manner.

---

Without elaborating yet, I propose that we focus on how the interfaces and behaviours are modeled in SHACL/DASH/#1 without mandating how implementors choose to realise them. Thus, a "spec" would be more like that of DASH or SHACL Advanced Features draft, where it provides common ground in how the shapes can be annotated to provide necessary hints for UI builders and describe the desired output in generic terms.

---

Bottom line, as stated by @bergos, a goal would be interoperability but I do not think we can realistically expect that on the implementation level. Instead, I would seek to document design patterns to allow building of useful UIs.

Here are some such challenges I faced when using Shaperone in projects

1. How to dynamically provide options for dropdowns/comboboxes?
2. How to annotate data which would be loaded dynamically in the UI?
3. How to define connected fields where selecting a value in one affects another?
4. How to select columns to display in a tabular UI, row per resource? (also mentioned by @VladimirAlexiev)

[danielbeeke]

I think the left side of the diagram is the vocabulary. I think the right side is the actual JavaScript interface.

Vocabulary things

I agree that we have to add things to the vocabulary side of things, we need a bit more than SHACL and the current state of DASH. I understand the first point in your list and I think that it needs a little bit of vocabulary work to specify the SPARQL endpoint for example.

JavaScript interface

On the other hand I think we can also create a JavaScript interface which would only use customEvent, customElements and the RDFjs data model in those events, to decouple the dash:Editors and the dash:Viewers from the library surrounding the implementation of the dash:Editor. That way the implementations of dash:Editors and dash:Viewers could be interoperable.

Deeper in the implementation of the editor widget a developer can use React or litHtml etc. But the outer layer would interact with the form layout system via customEvents and a customElement.

I think inside the interface we could specify how to the scoring algorithm is attached to an implementation of dash:Editor. I think if we would have those we would be pretty close to interoperability on the dash:SingleEditor's.

[danielbeeke]

De-referenceable dash:Editors

I also think we could have a third part to the whole spec and that is de-referenceable dash:Editors implementations:

sh:property [
  sh:path ex:dateSpan;
  sh:name "Date start and end"@en ;
  dash:editor <https://danielbeeke.nl/dash-editors/DateRangeEditor>
] ;

That way SHACL shapes are super portable.

This idea builds further on the JavaScript interface. Without that we can not have this. What do you think?

[tpluscode]

On the other hand I think we can also create a JavaScript interface which would only use customEvent, customElements [...]

I applaud that but I think it's an anti goal. Even in JS world, many implementors wishing to create form builders using a library like react, vue, or angular will not be stoked with the idea of using the standards. Unfortunate as it is.

and the RDFjs data model

And then there are non-JS settings, which not only cannot use webby standards as a common denominator, they will not represent triples with the RDF/JS spec either.

What we could do, is to define high-level, black box interaction patterns. In other words, describe what changes should happen in the underlying dataset whenever the user interacts with the form in specific ways.

I think inside the interface we could specify how to the scoring algorithm is attached to an implementation of dash:Editor

:+1:

I also think we could have a third part to the whole spec and that is de-referenceable dash:Editors implementations

Dereferencable editors will not play well with applications. This will cause performance issues stemming from many requests (no effective bundling possible) and likely CORS. I've been having similar issues with shapes being loaded dynamically. It quickly becomes a bottleneck

[danielbeeke]

Web standards & template renderers like Ract, Vue and others

I applaud that but I think it's an anti goal. Even in JS world, many implementors wishing to create form builders using a library like react, vue, or angular will not be stoked with the idea of using the standards. Unfortunate as it is.

I think the interface could be using web standards only, and on top of that interface (a JavaScript class that extends HTMLElement) anybody could implement a class that works nice with React, Vue or any other template renderer.

The same goes for all the other stuff that needs to be done, like traversing the SHACL property graph to get properties that your dash:Editor would depend on such as maxLength etc. That tool to traverse the graph could also be put into this layer that is on top of the interface.

I do not think we should define what libraries to use, only the fundamental building blocks such as the data model like Quad and possibly DatasetCore.

Web & native

And then there are non-JS settings, which not only cannot use webby standards as a common denominator, they will not represent triples with the RDF/JS spec either.

Personally I think it would be fine to scope this specification to ontology work (which would serve all programming languages) and JavaScript interfaces (more narrowed down).

Native application developers will have profit of the work on the ontologies and with the JavaScript interface we can do great web stuff.

De-referencable editors & performance / security

Dereferencable editors will not play well with applications. This will cause performance issues stemming from many requests (no effective bundling possible) and likely CORS. I've been having similar issues with shapes being loaded dynamically. It quickly becomes a bottleneck

Sure it might be a bit experimental. I do think there are some solutions possible.

No effective bundling possible

We could have an Editor / Viewer registry: A SHACL UI library could expose an registry where the developer could register editors by IRI. The editor itself could be given as a class imported from NPM. This would be the safe mode.. only widgets that are known beforehand.

However a second mode would be to try to resolve Editors whose IRI is not known to the registry (if this is allowed in the initialization of the form library).

and likely CORS

One way that might work would be to let the IRI be the JavaScript file. That might be one of the shortest routes, and it could be that the server needs to set CORS headers. I am not sure if this would be a big problem. GitHub pages for example has this by default.

The positive things about these shapes and de-referencable editors is that we would not need to have a big waterfall. It would be: fetch shape, fetch all editors. I think it can even be done async with loaders (and editor fallbacks by the scorer algorithms).

De-referenceable dash:Editors needs other things to happen first

Personally I think we can only start with de-referenceable dash:Editors if we have the first part (ontology work) and the second part (JavaScript Interface) in place.

[HolgerKnublauch]

On de-referencing, I would keep the dash:Editor instances as "normal" RDF resources, but their URIs may carry additional triples to link to implementations, even in multiple languages or frameworks.

[bergos]

Before we go into details, we should evaluate the interest of people participating in the Component Interface subgroup #7. The required data structures will be very similar in every framework. I favor Web Components, but it's also OK if we end up with one or more specifications to cover other frameworks.

[VladimirAlexiev]

@bergos and @HolgerKnublauch I hope I'm not too late with the following suggested features:

How to select columns to display in a tabular UI, row per resource? (also mentioned by @VladimirAlexiev)

• How to populate a row? Need some sort of instance template. Some RDF data (eg rdf:type) may need to be prepopulated, and eventually immutable
• How to ensure that a "last row" remains i.e. the user is not allowed to delete the last row, if the master-child relation is mandatory? Or in general, if it has "min cardinality = m", how to ensure that "m" rows remain?

How to specify "URL policies" for objects and sub-objects? Eg see https://platform.ontotext.com/semantic-objects/soml/objects.html#soml-objects-id-generation that has 3 such options.

How to specify subgraph templates, where the editor user sees only part of the subgraph? For example, in CIDOC CRM you have to express "date & place created" of a Museum Object like this:

<object> a crm:E22_Man-Made_Object;
  crm:P108i_was_produced_by <object/production>.
<object/production> a crm:E12_Production;
  crm:P7_took_place_at <place>;
  crm:P4_has_time-span <object/production/time-span>.
<object/production/time-span> a crm:E52_Time-Span;
  crm:P82a_begin_of_the_begin "EARLIEST"^^xsd:date;
  crm:P82b_end_of_the_end "LATEST""^^xsd:date.

• <object> is the root URL (replace "object" with a suitably generated URL), whereas the rest are sub-object URLs that append the given words to the root URL
• the user wants to see something like this:

  Production
  Place: <place searcher>
  Date: <earliest date control> (latest: <latest date control>)

• the <place searcher> selects a crm:E53_Place by some suitable selector
• if the user doesn't fill <latest date control> then copy the value from <earliest date control> to both date slots

How to ensure that no parasitic nodes are created? Eg in the example above:

• <object/production/time-span> should be "created" (i.e. crm:E52_Time-Span should be recorded) only if the user entered at least one of the two dates
• <object/production> should be "created" only if the user selected a place or entered at least one of the two dates
• This is to ensure that parasitic nodes without business payload are not created

What are suitable ways to select a related object? Eg

• dropdown (if only a few)
• auto-complete (search through all lang labels, show label in preferred lang, show suitable disambiguating description, eg Paris Texas vs Paris France)
• hierarchical (country> region> city)
• create related object on the fly

[tpluscode]

I hope I'm not too late with the following suggested features

@VladimirAlexiev you bring in some great questions and use cases. As far as I understood the issues labeled "scope", @bergos simply wanted to agree on a very broad definition of what this group will work on. In essence, that is the current contents on the readme

Regarding the more specific subject, we agreed that I would extract focused issues from this one here so that we can discuss in separation. Your comment could easily be broken up into a dozen such issues where we can talk detail and prioritise.

How does that work for you?