Re: UI/UX snippets

For what it's worth, I have to point out that IBM is interested in having 
a way to mark a property as read-only, which is something OSLC supports.

Peter is proposing to stick with the bare minimum (which he calls the 
backbone in ISSUE-113), and in the process he wants to drop 
sh:defaultValue for which we approved a requirement.

I'm starting to think that a compromise might be to define a small set of 
such features packaged together as an optional feature, if there is such a 
set we could agree on.

It's clear to me that we can't afford to go all the way on this, and I 
have to say that it validates Peter's point last week that there is a lot 
more that would need to be considered to do a thorough job on that front.
--
Arnaud  Le Hors - Senior Technical Staff Member, Open Web Technologies - 
IBM Software Group


Holger Knublauch <holger@topquadrant.com> wrote on 11/12/2015 03:16:41 PM:

> From: Holger Knublauch <holger@topquadrant.com>
> To: public-data-shapes-wg@w3.org
> Date: 11/12/2015 03:17 PM
> Subject: Re: UI/UX snippets
> 
> FWIW I have over ten years of experience on all kinds of UIs for 
> RDF-based data. At TopQuadrant we went through various iterations and 
> redesigns, especially for representing form layouts. The most recent 
> designs to represent form layouts is summarized at
> 
>      http://uispin.org/swa-forms.html
> 
> I would much rather like to use SHACL for these use cases so that form 
> definitions become proper part of sharing linked data, and not just some 

> proprietary non-standard. When someone publishes an ontology, they 
> should be allowed to propose layouts so that generic software agents can 

> display instances in the most user-friendly way.
> 
> In addition to labels, comments and defaultValues (all of which are 
> approved requirements), I continue to suggest something like 
> sh:index/sh:order as a low-cost addition.
> 
> I also believe that having a model-driven way to group together multiple 

> properties (into sections) would be highly desirable. The SWA library 
> above has swa:ObjectsEnum for that purpose, which creates a tree 
> structure that is easy to edit and share. I have just opened ISSUE-114 
> to discuss that aspect.
> 
> Having such features as a built-in feature of SHACL will IMHO attract a 
> large audience, possibly even companies like Google that display lists 
> of properties from their knowledge graph. Delaying these things to other 

> WGs would cost valuable time. Having said this, there is of course a 
> limit to what we should specify. In SWA we have a library of widget 
> types (drop down boxes etc) but that is rather platform-specific and 
> could indeed grow in 3rd party extensions such as SHACL-UI for HTML.
> 
> Holger
> 
> 
> On 11/13/15 6:42 AM, Ted Thibodeau Jr wrote:
> > Towards the UI/UX aspect of things --
> >
> > The following might be considered Use Case, might feed more
> > directly into Requirements, or might be incorporated (no doubt
> > with substantial rewording) directly into the spec.
> >
> > When collecting data (which should conform to a shape), this
> > is often done via forms, which might be green-screen character-
> > based terminal interface, full GUI, or somewhere in between.
> >
> > Automated generation of such a form is often desirable.
> >
> > So...  describing an entity, we know it has some attributes or
> > properties, each of which is identified by an IRI, which is
> > generally not very human friendly.
> >
> > Associating an rdfs:label with that property gives a "human
> > friendly version of the IRI" -- so, for instance, foaf:name
> > gets a nice label of "Name" -- which could be displayed
> > alongside the text entry field (which the tool knows will
> > receive a string, because that's the range of foaf:name).
> >
> > An rdfs:comment might give a somewhat more fleshed out version,
> > such as, "the person's full name" or "the full name to be used
> > for this person", which might be displayed as mouse-over help text.
> >
> > A dcterms:description might give a much more detailed version,
> > which might be displayed upon a click, in a pop-up window, a new
> > browser tab/window, etc.
> >
> > There might be some further attributes, possibly listing all
> > possible values for the property -- which a UI generator might
> > use to create a selection menu for a long list (whether there
> > was to be one selection or many), or a group of radio buttons
> > for a short list with a single selection, or a group of check
> > boxes for a short list with multi-selcetion...
> >
> > This is not exhaustive, by any means.  One of the things we might
> > want to do with our next PWD is to call for pointers to UI/UX
> > ontologies that we might link to -- because reinventing the wheel
> > is not good, and UI/UX is a huge space, but having some simple
> > hooks to other people's work can benefit us all.
> >
> > I hope that's helpful to the process.
> >
> > Ted
> >
> >
> >
> >
> >
> >
> > --
> > A: Yes.                          
http://www.idallen.com/topposting.html
> > | Q: Are you sure?
> > | | A: Because it reverses the logical flow of conversation.
> > | | | Q: Why is top posting frowned upon?
> >
> > Ted Thibodeau, Jr.           //               voice +1-781-273-0900 
x32
> > Senior Support & Evangelism  //        
mailto:tthibodeau@openlinksw.com
> >                               //              
http://twitter.com/TallTed
> > OpenLink Software, Inc.      //              
http://www.openlinksw.com/
> >           10 Burlington Mall Road, Suite 265, Burlington MA 01803
> >       Weblog   -- http://www.openlinksw.com/blogs/
> >       LinkedIn -- http://www.linkedin.com/company/openlink-software/
> >       Twitter  -- http://twitter.com/OpenLink
> >       Google+  -- http://plus.google.com/100570109519069333827/
> >       Facebook -- http://www.facebook.com/OpenLinkSoftware
> > Universal Data Access, Integration, and Management Technology 
Providers
> >
> >
> >
> >
> >
> >
> >
> >
> >
> 
>