Unexpected typed value experience about json-ld-bp HOT 8 OPEN

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.

from json-ld-bp.

(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.

from json-ld-bp.

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 w3c/pub-manifest#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?

from json-ld-bp.

This issue was discussed in a meeting.

• RESOLVED: Transfer w3c/json-ld-syntax#257 to best practices document

from json-ld-bp.

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?

from json-ld-bp.

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.

from json-ld-bp.

• You can't create new rdf:type triples by setting @type in the context. Use Framing and @default (note that 1.0 did not allow @default for @type)
• Core purpose is context for the JSON to interpret it -- especially how you interpret strings.
• Native values + type coercion: No need to coerce native types, because they're not strings.

from json-ld-bp.

This issue was discussed in a meeting.

• No actions or resolutions

from json-ld-bp.