Warn or error if non-keyword strings having "@" are encountered

[gkellogg]

Looking at a schema.org example for ItemList, there is a JSON-LD example which includes the fictitious @url keyword, where they likely meant @id.

{
  "@context": "http://schema.org",
  "@type": "ItemList",
  "@url": "http://en.wikipedia.org/wiki/Billboard_200",
  "name": "Top music artists",
  "description": "The artists with the most cumulative weeks at number one according to Billboard 200",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@type": "MusicGroup",
        "name": "Beatles"
      }
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": {
        "@type": "MusicGroup",
        "name": "Elvis Presley"
      }
    },
    {
      "@type": "ListItem",
      "position": 3,
      "item": {
        "@type": "MusicGroup",
        "name": "Michael Jackson"
      }
    },
    {
      "@type": "ListItem",
      "position": 3,
      "item": {
        "@type": "MusicGroup",
        "name": "Garth Brooks"
      }
    }
  ]
}

There's nothing to signal an issue, and a JSON-LD processor will happily resolve this relative to @vocab as http://schema.org/@url. This creates a potential forward-compatibility issue if new keywords are introduced, as they are in 1.1. We might want to describe normative or suggested behavior if a processor encounters a string which could hold a keyword, but holds something else starting with @.

cc/ @danbri

Original issue: Warn or error if non-keyword strings having "@" are encountered #598

[ajs6f]

Is it possible to choose to ignore such new @ keywords in the algorithms? I.e. create no triples from them and drop them in expansion?

[gkellogg]

Is it possible to choose to ignore such new @ keywords in the algorithms? I.e. create no triples from them and drop them in expansion?

That's what 1.0 does, it just ignores them. The issue was an example in schema.org (ItemList example #3) which uses @url instead of @id, which would seem to be an error. Thus the danger of ignoring such things.

  "@context": "http://schema.org",
  "@type": "ItemList",
  "@url": "http://en.wikipedia.org/wiki/Billboard_200",
  "name": "Top music artists",
  "description": "The artists with the most cumulative weeks at number one according to Billboard 200",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@type": "MusicGroup",
        "name": "Beatles"
      }
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": {
        "@type": "MusicGroup",
        "name": "Elvis Presley"
      }
    },
    {
      "@type": "ListItem",
      "position": 3,
      "item": {
        "@type": "MusicGroup",
        "name": "Michael Jackson"
      }
    },
    {
      "@type": "ListItem",
      "position": 3,
      "item": {
        "@type": "MusicGroup",
        "name": "Garth Brooks"
      }
    }
  ]
}

[ajs6f]

I'm not sure if I'm misunderstanding, but the example doesn't seem to have ignored it at all-- it expanded it to http://schema.org/@url. I'm asking whether it would be possible to ignore it in expansion entirely, i.e. @url would be dropped entirely, no expanded form, no triples. That might be more surprising than helpful, but it would seem to be a little more forward-compatible. Or perhaps I'm still missing the point (wouldn't be the first time!)?

[gkellogg]

the example doesn't seem to have ignored it at all

Good point, that's because of the use of @vocab; otherwise, it would have been dropped. Another reason we might flag this. If you really wanted @url as a relative IRI, you could always use ./@url.

[dlongley]

This seems like a feature implementations could offer (a special mode to check for this sort of thing). I don't think we'd want this extra burden (or any similar extra burdens) added to the standard processing rules.

[ajs6f]

@dlongley I don't maintain an impl (so take a grain of salt with this question), but would a configurable mode just shift the burden to the clients of impls instead of the maintainers of impls?

[dlongley]

@ajs6f,

Yes, but I think that's where it should be. In fact, I think I'm speaking more with my client hat on than my implementer hat when I say that I do not want my production systems to have to deal with the extra burden of checking non-error cases to express warnings.

I think it should be a goal to have a "fast lane" for JSON-LD processing to keep things as efficient as possible. I would prefer that the bottleneck in a complex software system never be JSON-LD processing. One way to help support that effort is to keep corner cases like raising warnings out of the standard processing mode.

[azaroth42]

I'm convinced by @dlongley's argument.

I'm in favor of close won't fix for the following rationale:

• Per @dlongley, raising a warning but otherwise continuing is a burden for processing that in the regular case of it being a part of a much larger automated system will never be seen anyway, so just adds complexity and no value.
• It could be an option to turn on when debugging your JSON-LD, and turned on by default in the playgrounds. But that's an implementation issue, not syntax or API.
• It would break the (admittedly incorrect) existing usage in the schema example, but I wouldn't be surprised if someone had intentionally mapped @label to rdf:label to go along with @type, and it would certainly break them.
• There is already a non-normative note at the end of 4.8 warning against making your own keys that start with @, and I think from a spec perspective that is the right approach.

[ajs6f]

@azaroth42 I'm actually fine with close-won't-fix, but I do want to address one point you make:

Per @dlongley, raising a warning but otherwise continuing is a burden for processing that in the regular case of it being a part of a much larger automated system will never be seen anyway, so just adds complexity and no value.

I disagree strongly. It's exactly in the case of a large fully-automated system where I want warnings from my libraries (instead of silent acquiescence), so that I can accumulate information that lets me improve workflows without them having to break down first. So although I agree that this ticket isn't a good case at all for emitting warnings, I disagree strongly that we could find no such cases.

Just my 2¢!