Should we reuse DASH namespace?
Opened this issue · 10 comments
On the kick-off call, the question was asked whether we should keep the DASH "brand" or come up with something else. Given that DASH is used by TQ for more than just building UIs, I do agree that we could start fresh
I have two proposals
- LUSH - Linked Data User Interfaces in SHACL
- BUILD - recursive for Build User Interfaces with Linked Data
The bikeshedding potential here is limitless. I don't believe the namespace needs to spell a real word, and it don't need to be a backronym.
My proposals:
- SHUI - SHACL User Interfaces (Short and sweet)
- SHACLUI - SHACL User Interfaces (Same as the working group title)
- SHADUI - SHACL Shape Driven User Interfaces
- DASDUI - Data Shape Driven User Interfaces
I liked SHUI too. Easy to remember and maybe infer what's that if you know GUI and TUI.
"Given that DASH is used ... for more than just building UIs" - There is a reason for that.
The best way to model information for the UI is IMHO to generalize it so that it can also be used by other tools. A good example is dash:singleLine which is both for validation (no line breaks) and the choice of UI component (TextField vs TextArea). The same applies to many other properties, constraint components and objects, e.g. the Property Roles. And even things like DASH Multi-Functions and DASH Templates can be used by UI code as well as other program logic. Clearly also dash:reifiableBy, which defines the layout of nested forms for RDF-star scenarios.
Another example (not in DASH yet) is an extended vocabulary to be used in conjunction with rdf:JSON, to point at the JSON schema of valid values. If these are JSON arrays, the UI can pick a completely different widget than for JSON objects (where it may construct a nested form). At the same time this info is for validation.
Therefore, are you guys sure that this namespace here will be limited to "UI" and should therefore contain "UI" in its name? Years ago I developed a TQ-internal extension of SPIN called UISPIN, which later turned out to be of general use for defining not just server-side HTML templates but also server-side web services.
I went with something as generic as possible, such as "Data Shapes" for this very reason.
I don't think it makes sense now to discuss the title of a specification. The proposed ontology subgroup #7 should collect topics, structure them, and then it's time to think about names and namespaces. I proposed abstract names for the subgroups to keep the final name for specifications open.
The point is not UI vs. not UI. The point is that current DASH namespace might contain many things specific to TQ that are presumably out of scope of the current taskforce. Hence I would also personally prefer to start fresh.
I agree with the approach that the ontology definition should not entirely be targeted at UI.
@HolgerKnublauch makes a good point about non-UI concepts. That said, IMO, nothing prevents the vocabulary to be called SHUI and still address aspects other than user interface strictly speaking.
@tfrancart yes, I too favor the fresh start approach. We will then get to choose what we keep from DASH fairly unchanged but also will be able to redesign what we need
Apologies if I misunderstood stuff but if I understand correctly, with the shacl-ui ontology the goal would be to create an ontology to be able to define UI elements?
Why do we not use the existing UI ontology for this goal? Do we know about the existence of it?
Okay, this ontology is used by Solid-UI, but the ontology itself does not contain any Solid specific parts and I feel like it does exactly what the goal of this shacl-ui is.
Why do we not use the existing UI ontology for this goal? Do we know about the existence of it?
I personally do
Apologies if I misunderstood stuff but if I understand correctly, with the shacl-ui ontology the goal would be to create an ontology to be able to define UI elements?
I don't quite think this is the goal. I think the goal here is to be able to associate UI elements with parts of the data model. I think the UI ontology can be used to describe the structure of a form in semantic terms (any form, be it tied to a semantic knowledge graph or not (?) ), while the goal of SHACL-UI would rather be to have the ability to have a model-driven form, directly from the description of the KG structure. It is rather extra annotations on the KG structure description to ease the generation of forms. Of course this will require to define identifiers for "widgets" (e.g. input fields, dropdowns, etc...) which could be mapped to UI ontology if this makes sense. Other than that I don't think other parts of the UI ontology are interesting in this work.
Certainly the relationship with UI ontology should be studied in scope of this project.
Please anyone correct, amend or repeal my answer.
I propose to close this as we more or less already settled on shui prefix
In the meeting on 2023-08-09 we decided:
The final namespace will be defined once the document is filled and we have a better idea of which name fits.
Let's keep this issue open but postpone further discussions.