- From: Florian Kleedorfer <florian.kleedorfer@austria.fm>
- Date: Thu, 01 Jun 2017 12:43:37 +0200
- To: Irene Polikoff <irene@topquadrant.com>
- Cc: public-rdf-shapes@w3.org
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 10:44:10 UTC