Re: SHACL-based Instance Edit Forms?

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?


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 12:46:27 UTC