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

Type Coercion / Node Conversion: @coerce keyword or similar#335

Open
michaelcpuckett opened this issue Feb 29, 2020 · 4 comments
Open

Type Coercion / Node Conversion: @coerce keyword or similar #335

michaelcpuckett opened this issue Feb 29, 2020 · 4 comments
Labels
defer-future-version Defer this issue until a future version of JSON-LD
Projects
JSON-LD Management DEPRECATED

Comments

@michaelcpuckett
Copy link

michaelcpuckett commented Feb 29, 2020 •
edited

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

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"
}

Currently, the expansion step will generate an error:

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

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 solution that coerces the XSD type, 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 keyword called @coerce.

I originally opened this as an issue in Framing and got some helpful feedback from @gkellogg:

w3c/json-ld-framing#98

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 michaelcpuckett mentioned this issue Feb 29, 2020
Closed
@gkellogg gkellogg added the defer-future-version Defer this issue until a future version of JSON-LD label Feb 29, 2020
@ioggstream
Copy link

Related to #386

@ioggstream ioggstream mentioned this issue Jan 31, 2022
Open
@ioggstream
Copy link

ioggstream commented Jan 31, 2022 •
edited

@michaelcpuckett if you reflect in this use case too, I can close #386 and continue under this issue.

re-reading this issue I understand it's only related to integer values, sorry for the confusion.

@VladimirAlexiev
Copy link

jsonld.SyntaxError: Invalid JSON-LD syntax; "@id" value must a string. is extremely unpleasant.
At least that's what the playground produces: https://tinyurl.com/ya7g4n9y.

@msporny @gkellogg
But is that mandated by the spec? Why can't I make a URL out of an integer, or even a boolean?

@VladimirAlexiev VladimirAlexiev mentioned this issue Feb 1, 2022
Open
@msporny
Copy link
Member

msporny commented Feb 1, 2022 •
edited

But is that mandated by the spec? Why can't I make a URL out of an integer, or even a boolean?

Every feature that we add to JSON-LD makes the implementation burden harder for implementers, and understanding the standard harder for developers, which results in worse interoperability and authoring outcomes.

Yes, it would be nice if JSON-LD processors did this, but at the same time, this is the first time (that I know of) that this has come up during the 10+ years that JSON-LD has existed.

When it comes to things like this, we've suggested that developers first just write a quick function to do some pre-processing on their JSON. For example, a function that runs over a JSON object and turns all "id" values to strings would be a fairly trivial piece of code to write. If we try to put it in the next standard... it'll take 2-4 years for that feature to happen. Given that this is the first time that this feature has been requested, given how long it takes features to be standardized, and given that I expect this need to not be shared among many... write a few lines of code and solve the problem in a way that works for you today.

If we get lots of people clamoring for this sort of type coercion, we can come back and revisit the feature request.

Again, the feature is easy to implement... it's getting the standard updated, implementations updated, test suites updated... that's what'll take time.

An alternative way to address this is to convince the implementers to provide "pre-processing" functions that they can register w/ the JSON-LD processor. So the processor would always run these pre-processing functions before doing the JSON-LD standard operations. Food for thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
defer-future-version Defer this issue until a future version of JSON-LD
Projects
JSON-LD Management
Status: Future Work
JSON-LD Management DEPRECATED
Future Work
Milestone
No milestone
Development

No branches or pull requests

5 participants
@gkellogg @msporny @VladimirAlexiev @ioggstream @michaelcpuckett