- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Thu, 12 Nov 2015 19:17:48 -0800
- To: Holger Knublauch <holger@topquadrant.com>
- Cc: public-data-shapes-wg@w3.org
- Message-Id: <201511130317.tAD3HucJ029626@d03av03.boulder.ibm.com>
Holger Knublauch <holger@topquadrant.com> wrote on 11/12/2015 05:28:32 PM: > From: Holger Knublauch <holger@topquadrant.com> > To: public-data-shapes-wg@w3.org > Date: 11/12/2015 05:29 PM > Subject: Re: UI/UX snippets > > I don't understand this. There is a set of proposed annotation > features, most of which are already approved. They basically do no > harm, have no cost for people who don't care, and didn't even take > many WG resources so far, until Peter started to raise (what he > considers) issues. > > The validation aspect of the language, however, with all its glory > details of recursion etc have probably eaten up 95% of WG resources, > with many difficult problems still to solve. Very few people here > can claim they have experience, so there is a lot of speculation > involved about what people actually need. > > If we follow that pattern, someone could raise a number of ISSUEs > that the validation aspects are too difficult to specify and that we > don't have proper criteria to measure our success in specifying > them, so we should rather just give up instead of trying. Maybe the > chair then chimes in with a "compromise" which moves all remaining > validation topics into a separate, optional, feature. > > Is my impression is correct? No. -- Arnaud Le Hors - Senior Technical Staff Member, Open Web Technologies - IBM Software Group > > Holger > > > On 11/13/2015 11:18, Arnaud Le Hors wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Received on Friday, 13 November 2015 03:18:30 UTC