Re: SHACL-based Instance Edit Forms?

Florian,

AtomGraph also provides create/edit mode. It is based on SPARQL, not SHACL
however. It is shown around 2:40 in this video:
https://www.youtube.com/watch?v=vHIRzEsm8ug

Contact me off-list if this is something of interest.


Martynas
atomgraph.com

On Thu, Jun 1, 2017 at 12:43 PM, 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-pro
>> ducts-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/
>>>
>>
>