Re: UI/UX snippets

Hi Karen,

My current problem with the work of this working group and the issues 
raised on the deliverables is the volume of emails.
If you do not come from a computer science / information science 
background like me, I'm just a mechanical engineer and firefighter, it 
ends up as TL;DR;

That being said, as a member of the working group I did not actively 
engage with the group either to make it a lot more digestible.

My current view on where a 'Data Shapes' vocabulary would fit in is to 
annotate a UI building block with this vocabulary so that it becomes a 
shape by itself.
that means if the application receives data it needs to go through its 
various UI building blocks to see which of them validates against the 
data.
The one(s) that validates can be used to display the data send to the 
application. This is essentially how my current implementation works.

The firebrary, a SKOS based terminology list for fire departments, has 
roughly 2 types of resources, 1) concept schemes and 2) skos concepts.
I use 2 'shapes' with which I validate the date from the graph store. If 
it validates with the Concept shape that will be used to display the 
properties of the concept and vice versa.

attached you'll find a very minimal 'shape' as I use it right now to 
display skos:concepts on firebrary.

>From my last reading of SHACL spec I think all that I need to have is 
available, but all the side notes with issues references makes me 
reluctant to implement a first incarnation.

So now that I did raise my voice on this subject I face a new problem, I'm 
very time constrained so actively contributing to the group is going to be 
a challenge.

Met Vriendelijke Groet / With Kind Regards
Bart van Leeuwen

##############################################################
# twitter: @semanticfire
# netage.nl
# http://netage.nl
# M.A. Reinaldaweg 79
# 3461AJ Linschoten
# tel. +31(0)6-53182997
##############################################################





From:   Karen Coyle <kcoyle@kcoyle.net>
To:     public-data-shapes-wg@w3.org
Date:   13-11-2015 02:02
Subject:        Re: UI/UX snippets



Hi Bart. Thanks for the link to EnyoJS, and for the reminder of how 
complex a language for UX design can be.

Thinking of SHACL as primarily a validation language, but one that could 
have a useful interaction with something like Enyo or other UX design 
packages, what do you see as the key properties that SHACL must have to 
make that connection?

kc

On 11/12/15 1:38 PM, Bart van Leeuwen wrote:
> Hi Ted,
>
> I have been on this for about 7 years already,
> I've looked at Fresnel [1] but at the time it was a dead-end, I didn't
> like the fixed connection between the data and the lens.
> What I wanted to have is a way to express my own layout and ordering of
> data I receive.
>
> In that sense Shapes as a concept is actually that what I was looking
> for. Not so much to auto generate user interfaces but to select which
> user interface parts to use for certain types of data.
>
> Last year at ISWC I presented a approach [2] in the developer workshop
> [3] which actually mentions this working group.
> In the mean time I was able to deploy this concept in more than 60 fire
> station world wide and use it as a frontend for the Firebrary [4] (
> sorry text is all Dutch now )
>
> The UI is defined by json structures ,'shapes' if you like, which fairly
> easily could be converted to JSON-LD to include shapes vocabulary.
> Currently the 'shapes' selection is done primarily on the RDF class and
> the constraints are very limited and processed in javascript.
> The nice part is that you actually define which properties go where on
> your user interface at user interface level.
>
> I'm currently awaiting a new release of EnyoJS which would make playing
> with the code a lot easier, the next step would be to open up the source
> code so others can play with this.
>
> I'm not 100% sure it relevant to the working group, but at least your
> email triggered me to write this down :)
>
> [1] http://www.w3.org/2005/04/fresnel-info/
> [2]
> 
http://blog.resc.info/using-interface-encapsulation-to-listen-to-linked-data-predicates/

>
> [3] http://iswc2014.semdev.org/program/
> [4] http://www.firebrary.com/data/terms/nl/lmc/1.2/200000006
>
> Met Vriendelijke Groet / With Kind Regards
> Bart van Leeuwen
>
> ##############################################################
> # twitter: @semanticfire
> # netage.nl
> # http://netage.nl <http://netage.nl/>
> # M.A. Reinaldaweg 79
> # 3461AJ Linschoten
> # tel. +31(0)6-53182997
> ##############################################################
>
>
>
> From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
> To: public-data-shapes-wg@w3.org
> Date: 12-11-2015 21:42
> Subject: UI/UX snippets
> ------------------------------------------------------------------------
>
>
>
> 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
>
>
>
>
>
>
>
>
>
>
>

-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet/+1-510-984-3600