Collaboration

[tpluscode]

Hi. I found your repo via your usage @tpluscode/rdf-ns-builders

It so happens that I have a near fully-featured SHACL form builder: https://forms.hypermedia.app

Would you be interested in joining efforts?

[vid]

Yes! I stumbled across shaperone recently and meant to follow up with regard to support for form validation and logical constraints. I'd be more than happy to collaborate if it meets goals. Maybe a chat? Let me know what works. Thanks.

[tpluscode]

Totally. We can join a call some time and see how much we align. I'm sure we can work something out :). Hit me on awesome@hypermedia.app

[vid]

@tpluscode , thanks for the discussion and follow up.

This shacl-poc repository is working on a subset of SHACL capabilities for limited use cases. For fully realizing the capabilities of SHACL we would look to transition to a project like shaperone. However, since the POC is very limited and specific, I am not certain we could use shaperone today.

I can't really evaluate all the nuance of SHACL and your implementation, so can't evaluate where our use case may not be supported. I understand there may be some ambiguity using logical constraints, as discussed in https://github.com/hypermedia-app/shaperone/issues/117, however for now, only using xone, it seems straightforward to allow the user to choose between the two and only use that in the data graph/validation.

Regarding displaying validation results inline, https://github.com/hypermedia-app/shaperone/issues/118, since we are using your library we may encounter this problem (the thought, without digging into the implementation, was blank nodes identifiers might provide a solution?).

Resources are really limited to develop the poc (and there are a few things to do outside the form). With a clear example addressing both requirements the poc can switch to your library, however otherwise the focus has to be conformant SHACL and a built for purpose library that can be switched out in the future.

We talked about some code to collaborate on this, maybe the shaperone playground can be used to try these features?

I hope this makes sense!

[tpluscode]

Certainly, the playground can be used to experiment within the limits of the implemented features. Additionally, any PR deploys a playground with its changes to try out. You can use it already to see the current extent of hypermedia-app/shaperone#117. As discussed in the related issue and PR, this will simply combine all properties to at least have a complete UI representing all the fields.

[...] only using xone, it seems straightforward to allow the user to choose between the two [...]

This may seem easy when there are only two fields, and if you start from an empty form. But when you add more properties to the alternative shapes or the data graph is nonconformant to begin with, you would easily end up with a rendering where some hidden properties generate validation errors, which would be confusing to the users.

Shaperone aims to be a generic tool, an I'm not yet confident in how these features would be implemented in a way to satisfy different use cases.

That said, the rendering can be customised to accommodate different choices in the actual rendered output. (I now realise that page is missing from the documentation, should work on that soon too)

[...] and only use that in the data graph/validation.

This is not how validation would work. You would not split the shape but rather pass it to a validation library along the data graph to get the report.

Resources are really limited to develop the poc [...]

It is up to you. I can offer my help in adding features to Shaperone and/or helping you build your custom extensions where necessary and I won't feel ready to introduce them to the core. Between the two of us, this might be a more efficient way to achieve your goal. And soon you would be capable of contributing yourself.

otherwise the focus has to be conformant SHACL

I'm a little lost here. "Conformant SHACL" as opposed to what?

Regarding displaying validation results inline

Regarding validation, the hard part is not really presenting errors but actually producing a useful report. The rdf-validate-shacl library we're currently using has limitations in the level of detail and effort would have to shift there.

In Shaperone, the implementation would be agnostic of how you perform validation and only follow the validation report spec to connect messages to fields and to the rendering.

[vid]

By "Conformant SHACL," I just meant to emphasize that we want it to be forward-compatible with other libraries.

I would like to use Shaperone (with Hydra) but given we have an April timeline, it's a limited project, and its requirements aren't currently a priority for Shaperone, will have to continue with our limited approach. I'm switching my focus to this dev later this week, will look for opportunities to contribute to Shaperone. Thank you very much for your patient explanations.

[tpluscode]

Well that's a shame, but hopefully you will reconsider at some point.

At any rate, all the features you need are definitely within scope for a future 1.0 of shaperone, even if we did not need them immediately in our project.

I have also started working on validation and here's a example of its current state, built from https://github.com/hypermedia-app/shaperone/pull/122

[vid]

The validation example looks great. In terms of UX, the main point that may be confusing is seeing both the count and type errors, the later of which is not very user friendly.

As for use of Shaperone, believe me, it's not a matter of considering, since it's clearly the better path, it's just a matter of current fit and the scope of the poc.

Taking it one step at a time, if Shaperone could present a simplified view for xone, we could think about working with it for the current development. I think for many situations xone will be the right choice, it certainly seems like the easiest to work with.

For example, if there is only one type of logical constraint, and it's xone, provide a tabbed interface for input and only include that value node in the graph. However, maybe a special case for "only uses xone" doesn't suit Shaperone as a general purpose library.

[tpluscode]

Surely, this is but a first attempt at displaying the errors. I will take any suggestions for improvement :)

The errors come from an external library. Maybe they could be customised or modified before displaying, at least by shortening the URL so that it at least becomes Value does not have datatype xsd:integer

a simplified view for xone

The core library should provide some more metadata about properties, including the logical constraint, if any.

That way a customisation would be easily made to the rendering, such as hiding or disabling the excluded alternatives. I'll be happy to provide an example

[vid]

Surely, this is but a first attempt at displaying the errors. I will take any suggestions for improvement :)

I realize that, in fact I saw it change between reloads. I think the approach of the error message inline rather than a disappearing tooltip is better.

I'll be happy to provide an example

That would be really helpful. In case it's not clear, everyone would much prefer to use Shaperone and help develop it (even if just on the edges).

[tpluscode]

In fact, the disappearing tooltip is html behaviour of native inputs. Proper design system would look better, I'm sure

[saumier]

Hi. This is a really interesting discussion :-) Looks like Shaperone is very close to being a perfect fit for our projects at Culture Creates.