Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Google Rich Results ignores @context #3455

Open
VladimirAlexiev opened this issue Jan 29, 2024 · 7 comments
Open

Google Rich Results ignores @context #3455

VladimirAlexiev opened this issue Jan 29, 2024 · 7 comments
Labels
no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!).

Comments

@VladimirAlexiev
Copy link

Hi @danbri!
(cc @gkellogg)
We've carefully crafted a context to make the JSONLD exported from our site as pleasant as possible.
It's pasted below in YAML form.

To our horror, when we tested with Google Rich Results,
https://search.google.com/test/rich-results/result/r/articles?id=fbKAnENPedxeLGWKMVigPA
we see that Google completely ignores the context!
This is easiest to see from the author field that's interpreted as a name rather than URL:
image

We also tried putting the context first instead of last, but the result is the same.
Maybe we need to deploy the context on a URL somewhere (rather than being embedded)?

"@context":
  # base and prefixes
  "@vocab": http://schema.org/
  "@base":  https://kg.ontotext.com/resource/
  xsd:      http://www.w3.org/2001/XMLSchema#
  otkg:     https://kg.ontotext.com/resource/ontology/
  sysont:   http://ns.ontowiki.net/SysOnt/
  
  # aliases
  id: "@id"
  type: "@type"

  # schema.org props, keep them sorted
  about:                {"@type": "@id"}
  abstract:             {"@type": sysont:Markdown}
  actionStatus:         {"@type": "@vocab"}
  additionalType:       {"@type": "@id"}
  alternateName:        {"@type": xsd:string}
  audience:             {"@type": "@id"}
  author:               {"@type": "@id"}
  contentReferenceTime: {"@type": xsd:dateTimeStamp}
  contentUrl:           {"@type": "@id"}
  contributor:          {"@type": "@id"}
  datePublished:        {"@type": xsd:date}
  description:          {"@type": sysont:Markdown}
  duration:             {"@type": xsd:duration}
  endDate:              {"@id": endDate, "@type": xsd:date}
  endDateTimeStamp:     {"@id": endDate, "@type": xsd:dateTimeStamp}
  endTimeStamp:         {"@id": endTime, "@type": xsd:dateTimeStamp}
  eventAttendanceMode:  {"@type": "@vocab"}
  hasPart:              {"@type": "@id"}
  homepage:             {"@type": "@id"}
  identifier:           {"@type": xsd:string}
  image:                {"@type": "@id"}
  isAccessibleForFree:  {"@type": xsd:boolean}
  isBasedOn:            {"@type": "@id"}
  isPartOf:             {"@type": "@id"}
  isbn:                 {"@type": xsd:string}
  jobTitle:             {"@type": xsd:string}
  knowsAbout:           {"@type": "@id"}
  location:             {"@type": xsd:string}
  logo:                 {"@type": "@id"}
  mainEntity:           {"@type": "@id"}
  mainEntityOfPage:     {"@type": "@id"}
  member:               {"@type": "@id"}
  mentions:             {"@type": "@id"}
  name:                 {"@type": xsd:string}
  object:               {"@type": "@id"}
  organizer:            {"@type": "@id"}
  performer:            {"@type": "@id"}
  potentialAction:      {"@type": "@id"}
  provider:             {"@type": "@id"}
  publisher:            {"@type": xsd:string}
  recordedAt:           {"@type": "@id"}
  recordedIn:           {"@type": "@id"}
  sameAs:               {"@type": "@id"}
  size:                 {"@type": xsd:string}
  sponsor:              {"@type": "@id"}
  startDate:            {"@id": startDate, "@type": xsd:date}          # start of a conference, date precision
  startDateTimeStamp:   {"@id": startDate, "@type": xsd:dateTimeStamp} # start of a webinar, dateTime with timezone
  startTimeStamp:       {"@id": startTime, "@type": xsd:dateTimeStamp} # start of a WatchAction, dateTime with timezone
  subEvent:             {"@type": "@id"}
  superEvent:           {"@type": "@id"}
  target:               {"@type": "@id"}
  url:                  {"@type": "@id"}
  workFeatured:         {"@type": "@id"}
  worksFor:             {"@type": "@id"}
  year:                 {"@id": startDate, "@type": xsd:gYear}         # start of a refProject, year precision

  # OTKG classes and props, keep them sorted
  EventParticipation:   {"@id": otkg:EventParticipation}
  useCase:              {"@id": otkg:useCase, "@type": "@id"}
@rrlevering
Copy link

First, please post this in the Google support forums since it's a Google specific issue. I swear they bubble up and we usually do something. Or ping me directly on Mastodon with Google SD parsing issues (@rrlevering)

Second, we (Google) don't support extending schema.org vocab in this style (in the same context object). But you can have multiple contexts that are evaluated in order so you can override schema.org default behavior at least for prefix overriding.

Thirdly and most importantly, we don't support a lot of context parsing, most particularly @type definitions (for value types, obviously we parse the node types). Google's systems don't pass along type information from the JSON-LD parse at all besides the native JSON types. They go in as strings, numbers, or objects based on the JSON type and then we separately post-process them with the schema.org spec to make the graph model adhere to the typing standard. This is primarily because we needed to do this anyway for microdata and deal with crappy RDFa/JSON-LD so we can't assume that things like strings/numbers are coming in correctly.

I'll poke at it today a bit to see whether there are some gains I can make easily without a lot of effort. Maybe see if we can at least handle string -> @id logic in contexts. It could potentially make some things nicer without needing to specify { "@id": "foo" } node references.

@VladimirAlexiev
Copy link
Author

hi @rrlevering, thanks for your feedback! Can you point me to the appropriate Google support forum?

We'll use "multiple contexts": should our custom context be deployed on the network (which we actually prefer), or can also be inline (which is slightly more convenient for development)?

deal with crappy RDFa/JSON-LD

I hear you very well.
Just one question: say we emit this (because in our database we use God's own XSD datatypes instead of Schema.org "datatypes"):

"startDate":  {"@value": "2024-01-31T12:34:00 02:00", "@type": "xsd:dateTimeStamp"}

Will Google parse it ok and use the @value and not be bothered by the @type?

string -> @id logic`

that would be useful! Please write here when/if you deploy this at Google Rich Results.

@VladimirAlexiev
Copy link
Author

@Kriska ^

@rrlevering
Copy link

Can you point me to the appropriate Google support forum?

I would post here: https://support.google.com/webmasters/community with a "Structured Data" tag. Generally someone will try to help you and in this case likely escalate to me via an internal bug because it's very technical. Or ping me if that's not satisfying. Sometimes that actually yields better results like documentation changes to fully document this.

The only reason this is kinda fuzzy is that we host the Schema Markup Validator which is using this logic. So there is some argument for posting here, but it makes me a bit uncomfortable because it's mostly a Google focused question.

Will Google parse it ok and use the @value and not be bothered by the @type?

We should ignore the @type field in the your example. In @value objects we currently just use the @value field and the @language field and ignore anything else. Though honestly that would by far be the easiest one to add @type handling to (though probably less useful).

@Tiggerito
Copy link

Can you share the post URL once you have done it. I may be the guy doing the bubbling up :-)

@WinterSilence
Copy link

@VladimirAlexiev #3334 Гугловские схемы не соответствуют стандартам, хоть они и уверяют в обратном (краткая суть моей переписки с ними - "у нас все норм - ищите проблемы у себя").

@VladimirAlexiev VladimirAlexiev mentioned this issue Mar 14, 2024
Open
@github-actions GitHub Actions
Copy link

This issue is being nudged due to inactivity.

@github-actions github-actions bot added the no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!). label May 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
no-issue-activity Discuss has gone quiet. Auto-tagging to encourage people to re-engage with the issue (or close it!).
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rrlevering @VladimirAlexiev @WinterSilence @Tiggerito