W3C home > Mailing lists > Public > public-schemaorg@w3.org > February 2017

human readable labels for schema.org terms (and translated labels)

From: Dan Brickley <danbri@google.com>
Date: Wed, 15 Feb 2017 17:16:59 +0000
Message-ID: <CAK-qy=4qjqwudbbLSLh=opLY+B0+qUyc8zfAF8G=0wsL78GGgQ@mail.gmail.com>
To: Charles McCathie Nevile <chaals@yandex-team.ru>, "schema.org Mailing List" <public-schemaorg@w3.org>
Chaals et al.,

I was looking at what we have for human readable term labels in schema.org -

currently they just mirror the last part of the URL exactly - i.e.

see https://gist.github.com/danbri/f1add8f30b0c7444702e601970a78841#file-_labels-txt
for a list, but these are basically just the last part of their
schema.org URLs, e.g. "action", "CreativeWork" etc.

I remember we've discussed (also) having more sentency strings, e.g.
to make translation easier. Do you have any thoughts on design of
those? e.g. acronym-handling, case handling with a view to translating
into non-English languages and scripts. Looking at
https://en.wikipedia.org/wiki/Cyrillic_script it seems case can be
represented there, but obviously there are other languages to
consider. Currently we have exactly one term ID for each human
readable label, but this requires "action" to be distinct from

We could probably make a first pass at creating more human oriented
labels by adding a space character into the name string whenever a
capital letter is preceded by a lowercase letter or multi-letter
capitalized acronym. We could then make a pass through and consider
expanding anything cryptic. Many properties include acronyms, which
are problematic both for intelligibility, and regarding

A related idea would be to partition the first sentence or two from
the description/definition of each term, since these are sometimes
very large blocks of hypertext. We could aim to make sure that these
"core definition" strings include appropriate expansion or referencing
of any acronyms or confusing terms in the actual term. We could then
use these short definitions as a translation target, and treat them
more conservatively than the larger definition text.



p.s. filed an issue https://github.com/schemaorg/schemaorg/issues/1523
though I suspect there is another issue already which I failed to
Received on Wednesday, 15 February 2017 17:17:33 UTC

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