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

method to require {"id": "uri"} resource compaction result #6

Closed
gkellogg opened this issue Jul 8, 2018 · 4 comments
Closed

method to require {"id": "uri"} resource compaction result #6

gkellogg opened this issue Jul 8, 2018 · 4 comments

Comments

@gkellogg
Copy link
Member

gkellogg commented Jul 8, 2018

Issue: The compaction algorithm prefers the most compact format, which for resources without relationships is a string containing the URI. This causes problems in systems that cannot handle arrays of mixed data types (for example ElasticSearch) when there are also resources that have relationships, resulting in both objects and strings in the same array.

For example:

"seeAlso": [
    "http://example.org/reference1",
    {"id": "http://example.org/reference2", "format": "text/html"}
  ]

would raise an error in Elastic.

Proposed solution: Provide a flag to the compaction algorithm to signal that the resulting JSON should always create objects for resources, even if there is only the URI available. This would instead render the example above as an array of objects:

"seeAlso": [
    {"id": "http://example.org/reference1"},
    {"id": "http://example.org/reference2", "format": "text/html"}
  ]

Original issue: JSON-LD 1.1: method to require {"id": "uri"} resource compaction result #507.

@azaroth42
Copy link
Contributor

👍 to this issue. Being able to generate consistent JSON is valuable for many scenarios, including Elastic as mentioned. It means that consuming systems need much less type checking or pre-processing.

@gkellogg
Copy link
Member Author

This may effectively be a duplicate of #3. No flags required.

@azaroth42
Copy link
Contributor

Agreed. Let's leave both open until both are satisfied, hopefully by the same solution?

@azaroth42
Copy link
Contributor

WG resolved that the use case for #3 and #6 are important, and should have a single solution to be discussed in a separate combined issue: #33

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

No branches or pull requests

2 participants