Meeting notes 2023 05 24

Kick off meeting, SHACL UI task force

Wednesday 24 May 2023 10:00 UTC

Introductions

Thanks everyone for joining.

I knew there's some interest in the topic. I didn't expect so many people. I'm happy about that.

Let's have a quick introduction round.

Thomas Bergwinkl
RDF/JS specs, RDF-ext, will join TopQuadrant in July

Aaron Bartholomew
Works with MediaWorks and Daniel

Ashley Sommer
Creator and maintainer of PySHACL, interested in the SHACL community

Charles Munat, New Zealand
Webdeveloper, ontologies, software architecture, teaching

Daniel Beeke, Austria
Christian ministry MediaWorks, works on a media catalog / CMS based on SHACL that publishes little web apps. Creator of rdf-form

Edmond Chuc, Australia
Software developer, Working at Kurrawong AI. Working with government that does read-write linked data Interested in this group

Holger Knublauch
Programmer at Top Quadrant, creator of SHACL and DASH specs

Ieben Smessaert
Master thesis student at Ghent university Solid decentralized web forms Will start PHD about this

Jesse Wright
Academic and developer, creator of Schimatos, works on Solid at Inrupt, Ghent and Oxford. Works on decentralized reasoning and query planning

Marco Neumann
Information scientist, Lotico community Has been wih SHACL from the start

Maxine Jakubowski
Belgium, UHasselt https://www.mjakubowski.info/ PhD about SHACL

Nils Preuss
PhD candidate in mechanical engineering in Germany. Scientific metadata with SHACL and RDF

Peter Hristov
IT Center of the RWTH in Aachen. Works on Coastline a platform for research data management. Uses RDF and SHACL

Steve Ray
Freelance standards, Information standards in the building management sector, made with SHACL.

Thomas Francart
France I'm a freelance ontologies and knowledge graph engineer. Uses semantic web technologies for 20 years Interested in SHACL and Query builder and UI Creator of https://sparnatural.eu/

Tomek Pluskiewicz
Poland, Works at Zazuku. Has been using SHACL a lot for forms, validation, queries and UIs. Notes that SHACL is an excelent spec for those use cases.

Vladimir Alexiev
Works at Ontotext in Bulgaria. Chief Data Architect, research and commercial projects in various domains. Architecture and construction industry of data manufacturing, transport and logistics. GraqhQL, SHEX and SHACL

Silas Jokel, Germany
Webdeveloper with Elevait, Works with RDF and SHACL UIs, forms and tables from SHACL

Benedikt Heinrichs
RWTH in Aachen Works on AIMS, SHACL profiles

Andy Seaborne
Telecent, an event driven data mesh On top of that rapid development applications Interest in SHACL as source of good UIs

Thomas: Points to the Etherpad: https://etherpad.wikimedia.org/p/shacl-driven-uis

I prefilled it and there's a rough agenda. You can put anything in there. It saves work if we do it together.

I think we have people from Australia to the West Coast. Finding a time slot which works for everyone is hard. So decisions can be made outside of the call. Because there are people who are unable to participate in this kick off call.

This kickoff call is to find a scope of what we want to do with the group. I thought it's good to ask Holger to, who knows the topic the best, give us a brief introduction to SHACL and DASH.

After that we will discuss on which levels we will work and what kind of specification we will make. Please add your Gitbub account to the Etherpad and add that you are present.

Introduction to SHACL by Holger

Holger: Thanks for the invite and introduction, Thomas. [Holger shares his screen] It's great to be talking about this topic and it's hopefully a start of a successful project for all of us. When SHACL was defined by the working group, the official task was to define a validation standard. Basically, only a way to define constraints and shapes. There was also, for many people, including myself, a strong desire to use SHACL for other things and include things that can be used to drive user interfaces right into the standard from the beginning.

When you're using a validation language for validating input forms, it also makes sense to try to use the same mechanisms and the same vocabulary and possibly the same shapes to also attach other information that may be useful for for driving user interfaces. For example, the arrangement of things on the screen. Let me show a couple of examples here. This is our tool to Topbraid EDG. I'm displaying a taxonomy. A simple geography example here with continents and countries. Each of those notes here on the left is an instance of a class. This is a country instance here, for example. And then when you navigate to one instance, you see what we call a form display. It is consisting of groups, property groups. Here is a list of properties that are under the label of label and description. And then there are geopolitical characteristics, hierarchical relationships, matching relationships, etc. All of that domain specific, depending on what instance you're looking at, the form will display different things. I'm showing this as one example of what you can do with SHACL, obviously there are many other ways of rendering this information. This is just to show something. We display property groups and for the each property group, we show the properties and then all the individual values of the triples that are attached to this instance. We show all these triples with suitable viewers. So, we call those things viewers. And there are also editors. Viewers are used when you have something like a literal, in this case here, the literal "Iceland"@en in the English language tag. The system automatically picks a suitable viewer based on the data type of that literal. And in this case, it's fairly obvious to display just the label and then in parentheses the language tag. If something is a resource, we render it like a link to the class, we display it as a hyperlink and with the label of the target resource. For most of that information it is already straight forward to derive it from the model. The SHACL standard includes things like data type constraints and class constraints. But it also contains includes some non-constraint properties. Things like sh:name and sh:description. Here I'm showing (the SHACL specification)[https://www.w3.org/TR/shacl/]. So, this is where we had a bit of controversy in the working group, whether they should be included or not, because they are not strictly about validation, but we ended up adding them.

Many of you may know about these properties. Things like the sh:name and sh:description, they are basically used to define suitable display names for properties on the forms. This would be the thing that you typically see next to the property value. The name and the description can also be used, as a tooltip text, when you navigate over a property name. And then there is sh:order and sh:group. These are there to arrange things on the screen and to define the layout.

When I navigate to a class definition, or just a shape. For example this class Country. We are presented with an ontology editing mode, inside Topbraid EDG. We have a class tree here, showing the inheritance: country, the subclass of Geoconcept, which is a spatial thing. It's also subclass of skos:Concept for those who know skos. And here we display the property groups and the properties that are included in them. And here you see the equivalent that I had for each instance. So, the property groups themselves have an index or so called order, sh:order, which defines how they are displayed from top to bottom. Obviously, the default value for, if no order is given, is zero. You can rearrange them and then you can drag and drop property definitions into those groups.

And those correspond to triples here in the model. So, if you look at the source code of this SHACL shape, which is also a class, it defines various properties and then it inherits other properties from the super class. In this case Geoconcept, which defines many of those properties here.

And then the property shapes. Some of them have a pointer to the property group and also an order. The language belongs to the group geopolitical characteristics. And ordering is stored here using a decimal number. We choose decimal as a way for people to insert numbers in between other numbers later down the road. So, this is all built into the default SHACL standard. Now, given that this is an RDF based language, it allows other people to define additional properties. And we have been using that quite heavily so that people can attach other information to property shapes.

Introduction to DASH by Holger

And this is where the so-called DASH standard comes in. You can find that it's all basically open source. So, there's no strings attached if you want to use that vocabulary. It's a Apache license. So, you can just go to datashapes.org and there is one document in particular that is relevant here for this. (It's about form generation.)[https://datashapes.org/forms.html] And this in particular defines all these widgets and I'm going to show them in a second. But if you want to, if you haven't seen that document, it is explaining a little bit what I've shown with examples.

Speaking about those forms, the forms come in two modes in my application or in our product here. They are either in view modes or they are in edit mode. So, you can switch to editing. And then the system is rendering edit widgets for all those values that exist and has the ability to add new values as you would expect. You can add other labels and so on. And again, the choice of widgets that are displayed here depends on the shapes. So, for example, here, the ontology defines that a preferred label can also be RDF language string values. Therefore, we display a text input field together with the language selection field. So, that's again all model driven.

If you want to change that display to something else, from the default view of images here, which is just the URL to an image display widget. You can use dash:viewer and attach another property to this property shape here. At the property shape now, you can see that there are additional input fields here for viewer and editor. And these are two properties called dash:viewer and dash:editor. You get a choice of widgets that we have defined and that we have found to be useful. But keep in mind, this is RDF. Anyone can add other instances here. Anyone can define their own additional widgets that are not in the list. Obviously here for flags, you want to use an image viewer. So, when I apply this change, then when I next time go to to the same instance here in my taxonomy, it's now using the image viewer instead of the showing the URL. Similar, the property editor can be used to switch to different editing components. Examples of that include things like the choice between text area editor and text field editor. So, whether you're single line editor or multi line editor or a rich text editor, if you want to do text formatting as well. Date picker, and so on. In most cases, these can be shows automatically simply by looking at the ontology, simply by looking at whether it's a date property. Or any oher data type. And obviously you would pick something like a date time picker or a date picker widget. But in some cases, you still may want to override that and then configure a different widget.

The DASH specification contains all those widgets that I'm speaking about, they are defined in text form in the spec. We have the image viewer (here)[https://datashapes.org/forms.html#ImageViewer]. So, this is a very minimal definition. But basically it defines roughly what each of those components is supposed to do. It has a score function and a rendering description. The rendering basically just says here in prose, just says it should show the image of given URL using an IMG tag in HTML. That would be one example, hopefully, understandable for most people. Obviously, this in a future version (of DASH or SHACL or what the group defines), this could be formalized further. We could potentially even define a web component for each of those things if we want to move in this direction. So, in addition to that, most of those viewers and editor components have a score function. The score function is a description of an algorithm that returns a number between 0 and 100. If a score is 0, this means the component is not suitable for a property. If a score is bigger than that, then the widget with the highest score basically gets chosen when the user interfaces is rendered. In this case, here example, the score should be 50 for IRI, all literal notes, that have an image ending such as PNG, JPEG, SVG. So, this is a bit of an algorithm that would help the user interface to pick those components. Obviously, again, the score function here, if we want to go this way, if this inspires somebody, we could formalize this into, let's say JavaScript against some API like the JavaScript API from your group.

I've come up with this catalog of widgets here that we found useful in practice. I've included screenshots and examples. In our program, we have a few more of those that are not listed here because they are too specific for our application, but the framework allows them to be defined. And each of those basically here is basically defined as an RDF instance as well. So there is a class called dash:Editor. And then the details editor is just an instance of that. In the interest of time, I don't want to spend too much longer. There is, I would say, the desire of all that to be as model driven as possible. Having explicitly specified widgets like editors and viewers should be the last resort. I believe most of the information should really be coming from the model because then this information can also be used by other applications. An example of that is SHACL does not have a constraint to specify that strings must be single line values. And there are plenty of examples where it must be one line, for example, most labels display labels are just single lines. It typically don't include line breaks. So, attaching (dash:singleLine)[https://datashapes.org/constraints.html#SingleLineConstraintComponent] property to, let's say the label property shape definition, would help a system to automatically select the text field widget instead of a text area, basically disallowing multi line edits.

And I think there is potential for defining more of those things because the single line property can then also be used for constraint checking, which makes it much more widely applicable.

Okay, the last very last thing I'm showing, there is one other part of the dash namespace that may be interesting here.

Introduction to DASH property roles by Holger

That we found useful is a little vocabulary called (the property roles vocabulary)[https://datashapes.org/propertyroles.html] and this defines a couple of so called roles that can be used for annotating property shapes. For example, you can use (the icon role)[https://datashapes.org/propertyroles.html#IconRole] to specify that a certain property shall be used as the icon for when a resource gets rendered, let's say in a tree or a graph component. We have the Description role, and the label role. The label role obviously should be for rdfs:label and so on. Description can be used as a short summary. So basically these are annotations that you can put on property shapes to produce other types of useful renderings and I'll just show the examples of that.

So if I go to Europe and I want to get more information about the countries here, the system shows this tooltip text here. That's another way of rendering in addition to the form. So this tooltip text is informed by those property roles. It knows what the label is, how to derive the display label that you see on top and then it shows the icon here, which is the flag. And then it shows also some key properties like the ISO alpha code and if it had a description it would show that. So this information is also again attached to the model.

So with this, I'll better turn back to Thomas and of course I'm always happy to discuss and answer questions of this. Thank you very much.

Setting a clear goal for the group

[Thomas] There are some questions in the chat. I would say, we don't want to dive too much into technical details right now.

The important part is that we figure out now what we actually want. If we have a common understanding and so on. With the people I talked to, DASH was always a reference. It is now of interest to all and see if we agree on that. Or if some disagree we have to find another level of agreement.

I prepared an (abstract diagram)[https://docs.google.com/drawings/d/1dPtZZw8uFnoulsl1lHUd-HxgDYuF_NYKORlaUkMPo1c/edit] of how I see the direction the group could take.

What we in general are talking about is having reusable components and then we have the part describing the component, like that is what DASH is focused on. Which component to choose and so on. You have a shape, you have some logic which controls which component to load and then you have the component itself that then takes care of converting from the UI input output to to or from RDF.

I would like to hear from you:

• Do you see DASH is exactly what you want?
• Are there some details that are missing DASH?
• Can we say DASH is a starting point and we would modify DASH to make it work.
• I see this as the best option as most people I have talked to are using DASH.

If nobody said anything then I would simply propose it.

[Maxime] I am totally new to these kinds things, but would't the data controller also want to validate the input and so it would need the shapes as well? Just a basic question.

[Thomas] We have to figure out who wants to do what with it. So about the data controller and the data graph. Some people will say I want to do everything in the frontend. And other people may say I send this data to a WebSocket and let the backend do the validation. So some people might have those parts closely together and others would have these more separate.

The question is now: do we need to specify it? This is what I mean with the levels. Do we want to specify if there is some kind of valdiation or not?

[Maxime] I think my question is about specification and it is: do you specify as well that the shape that you used to generate the form is also the shape of the data that you used to validate when it is saved somehow?

Is that something that you want to incorporate in this?

[Thomas] I think that most people will agree that the shape also will be used for validation. How active you want to do the validation is an other topic.

If we specify it then technically where do we specify it? Do we specify it on the component, in the controller component and do specify the controller component and all the communication it has with front and backend and so on.

GrapQL was mentioned here, I explicitly left it out, I am pretty sure some people want to do it, also more than one person. But I am not sure if everyone wants to do that.

I am not sure if we need to define it right now.

It's maybe that we find the rough structure and then we make proposal of what we put in there and and then we can maybe even handle this with issues or later calls.

Some people might want to use JavaScript other might want to not use JavaScript. I think broadly it is about defining the interfaces that are used for the components. Like callback functions, data structures of the object you handle, the value itself and on the left part is 'the how'. How do you build the components together, that is very abstract. That is more about DASH and the ontology. That part is very abstract, that is not connected to JavaScript at all.

If you do things in the browser we can define things like an image tag, but I think we can even define it in an abstract way.

[Daniel] I wonder if the layout and components definitions spec should be the main focus because you also have the Hydra draft spec and there are some other initiatives. One is the FNO by imec — Ghent University — IDLab. They try to define how to handle the data.

So from my perspective, my advice would be to focus solely on the left side of this.

[Added note from Daniel] I misunderstood the diagram. I want to focus on both left and right sides of the diagram. I was thinking we were going in to the area of Hydra and other ways of handling the data. The phase before and after the form.

[Thomas] The thing is what I always heard is: we want to reuse the components. If you want to go that direction, then you need to define an interface for this components.

But if it is a topic or not, we have to say we have to say which direction we want.

If you want to have: that you can use one JavaScript implementation or the other, then we need to define that interface. And then we need the right part.

I mentioned earlier that there are people who could not join because of the timezones. The idea would be we can split it to the left and the right part. People might be interested in the left and / or the right. But splitting it up is maybe easier for organizing this so that everybody on the whole world can participate.

[Daniel]

Okay, that was my idea how I understood the two green parts and maybe I'm understanding it wrong so please clarify. So on the left side I would understand that these would change triples because there would be an input but they would not write it back into a back end or into a data store or something like that. And on the right side the data controller would be doing just that. Is that correct? Is that the separation that you want?

[Thomas] No, the right side is the component itself, the actual implementation. (which needs an interface) on the left is what Holger also showed the ontology / DASH. Those components which are very abstract. Like a dash:textEditor, a dash:multiLineEditor and abstract stuff like that.

And then you connect it to the JavaScript, which is the right part. A web component or whatever. And that would be the right part. So the left part is that you just define them the model and the right part is then the actual implementation and handling the data. So that you change something and then it changes a data graph.

That data graph I left it out because I'm not sure if everyone wants to handle it on the front end maybe someone to do it somebody wanted to back end. Yeah, but this is also not the important. It's just the rough structure that should come to agree on.

[Thomas P] So I'd like to ask two questions. The first one.

Are we focusing on just the form? As in I found that building unlike what we see in Topbraid, I found that the shape you want to use for forms might be very different from shape that you use to define a view.

Dash viewers and editors exist in the same spec but you just may want to structure your view and you editor form slightly different.

It's not like you can just switch on any single field from anything going to editing and I mean it makes a little bit of a very generic UI. Not really bespoke.

And the second question about the proposal that you share already.

Have you considered looking at what people actually do? I mean I'm sure there's many ideas and many solutions to problems you know that are hidden behind a simple diagram.

So rather than starting again from scratch maybe we can first review what what already exists.

[Thomas] So the last but was like this diagram or like starting from scratch whether it's using the existing stuff or did I get this correct?

[Thomas P] Yes maybe to reprase or ask an alternative question. It's the goal to create an implementation based on on the architecture as proposed?

[Thomas] That is something we can figure out. I'm not sure if everyone wants to go in the same direction.

I would start on a basics level where I'm pretty sure we can all agree on. And then where you load the data from like Hydra, Solid or maybe someone loads the shapes in a different way. That would not be part of the spec.

Also like I just get a reminder that we have 10 more minutes. I want to have a rough structure and then we say okay we can maybe start creating a repository where we continue this issues and maybe all the organizing as a little bit more than in detail. I don't want to get lost in technical stuff now.

But if there's something we can agree on. A data model, whether we have the component interfaces. I think that is something we have to define. I think DASH does the left part already almost completely. There are for sure some gaps but that would be for me the starting point and the right part is something which I think is completely missing.

Can we agree on a name for the left thing? Do we continue with DASH? Maybe DASH version 1? Holger what do you think about this.

[Holger] If people are interested in reusing this namespace, it's already used in a couple of implementations that I know about so for sure it's available for that.

We have other things in that namespace as well, which don't really fit here, so one idea would be to reuse what what you guys want to reuse. Put that in a separate document, separate turtle file which then gets maintained by the group and I copy the stuff that that we need back into the product code here on my side so that we focus on on what is relevant here for form editing and viewing and stuff.

[Thomas]

So you are fine with that we also use just now is a working title or maybe the final title you say the left part is dash that is okay for you?

[Holger] Yeah I mean in general the goal of why I came up with the dash namespace was to to fill or potentially prepare for future versions of SHACL things that we didn't have time for in the working group because the working group was very very time limited at the end and it was too controversial. To get any of that done so it didn't have even obvious things that that later we found to be useful so that was basically the idea of having this as a starting point later it could be moved into the SHACL namespace itself once it's stable enough but for now yeah that's one idea of course we can also name a different namespace. If that keeps more people happy. I have no strong opinion.

[Thomas Francart] Yeah just want you to react on that last sentence isn't it a problem if the dash namespace also includes stuff that is not related to SHACL driven UI?

[Thomas] I really just want to have a basic structure for the group. So what do we call the left structure? DASH?

Does somebody have a good title for the right part? DASH components interfaces?

[Daniel] So basically we're naming something like dash viewers and dash editors into one thing? If I understand things correctly it would be a bit about how do you integrate those who how does such a widget get its data how does it manipulate it how does it write back, correct?

[Thomas] It would be about how if you want to use the interfaces. Dash viewers and editors yes.

[Daniel] Yes I think the proposal of Bene is interesting: DASH component interfaces.

[Thomas] Okay I will create a repository in the RDF/JS organisation. I simply call it maybe SHACL UI. That would be abstract enough that everyone is happy with it okay.

Then what I would do is then create this repository maybe create some basic tags structure. Together with Daniel will get the minutes done. And put it in the wiki.

I will also prepare some open questions also for the mailing lists.

Maybe we can manage to split it up already and then have separate meetings. We need to find out how to work in this group.

Lets see if this requires having a another call or we can agree on use the tools.

[Andy] I wouldn't dismiss some of the more basic stuff and working towards experts presenting the work outside. I think it's quite important to do something like get written mission statement so that it becomes actually quite clear what is what is going to be covered.

If you can go for so long with a sort of fairly open thing and see how it converges but for introducing people who are outside of the group or people might be just you know even observing or wanting to join kind of giving some sense so what is in and importantly, what is not in.

I think it helps if someone wants to move towards drafting mission statement. (I could not understand a little part here)

Vladimir mentioned Xforms there have been other attempts of things in the past. So just doing the basics of getting everybody up in the community to be working on one thing.

[Thomas] Okay thanks for the hint. This is what was the scope of what I wanted to discuss. We will write this down and then we add maybe tags for issues that everyone can work on.

Bringing what we have discussed now and then allow others to to say something.

I will push it to the repository and announce everything on the mailing list. The gitter chat will be followed. Discord is also followed but Gitter is preferred.

Thank you everyone!

[Holger] Thanks for organizing this Thomas.