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

Hi Pat,

Sounds like a plan!

A few thoughts, in no particular order:

   - Currently the files used to create the Schema.org core vocabulary and
   its extensions are in RDFa format.  As it is easy to convert between
   differing RDF serialisations, that would not be too much of a problem if
   and when the work you are embarking upon, is ever merged into the schemaorg
   repository.

   - On a similar point, I think you are OK to assume that an rdfs:comment
   without a language tag is the official [non translated] description.  At an
   eventual merging, the Schema.org code would need to be enhanced to at least
   disregard such properties with language tags.

   - As a start point, google translate could work well for initial
   translations for all rdfs:comment values, I would try to to get some
   community input as validation if possible. And of course you would apply
   your 'official' view to the main terms of interest to you.

   - Also Google translate might provide an easy first pass translation for
   the schema:alternateName values - programatically use the camel-case
   delineated components of labels to provide input into translate.  I would
   imagine that human validation would definitely be required, but it might
   provide a good first pass at a large quantity.

   - On the assumption that your initiative is successful, both in
   approaching a significant proportion of the 2,300 terms (which would make
   it widely usable) and in languages covered; would it not make sense to have
   one RDF file per language?  In that way contributions for differing
   languages could be managed separately, without all the usual git overheads
   of merging things into a large single file.


I will be interested in your progress.

~Richard.

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



On Tue, 9 Apr 2019 at 14:52, Pat McBennett <patm@inrupt.com> wrote:

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