Re: SHACL-based Instance Edit Forms?

On 1/06/2017 22:45, Florian Kleedorfer wrote:
> I think I understand. Now the issue I see is cooperation between 
> different actors in creating a GUI for a speicific user in a specific 
> situation. So far, we've established that a service can make decisions 
> on how to render data and shapes. It can take annotations on the 
> shapes (or on the data) into account. So, the author of the instance, 
> of the ontology, of the shape, and the author of the GUI take part in 
> those rendering decisions.
>
> Such a system can handle unforseen use cases only with default 
> widgets, and in order to cater to an unfreseen use case, at least one 
> of these roles has to become active and make adaptations - but those 
> actors actually don't see the system in action. The users do.
>
> If we stick with the taxi use case, let's say the taxi is ordered and 
> the driver (or her service provider) adds triples indicating the 
> expected arrival time and updates its location every 10s. Normally a 
> date/time display would be appropriate for xsd:time, and a map widget 
> to display the taxi location. In this case, however, it would probably 
> be better to display a countdown widget toward the time of arrival 
> because that's the information the user actually requires.
>
> Now as I imagine this, when this use case first takes place, the 
> default display and edit widgets are used. But then, a tech-savvy user 
> realizes that a countdown would be better suited for this situation. 
> She creates a countdown widget, publishes it according to some (now 
> inexistent) W3C recommendation, and in subequent cases client GUIs 
> choose this widget over the default, until someone else publishes a 
> widget that combines countdown, distance and map in a nice way.
>
> Anyone else interested in enabling this?
> What is missing for us to get there?

I agree it would be great if some (open source?) project would define 
URIs for specific UI widgets or similar clues that clients can use. A 
password field is a good example.

There are plenty of interesting research projects possible around SHACL.

Holger



>
>
> Am 2017-06-01 13:38, schrieb Irene Polikoff:
>> 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.
>
> Just to be sure, you are talking about Non-Validating Property Shape 
> Characteristics[1] here, right?
>
>
> 1. https://www.w3.org/TR/shacl/#nonValidation
>
>>
>>> 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 22:33:20 UTC