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

Hi Richard,

Ok, great - thanks for the feedback.

So next steps for us are simply to define our own triples for the existing
Schema.org terms that we use today and that we want to render in our UI's
(i.e. we're not offering to translate all ~2,000 terms in there now!). And
those triples will use the prediate 'schema:alternateName' to provide
human-readable short-form UI-label-suitable descriptions. So for example:

schema:givenName
    schema:alternateName "Given name"@en ;
    schema:alternateName "Prénom"@fr ;
    schema:alternateName "Nombre de pila"@es ;
    schema:alternateName "Vorname"@de .

We'll put this new Turtle file up on Github somewhere too.

But in fact, in relation to your suggestion of using 'schema:description'
for multi-lingual UI display of long-form descriptive text, I don't think
that's necessary. The current rdfs:comment values are actual fine already
(for English). The fact that they don't have a language tag today is not a
problem, our logic can simply assume English in the absence of one (which
seems reasonable to me). So for example, all we need to do to support
multi-lingual long-form descriptions (in the same Turtle file as above) is:

schema:givenName
   rdfs:comment "Vorname. In den USA der Vorname einer Person. Dies kann
zusammen mit familyName anstelle der name-Eigenschaft verwendet werden."@de
.

Does that sound about right to you guys (with the proviso that the
translations I've provided above came from straight from Google Translate,
and are not our 'official' ones!)?

Cheers,

Pat.

P.S. We'd love if our Turtle file could be integrated back into Schema.org
officially, but as Dan says, we understand that you need first to formalize
a workflow for that.



On Mon, Apr 8, 2019 at 12:17 PM Richard Wallis <
richard.wallis@dataliberate.com> wrote:

> 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.
>>>>>
>>>>>