w3c / json-ld-bp

JSON-LD 1.1 Best Practices Note
https://w3c.github.io/json-ld-bp/
Other
21 stars 7 forks source link

Unexpected typed value experience #14

Open BigBlueHat opened 4 years ago

BigBlueHat commented 4 years ago

While reading https://github.com/w3c/pub-manifest/issues/65 I tested the following JSON-LD in the playground:

{
  "@context": {
    "name": {
      "@id": "http://example.com/name",
      "@type": "xsd:string"
    }
  },
  "name": true
}

This resulted in this unexpected (by me) expanded form:

[
  {
    "http://example.com/name": [
      {
        "@type": "xsd:string",
        "@value": true
      }
    ]
  }
]

Obviously...that's incorrect and I'd expected a warning, error, or (perhaps) type coercion.

Reshaping it a bit, I added a @language tag, and that did throw a more expected error:

{
  "@context": {
    "name": {
      "@id": "http://example.com/name",
      "@type": "xsd:string"
    }
  },
  "name": {
    "@language": "en",
    "@value": true
  }
}

Ask here is to see if we could make this more obvious. 😄

gkellogg commented 4 years ago

While reading w3c/pub-manifest#65 I tested the following JSON-LD in the playground:

{
  "@context": {
    "name": {
      "@id": "http://example.com/name",
      "@type": "xsd:string"
    }
  },
  "name": true
}

This resulted in this unexpected (by me) expanded form:

[
  {
    "http://example.com/name": [
      {
        "@type": "xsd:string",
        "@value": true
      }
    ]
  }
]

Obviously...that's incorrect and I'd expected a warning, error, or (perhaps) type coercion.

Not incorrect, but are you suggesting that we should build in knowledge of the "xsd" so we know that it's not intended as an IRI scheme?

Reshaping it a bit, I added a @language tag, and that did throw a more expected error:

{
  "@context": {
    "name": {
      "@id": "http://example.com/name",
      "@type": "xsd:string"
    }
  },
  "name": {
    "@language": "en",
    "@value": true
  }
}

Ask here is to see if we could make this more obvious. 😄

The purpose of the @type in the term definition is to know how to interpret string values. In this case, it's a value object, so the @type definition does not come into play.

gkellogg commented 4 years ago

(Sorry, this isn't about the xsd prefix, but about the asymmetry of handling value coercion).

Typically, if we see values that are native JSON values (true, ...), the algorithms just leave them alone. If we were not to assign the @type to the value object, we would be out-of-spec with 1.0, which is explicit about doing this.

Perhaps adding something that would make a native value along with @type in a value object, or in coercion, an error, we could get away with it, but again are in danger of invalidating JSON-LD 1.0 content.

BigBlueHat commented 4 years ago

So, I'm probably wanting the xsd:string (and friends) to be more "magic" than it is currently. And perhaps it's not JSON-LD's job to verify data--just to expand it.

The thinking is that the following expanded form JSON would be considered invalid by any one implementing a spec or code--see https://github.com/w3c/pub-manifest/issues/65 for a specific scenario and discussion:

[
  {
    "http://example.com/name": [
      {
        "@type": "xsd:string",
        "@value": true
      }
    ]
  }
]

The result of the lack of this in JSON-LD means that something else (often JSON Schema) is needed to do actual value/content validation. Is/was that the expected scenario? If that's the case, then explaining this is certainly needed for the Best Practices. /cc @ajs6f

Also, I'm guessing the xsd: prefix is the only one of it's kind?--i.e. CURIE's that don't expand?

iherman commented 4 years ago

This issue was discussed in a meeting.

ajs6f commented 4 years ago

I think we can address this, but IIUC I'm not sure we need to say much more than "JSON-LD contains no internal mechanism for data validation. You have to supply that yourself." (modulo better wording)

Or @BigBlueHat , are you thinking of a core commitment we could be seen as letting down?

BigBlueHat commented 4 years ago

Or @BigBlueHat , are you thinking of a core commitment we could be seen as letting down?

Not a core commitment, but a frequently misplaced expectation. 😕 We can certainly call it out with something as simple as you describe, so I'll take a crack at that shortly.

azaroth42 commented 4 years ago
iherman commented 4 years ago

This issue was discussed in a meeting.