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: Richard Wallis <richard.wallis@dataliberate.com>
Date: Mon, 8 Apr 2019 12:17:40 +0100
Message-ID: <CAD47Kz7vc2up2AzYO43xoz7HB_aWz0ihu56Sxe9mOzON6ra34w@mail.gmail.com>
To: Pat McBennett <patm@inrupt.com>
Cc: Michael Andrews <nextcontent01@gmail.com>, Dan Brickley <danbri@google.com>, "schema.org Mailing List" <public-schemaorg@w3.org>
Hi Pat, Michael,

I think your suggestions are a good.

I concur with Dan's suggestion of using an alternative property for the
language dependant name of a term.

As you will see from the current vocabulary definition, the rdfs:label is
effectively defining a short name for a term's defining URI.   As such it
could be potentially disruptive to make changes in this area, not only for
the Schema.org UI but also other tools, UIs, and documentation that depend
on the structure as currently implemented.  I believe therefore it should
be maintained as the, user language agnostic, standard label for a term.

I would recommend the use of the schema property alternateName
<https://schema.org/alternateName> for the purposes you describe.

I could then envisage, as Dan suggests, an initially separate Github area
for the set of terms (there are approximately 2,300) language specific
properties for *alternateName* and *description*.  These could then be used
to underpin language specific implementations as you describe and
potentially a future language aware enhancement to the Schema.org UI.

~Richard.

Richard Wallis
Founder, Data Liberate
http://dataliberate.com
Linkedin: http://www.linkedin.com/in/richardwallis
Twitter: @rjw



On Mon, 8 Apr 2019 at 11:03, Pat McBennett <patm@inrupt.com> wrote:

> 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 11:18:16 UTC

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