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