W3C home > Mailing lists > Public > public-schemaorg@w3.org > April 2019

Re: Can we make Schema.org rdfs:label values usable for UI forms?

From: Pat McBennett <patm@inrupt.com>
Date: Mon, 8 Apr 2019 12:01:06 +0200
Message-ID: <CABgQ8mJhaJ-hKpESaLi8hR7zn0hKfAtTdzk7u25o7pX-CE=-iQ@mail.gmail.com>
To: Michael Andrews <nextcontent01@gmail.com>
Cc: Dan Brickley <danbri@google.com>, "schema.org Mailing List" <public-schemaorg@w3.org>
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



On Mon, Apr 8, 2019 at 7:58 AM Michael Andrews <nextcontent01@gmail.com>

> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:12:46 UTC