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: Pat McBennett <patm@inrupt.com>
Date: Mon, 8 Apr 2019 11:43:56 +0200
Message-ID: <CABgQ8mKfsEFnKcCMqZyPjUrmXbR62eiwBsSPqhy4cp-oR6RiSg@mail.gmail.com>
To: Dan Brickley <danbri@google.com>
Cc: "schema.org Mailing List" <public-schemaorg@w3.org>
Thanks Dan.

>>> It could be useful to have such strings, but let's use a fresh property
eg alternate Name.
Sure Ok, I've no problem with that. Would you suggest an alternative
Schema.org property, or something else like skos:prefLabel?

But I'm also just curious as to why you'd suggest using a fresh property.
Do you consider the current values of rdfs:label appropriate for Schema.org
(i.e. just the localname of the properties full IRI)?

I only ask 'cos I'd considered the meaning of rdfs:label as simply "As the
creator of this property in this vocabulary, I 'suggest' this string as a
useful very short description of this property to help humans understand
what it is". With that semantic I would think that 'Given name' is an
obviously better rdfs:label value than 'givenName'. And that same meaning
would make rdfs:label values *generally* useful for UI's (but of course if
someone wants their UI to render 'The users first name' instead, then
they're free to add their own property that their app could use to override
this 'default' rdfs:label value).

To strengthen my argument(!) - I think the current rdfs:comment values in
Schema.org are already perfect for use in my UI (e.g. when a user hoovers
over a form label they get a tooltip with the rdfs:comment value giving
them a fuller description of the what the term means).

>>> As for translations, why not publish somewhere else in GitHub to start
with?
Sure, absolutely - I planned on doing exactly that. I had just assumed that
my translations would literally be this simple:
schema:givenName
    rdfs:label "Prénom"@fr ;
    rdfs:label "Nombre de pila"@es ;
    rdfs:label "Vorname"@de .
...but using a fresh property instead of rdfs:label is fine too.

(Actually, this raises another little nitpick - but could the existing
rdfs:label and rdfs:comment values (which are already hugely valuable to me
by the way!) be appended with @en, since at the moment they most definitely
are all in English? I'm thinking that could be a trivial change to
implement :) ).


On Sun, Apr 7, 2019 at 10:51 PM 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 09:44:32 UTC

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