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

Hi Michael,

Cool, sounds like we're on the same page then!

Quick nitpick - on your 2nd bullet point: I think you mean "...Schema.org
code would need to be enhanced to at least disregard such properties
*without* language tags", right?
But in fact, I'd suggest not disregarding, but bombing out with an explicit
error saying something like "*Can't merge this file, as it contains the
comment [X] for term [Y] without any language tag (we reject this because
Schema.org already defines non-language tagged comments, and their current
values cannot be overridden)*".

On your last bullet point, I don't see us attempting to "*approach a
significant proportion of the 2,300 terms*", just the perhaps a couple of
dozen terms we use in our initial UI-driven applications. Likewise, I'd see
us only approaching a handful of common languages too. My hope would be
that our contribution might just 'show the way', and encourage the broader
community to join in and contribute for the Schema.org terms relevant to
their particular interests (thereby eventually achieving full coverage
through community effort).

But your point of file-per-language is well taken - it's an issue I've
considered for sure. Ideally supporting file-per-language or file-per-vocab
(or in the case of 'big' vocabs like FIDO (or Schema.org in the near future
maybe?!) file-per-subsection-of-vocab) are all worth supporting I think
(since the RDF underneath doesn't really care, as all the files are just
'graphs' and so easy to merge (if really needed) when broken up).

Hopefully we'll have an initial update up on Github soon (as it should be
super easy!).

Cheers,

Pat.




On Tue, Apr 9, 2019 at 5:33 PM Richard Wallis <
richard.wallis@dataliberate.com> wrote:

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