Re: Question on expressing translations of terms

On 5 September 2016 at 18:01, Alexandre Bertails <bertails@apple.com> wrote:

> Hi Felix,
>
> I am not surprised GSDT won't accept your snippet because schema:sameAs is
> not defined on all schema:Thing.
>
> I don't think we have made much progress on extending (or not) the range
> of schema:sameAs. To be honest, there's been very little traction there and
> some people just didn't like the idea and were advocating for the use of
> owl:sameAs instead.
>

Yes,  I think we got stuck in those discussions. It might be worth starting
over but backing up and beginning with goals rather than a candidate
(sameAs) solution.

As far as the Google tool is concerned,
https://gist.github.com/danbri/868cb89aeb797a0ff43955b9187f8b6b is as close
as I could get it to passing the checker, but the failures aren't
surprising given the current structures at schema.org.

Not sure what would be the next step though. I would at least prefer having
> a note somewhere saying explicitly that schema:sameAs shouldn't be used for
> such scenarios (maybe in [1]?).
>

What wording would you suggest? My preference would be for the definition
of sameAs to be sufficiently clear but we can always link to more details.

Dan


>
> Best,
> Alexandre
>
> [1] https://schema.org/docs/datamodel.html#mainEntityBackground
>
>
> > On Sep 5, 2016, at 9:47 AM, Felix Sasaki <fsasaki@w3.org> wrote:
> >
> > Hi Alexandre and all,
> >
> > coming back to this old thread … I am working on an implementation
> generating schema.org markup from term data bases - still with the goal
> to represent the „translated_as“ relation between terms. The google
> validation tool gives me for the below input
> >
> > {
> >   "@context": "http://schema.org/",
> >   "@id": "http://example.com/my-term-data-base-entry-1",
> >   "type" : "schema:Thing",
> >  "schema:inLanguage": "ja",
> >  "schema:name": "ページ",
> >  "schema:sameAs": {
> >    "@id": "http://example.com/my-term-data-base-entry-2",
> >    "type" : "schema:Thing",
> >    "schema:inLanguage": "en",
> >    "schema:name": "page"
> >  } }
> >
> > The attached error messages. How could I adapt the example? Or is this
> an issue with the tool?
> >
> > Best,
> >
> > Felix
> >
> > <validation-errors.pdf>
> >
> >
> >> Am 17.03.2016 um 15:35 schrieb Alexandre Bertails <bertails@apple.com>:
> >>
> >> Felix,
> >>
> >> We are currently trying to solve a very similar problem. My plan is to
> use schema:sameAs for that. Applied to your example:
> >>
> >> {
> >>  "@id": "http://example.com/my-term-data-base-entry-1",
> >>  "@type": "schema:Term",
> >>  "schema:inLanguage": "en",
> >>  "schema:name": "screwdriver",
> >>  "schema:sameAs": {
> >>    "@id": "http://example.com/my-term-data-base-entry-2",
> >>    "schema:inLanguage": "de",
> >>    "schema:name": "schraubendreher"
> >>  }
> >> }
> >>
> >> Conceptually, the 2 entities really denote the same thing. Granted, our
> usage of schema:sameAs is not exactly what's described in
> https://schema.org/sameAs but there are reasons why we prefer to stay
> within the schema.org realm. And owl:sameAs would bring a lot of baggage
> with it which we are not interested in.
> >>
> >> Also, I think schema:translation would be too specific. Personally, I
> would be happy if the definition of schema:sameAs was less about web pages.
> >>
> >> Best,
> >> Alexandre
> >>
> >>> On Mar 17, 2016, at 6:22 AM, Felix Sasaki <fsasaki@w3.org> wrote:
> >>>
> >>>
> >>>> Am 17.03.2016 um 13:56 schrieb Thomas Francart <
> thomas.francart@sparna.fr>:
> >>>>
> >>>> I don't think the original question was about translating the terms
> of schema.org itself (classes and properties); it was about the
> possibility to describe terms/words, similar to what SKOS-XL proposes.
> >>>> For me the original proposition makes sense, it would allow to state
> things like "this term/word A is used for a large public", "that other
> word/term B is used by the scientific community" "the words/terms A and B
> are both used to refer to concept C", "word/term A is an acronym of
> word/term B", "word/term D is slang, while word/term E is formal language",
> etc.
> >>>
> >>> Yes, that was the original question. A further comment below.
> >>>
> >>>>
> >>>> Thomas
> >>>>
> >>>> 2016-03-17 13:38 GMT+01:00 Dan Brickley <danbri@google.com>:
> >>>> Yes, I tend to agree with Chaals & Richard here: for translated labels
> >>>> of structured data vocabulary terms (schema.org's and others), we
> >>>> should look towards the underlying W3C standards: RDF/S and perhaps
> >>>> sometimes SKOS, SKOS-XL. It is usual to stick to a single URL for
> >>>> types and properties rather than proliferate them by having different
> >>>> URLs for each language.
> >>>
> >>>
> >>> In my use case (see below) I need to differentiate uniquely (= via
> URIS) between
> >>>
> >>> 1) terms in language X,Y,Z
> >>> 2) common = language agnostic concepts that they denote
> >>> 3) domains (= topics) that they belong too
> >>>
> >>> Richard wrote :
> >>>
> >>> [
> >>> As to proposing a general purpose term definition / relationship
> structure such as you describe, I can see the need for such a capability
> but wonder if in most cases SKOS-like existing solutions would suffice for
> detailed description.  Whereas I would require some convincing as to the
> potential take up in a broad general purpose vocabulary such as Schema.org.
> >>> ]
> >>>
> >>> The use case is a Japanese buyer of items who knows how something is
> expressed in his language. He wants to be able to make a search for
> >>> スクリュードライバー
> >>> and say: give me pages about screwdrivers that express the concept of
> a screwdriver in my domain and denotes the concept I want to buy (= take up
> the information provided by 1,2,3 above). The buyer does not want to buy
> screwdrivers in general, and he does not want to buy everything with the
> label screwdriver in english; but he wants to be a specific screwdriver in
> a given domain, e.g. automative manufacturing. The buyer also wants to take
> variants of how terms are expressed into account, e.g. differences in
> spelling, abbreviations etc.
> >>>
> >>> Such searches are quite common in search of multilingual terminology
> data bases. In these data bases terms are uniquely identified first class
> citizens. More and more companies put such data bases on the web but don’t
> have a way yet to do that with structured HTML markup. So search for
> multilingual terminology, taking 1,2,3 into account, is not yet possible on
> the Web.
> >>>
> >>> - Felix
> >>>
> >>>>
> >>>>
> >>>> Here is an example btw of RDFa+RDFS definitions that do this, from
> >>>> https://github.com/schemaorg/schemaorg/blob/sdo-deimos/
> data/l10n/zh-cn/schema_org_zhcn.html
> >>>>
> >>>> <div typeof="rdfs:Class" resource="http://schema.org/Audience">
> >>>> <span class="h" property="rdfs:label">Audience</span>
> >>>> <span class="h" property="rdfs:label" xml:lang="zh-cn">听众</span>
> >>>> <span property="rdfs:comment">Intended audience for an item, i.e. the
> >>>> group for whom the item was created.</span>
> >>>> <span property="rdfs:comment" xml:lang="zh-cn">听众，观众, 读者</span>
> >>>> <span>Subclass of: <a property="rdfs:subClassOf"
> >>>> href="http://schema.org/Intangible">Intangible</a></span>
> >>>> </div>
> >>>>
> >>>> Does this approach do what you have in mind, Felix?
> >>>>
> >>>> Dan
> >>>>
> >>>> On 17 March 2016 at 10:56, Richard Wallis
> >>>> <richard.wallis@dataliberate.com> wrote:
> >>>>> Not sure I understand your definition of a term, but the ability to
> handle
> >>>>> names, or any other text based properties, of things in multiple
> languages
> >>>>> is already possible:
> >>>>>
> >>>>> {
> >>>>>
> >>>>>  "@context": “http://schema.org/”,
> >>>>>
> >>>>>  "@id": "http://example.com/my-term-data-base-entry-1",
> >>>>>
> >>>>>  "@type": "schema:Thing",
> >>>>>
> >>>>>  "schema:name": [
> >>>>>
> >>>>>    {
> >>>>>
> >>>>>      "@language": "en",
> >>>>>
> >>>>>      "@value": "screwdriver"
> >>>>>
> >>>>>    },
> >>>>>
> >>>>>    {
> >>>>>
> >>>>>      "@language": "de",
> >>>>>
> >>>>>      "@value": "schraubendreher"
> >>>>>
> >>>>>    }
> >>>>>
> >>>>>  ]
> >>>>>
> >>>>> }
> >>>>>
> >>>>>
> >>>>> or in RDFa:
> >>>>>
> >>>>>
> >>>>> <div typeof="schema:Thing"
> >>>>> about="http://example.com/my-term-data-base-entry-1">
> >>>>>    <div property="schema:name" xml:lang="en"
> content="screwdriver"></div>
> >>>>>    <div property="schema:name" xml:lang="de"
> >>>>> content="schraubendreher"></div>
> >>>>>  </div>
> >>>>>
> >>>>>
> >>>>> ~Richard
> >>>>>
> >>>>> Richard Wallis
> >>>>> Founder, Data Liberate
> >>>>> http://dataliberate.com
> >>>>> Linkedin: http://www.linkedin.com/in/richardwallis
> >>>>> Twitter: @rjw
> >>>>>
> >>>>> On 17 March 2016 at 09:04, Felix Sasaki <fsasaki@w3.org> wrote:
> >>>>>>
> >>>>>> Hi all,
> >>>>>>
> >>>>>> It seems that schema.org as of writing would not allow to express
> the
> >>>>>> relation for terms „A is a translation from B“ or „A is an
> abbreviation from
> >>>>>> B“. It is already possible to express that A is translation of B,
> see
> >>>>>>
> >>>>>> http://bib.schema.org/translationOfWork
> >>>>>>
> >>>>>> but this is specific to works, not translated terms. Would the
> below make
> >>>>>> sense? It is adapted from
> >>>>>> https://schema.org/translator
> >>>>>>
> >>>>>> note: schema:Term and schema:translation do not exist in schema.org,
> I
> >>>>>> made them up for the example.
> >>>>>>
> >>>>>> {
> >>>>>>  "@id": "http://example.com/my-term-data-base-entry-1",
> >>>>>>  "@type": "schema:Term",
> >>>>>>  "schema:inLanguage": "en",
> >>>>>>  "schema:name": "screwdriver",
> >>>>>>  "schema:translation": {
> >>>>>>    "@id": "http://example.com/my-term-data-base-entry-2",
> >>>>>>    "schema:inLanguage": "de",
> >>>>>>    "schema:name": "schraubendreher"
> >>>>>>  }
> >>>>>> }
> >>>>>>
> >>>>>> - Felix
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>>
> >>>> Thomas Francart - SPARNA
> >>>> Web de données | Architecture de l'information | Accès aux
> connaissances
> >>>> blog : blog.sparna.fr, site : sparna.fr, linkedin :
> fr.linkedin.com/in/thomasfrancart
> >>>> tel :  +33 (0)6.71.11.25.97, skype : francartthomas
> >>>
> >>
> >>
> >>
> >
>
>