- From: Pat McBennett <patm@inrupt.com>
- Date: Mon, 8 Apr 2019 12:01:06 +0200
- To: Michael Andrews <nextcontent01@gmail.com>
- Cc: Dan Brickley <danbri@google.com>, "schema.org Mailing List" <public-schemaorg@w3.org>
- Message-ID: <CABgQ8mJhaJ-hKpESaLi8hR7zn0hKfAtTdzk7u25o7pX-CE=-iQ@mail.gmail.com>
HI Michael, Good points - I agree with them all. But I think you're getting a little more sophisticated (e.g. adding new Schema.org terms for UI elements). All I'm talking about is the low-hanging fruit of cleaning up the 'labels' for the existing terms (e.g. either 'fixing' the current rdfs:label values, or adding a new fresh property) and adding basic language support by appending @en to the current values (for rdfs:label and rdfs:comment). Interesting to see that BartOC vocab - thanks. Just for info maybe, Tim Berners-Lee created a vocabulary for more fundamental UI elements a while ago - might be worth a look: https://www.w3.org/ns/ui.ttl Cheers, Pat. On Mon, Apr 8, 2019 at 7:58 AM Michael Andrews <nextcontent01@gmail.com> wrote: > I would like to endorse the proposal to make it easier to associate UI > labels with schema.org properties. > > I agree this is useful for supporting many use cases, including > localization as well has providing options for short and long descriptive > labels for different devices (e.g., show an icon label on a watch, provide > a full text label for large screen devices). > > While form labels are an obvious use case, the need for labeling applies > to all kinds of UI elements. > > One need is to be able to associate the labels that display with > schema.org actions with the states of those actions. For example, a > button can be associated with a potential action, and may change labels > (e.g., to undo) depending subsequent action status (Active, Completed, > Failed). > > Because different UI elements can be associated with different entities > and states, might could it also be useful for schema.org to define > common UI elements as entities as well? Having UI elements defined as > entities could facilitate with localization mapping. See for example, an > example of how UI elements were identified for localization of an > application: > https://bartoc-skosmos.unibas.ch/i18n-elt/en/page/?uri=http%3A%2F%2Fvocab.nerc.ac.uk%2Fcollection%2FGXM%2Fcurrent%2FGBX1%2F > > Michael > > > > On Mon, Apr 8, 2019 at 2:23 AM Dan Brickley <danbri@google.com> wrote: > >> >> >> On Sun, 7 Apr 2019, 13:00 Pat McBennett, <patm@inrupt.com> wrote: >> >>> Hi, >>> >>> I'm not regularly on this forum, so this question might reflect my >>> newbie status, but my question is very straightforward. Basically I was >>> hoping to use the Schema.org rdfs:label values as useful UI labels in my >>> app. >>> >>> For instance, when editing a Person instance in my app, I'd like to use >>> the 'rdfs:label' value for 'http://schema.org/givenName' on my UI's >>> form. But currently (i.e. in >>> https://schema.org/version/latest/schema.ttl) that value is >>> 'givenName', while of course a UI should show 'Given name' (for English). >>> >>> Likewise, for schema:globalLocationNumber the rdfs:label value is >>> 'globalLocationNumber', which again is not directly usable as a UI label >>> for this field. >>> >>> So it seems that perhaps this Turtle representation of Schema.org terms >>> is simply using the localname of the predicate IRI as the rdfs:label. >>> >>> Would it be possible to changes these rdfs:labels values to more >>> UI-friendly strings? Needless to say I'd be happy to provide suggested >>> changes for the fields we use today, but I suspect it might *not* be an >>> easy thing to do if those label values are simply auto-generated from the >>> predicate's localname... >>> >>> (As a follow on, we'd also like to provide a PR for translations of >>> these rdfs:label values for Schema.org terms we use in our apps, i.e. just >>> into a couple of common languages like Spanish, French, etc). >>> >> >> It could be useful to have such strings, but let's use a fresh property >> eg alternate Name. >> >> As for translations, why not publish somewhere else in GitHub to start >> with? We do have some out of date Chinese in the filetree too, it needs a >> bit more thought about workflow before we add more... >> >> Dan >> >>> >>> Cheers, >>> >>> Pat. >>> >>>
Received on Monday, 8 April 2019 10:01:41 UTC