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: Dan Brickley <danbri@google.com>
Date: Sun, 7 Apr 2019 13:50:57 -0700
Message-ID: <CAK-qy=7T27yRoabxvrzX3uoYPBTxg=S6QqGtUSbon4UMQPcsTw@mail.gmail.com>
To: Pat McBennett <patm@inrupt.com>
Cc: "schema.org Mailing List" <public-schemaorg@w3.org>
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 Sunday, 7 April 2019 20:51:32 UTC

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