Re: SHACL-based Instance Edit Forms?

In case of a shape saying that a datatype is xsd:string or xsd:time, no additional info is needed for a “default” display. It is already clear that one obvious way to present it on a form is as a text field or a time clock.

We add widget info to a shape when something special is needed e.g., a password type of field that masks a password string as it is being entered. In the end, there is a software someplace that interprets information in the shapes. Widget info is simply a way to declaratively specify additional facts about a possible display. Similar to how the datatype suggests a possible display. Our software uses this info to render forms. Some other software could do it as well. It could also elect to ignore some of the shape information and/or figure some other approach for deciding how to present data. This is RDF, so anyone can say anything about anything - a shape could have statements associated with it that are not described in SHACL.

Besides, these are simply annotation properties that have no impact on the validation. There are actually several annotation property that are built into SHACL, but are optional - SHACL compliant processors don’t have to support them in any particular way, but they could.

> On Jun 1, 2017, at 6:43 AM, Florian Kleedorfer <florian.kleedorfer@austria.fm> wrote:
> 
> Thanks! Just to see this tutorial is encouraging - SHACL might be the right way to go for us!
> 
> However, I see the scenario described below as a distributed one: many different actors may be involved:
> * The ontology creator, who creates a Taxi ontology (for whatever reason) and publishes it.
> * The taxi service provider T1, who finds that the Taxi ontology useful and so writes SHACL shapes so as to be able to communicate their information requirements to potential clients, and publishes them.
> * The taxi service provider T2, who is happy to re-use the Taxi ontology and the shapes
> * The app/website the potential client uses to publish their need for a taxi, and say, orders one from T2
> * the app/website may be taxi-specific, in that case using the Taxi ontology and the shapes are hardcoded
> * the app/website may be more generic, in which case the ontology and shapes
>   * may be discovered at need creation time and used for creating the taxi need
>   * may only be discovered when the need object is connected to a taxi offer that uses the ontology and has shapes attached (or references them)
> * The app/website another person uses to offer taxi services as a freelancer - which might work in almost the same way as from the client's perspective, only that they need a way to discover, review, and accept the appropriate shapes for generating edit dialogs and for validating.
> 
> Thus, there is no centralized control. Your tutorial and your answer seem to point to the crucial problem: you seem to be extending shapes with view/edit/search widgets that can be used within your platform. In our scenario, the SHACL shape author cannot dictate how shapes (or the data they restrict) should be displayed or edited, and that seems to be the missing part.
> 
> Ontologies and shapes can be referenced, so remixing them from arbitrary sources is possible, but for distributed data interchange, we still need a form of generic user interface specification for displaying instances and instance input GUIs. Ideally, those can be commbined recursively and interchangeably (like html5 templates, if I understand them correctly), so that over time, a service can learn which data to show/edit with which widget combination, given a certain user, context, or type of data. If there is any such work going on, I'd be thrilled to know. If not: shouldn't somebody start it?
> 
> Cheers!
> Florian
> 
> Am 2017-06-01 11:08, schrieb Irene Polikoff:
>> We use SHACL to generate web forms. Not open source though, sorry.
>> You can take a look at this mini tutorial
>> http://www.topquadrant.com/2017/04/17/shacl-topbraid-web-products-evn-edg/
>> In the beginning it discusses using web ui to create shapes
>> themselves, but towards the end you will see a form for a Person
>> created based on a shape.
>> For the form widgets that are fancier than what can be simply based on
>> the sh:datatype value, we created an extension for shapes with
>> properties to indicate edit, view and search widgets. You will see
>> them in the Display section for a shape. Map could be a view widget.
>> Regards,
>> Irene Polikoff
>>> On May 31, 2017, at 12:15 PM, Florian Kleedorfer
>>> <florian.kleedorfer@austria.fm> wrote:
>>> Hi,
>>> I am considering using SHACL for a de-centralized conversation based
>>> cooperation infrastructure[1]:
>>> When two users want to engage in some kind of transaction that
>>> requires structured information (e.g. one wants to hail a taxi, the
>>> other user represents a taxi company), the one requiring structured
>>> information creates SHACL shapes (in the example, the taxi company
>>> has an API to order a taxi and needs either an address or
>>> geo-coordinates).
>>> Those shapes are added to an RDF-based channel both users can
>>> read/write. The other user can now use the shapes to determine which
>>> information is required and add the necessary triples. Ideally this
>>> is done transparently by that user's GUI, by generating appropriate
>>> components (in the example, a map and a text input field with
>>> appropriate labels).
>>> Doing research on this I found this email in the list:
>> https://lists.w3.org/Archives/Public/public-rdf-shapes/2014Aug/0094.html
>>> All aspects raised by Holger (selecting properties, proposing
>>> values, and determining cardinalities) are relevant to us, either
>>> for the use case described as well as for others.
>>> Does anyone happen to know if there are implementations of such GUIs
>>> underway, ideally open source JS-based, usable in the browser?
>>> Cheers,
>>> Florian
>>> Links:
>>> 1. http://researchstudio-sat.github.io/webofneeds/

Received on Thursday, 1 June 2017 11:39:02 UTC