Re: UI/UX snippets

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

Connecting a ontology with a layout IMHO is not something I would use 
shapes for, neither would I supply shapes with the data, something Fresnel 
tried as well.
In my rather brief 7 year history of building applications around RDF data 
I very very rarely used only one vocabulary / ontology to describe the 
resources my applications use.
I want a shape to 'shape' a UI according to the data that comes in, most 
of the time this means that two statements who have no ontological 
relation do have a specific relation in my application. To save myself 
from the burden to create a vocabulary / ontology to combine these 2, 
shapes, as I used them in Resource shape format serve exactly this 
purpose.

If I want to display a form to edit a SKOS Concept but there should be 
extra options based on the contents of prov:wasGeneratedBy property,
e.g. if the concept was created by a barts:importAction I need a different 
UI.
With shapes as I understand it, this would be possible without creating a 
ontology / vocabulary to match the skos:concept with the 
prov:wasGeneratedBy for my specific use case.

> 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've did exactly the same in my example in the previous mail.
 

> Having such features as a built-in feature of SHACL will IMHO attract a 
> large audience

I agree, talking to a lot of people who are just starting to play with 
linked data/RDF, shapes is one of the missing links for them to make all 
this data digestible.

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