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.

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

Type Coercion / Node Conversion #98

Closed
lsimichael opened this issue Feb 29, 2020 · 3 comments
Closed

Type Coercion / Node Conversion #98

lsimichael opened this issue Feb 29, 2020 · 3 comments

Comments

@lsimichael
Copy link

lsimichael commented Feb 29, 2020

(See below)

@michaelcpuckett
Copy link
Contributor

I have an idea for a future version of JSON-LD Framing.

As a web developer, I would like to receive a JSON document from i.e. a simple API, add a @context to it, and perform JSON-LD operations. This light approach has been a big selling point to me for using JSON-LD.

A common response from such an API may include an "id" property as a number (as it is indexed in the source database as an integer), so after applying the @context the document may look like this:

{
  "@context": {
    "@base": "http://starwars.com/",
    "@vocab": "http://starwars.com/",
    "id": "@id",
    "type": "@type"
  },
  "id": 123,
  "type": "Human",
  "firstName": "Luke",
  "lastName": "Skywalker"
}

The expansion step will generate an error:

Invalid JSON-LD syntax; "@id" value must a string.

This makes sense, but my intention in declaring the @base was to form the IRI "http://starwars.com/123". I don't think this kind of type coercion is currently possible with JSON-LD.

The alternative would be a blank node with a custom ID property, which is less useful in certain situations.

I propose a framing solution that generates a new triple with the coerced XSD type and removes the original, so that when flattened, it becomes:

[
  {
    "@id": "http://starwars.com/123",
    "@type": [
      "http://starwars.com/Human"
    ],
    "http://starwars.com/firstName": [
      {
        "@value": "Luke"
      }
    ],
    "http://starwars.com/lastName": [
      {
        "@value": "Skywalker"
      }
    ]
  }
]

As a starting point, I suggest adding a term called @coerce.

@gkellogg
Copy link
Member

This would probably be in compaction/expansion rather than framing. It is somewhat similar to the useNativeTypes option for fromRdf.

It’s a common idiom in JSON, so it’s worthy of future consideration.

@michaelcpuckett
Copy link
Contributor

Thanks! I opened a new issue in the other repo.

w3c/json-ld-syntax#335

If that's right, this can be closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants