Re: SHACL-based Instance Edit Forms?

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 
    * 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 
* 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 

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?


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
> 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
>> <> 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:
>> 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.

Received on Thursday, 1 June 2017 10:44:10 UTC