Option to compact terms but not values

[gkellogg]

_This was raised by Fabian Steeg:_

The JSON-LD API document states: "Expansion has two important goals: removing any contextual information from the document, and ensuring all values are represented in a regular form."

Is there a way to achieve only the second goal, the regular form, but with compact terms? Using compaction with compactArrays=false is pretty close, but there is still at least one thing that is irregular and causing issues for me.

Given this input:

{
  "http://example.com/foo": "foo-value",
  "http://example.com/bar": {
    "@value": "bar-value",
    "@language": "en"
  },
  "@context": {
    "foo": "http://example.com/foo",
    "bar": "http://example.com/bar"
  }
}

I get this from compaction with compactArrays=false:

{
  "@graph": [{
    "foo": ["foo-value"],              <-- foo: array of strings
    "bar": [{                          <-- bar: array of objects
      "@language": "en",
      "@value": "bar-value"
    }]
  }],
  "@context": {
    "foo": "http://example.com/foo",
    "bar": "http://example.com/bar"
  }
}

But I'd like to get this (which is what expansion does to the values):

{
  "@graph": [{
    "foo": [{                          <-- both foo and bar:
      "@value" : "foo-value"               array of objects
    }],
    "bar": [{
      "@language": "en",
      "@value": "bar-value"
    }]
  }],
  "@context": {
    "foo": "http://example.com/foo",
    "bar": "http://example.com/bar"
  }
}

So I guess I'm looking for something like a compactValues=false option.

Is there some way to get this output?

Original issue Option to compact terms but not values #338.

[azaroth42]

Seems similar to the @type as @container:@setdiscussion and compacting URIs to {"@id": "..."} rather than just a string.

[azaroth42]

👍 to this issue. It's the same use case as #6, and similar to the requirement that led to adding @none for indexing.

Similarly, {"@value": 6, "@type": "xsd:integer"} and {"@value": 6} for data type of value rather than language.

[gkellogg]

Maybe if the context was something like the following:

{
  "@context": {
    "foo": {"@id": "http://example.com/foo", "@type": "@none", "@container": "@set"},
    "bar": {"@id": "http://example.com/bar", "@type": "@none", "@container": "@set"},
  },
  "@graph": [{
    "foo": [{"@value" : "foo-value"}],
    "bar": [{"@value": "bar-value",  "@language": "en"}]
  }]
}

The "@type": "@none" could signify that no value compaction should be performed, and the "@container": "@set" that values should be represented in an array.

We'd need to figure out the term matching precedence of this over other potentially matching terms, presumably match first.

[azaroth42]

@type: @none would work for literals, but not for resources per #6, as the algorithm would be unable to distinguish strings containing URIs from URIs. It would also be harder to distinguish "6" from 6, or 6 from 6.0 if you didn't have a data type.

For consistency with #6, how about (sigh) a new keyword? @compactForm: @dict or something like that?

[gkellogg]

Note that there is a difference in the context use when expanding vs compacting, and that the API allows for a separate expandContext to be provided, so if you had JSON where property values which were strings needed to be interpreted as IRIs, you could expand with a context that made that association, and then re-compact using a context where "@type": "@none" is set, which would then have the affect of maintaining the expanded representation for both values and node objects. For example:

{
  "@context": {
    "@base": "http://example.org/",
    "foo": {"@id": "http://example.com/foo", "@type": "@id"},
    "bar": {"@id": "http://example.com/bar", "@language": "en"}
  },
  "foo": "foo-value",
  "bar": "bar-value"
}

If using itself as an expandContext, or just using the expand API method, would result in the following:

[{
  "http://example.com/foo": [{"@id": "http://example.org/foo-value"}],
  "http://example.com/bar": [{"@value": "bar-value", "@language": "en"}]
}]

Compact using the context from the earlier example would generate the results as I had suggested:

{
  "@context": {
    "foo": {"@id": "http://example.com/foo", "@type": "@none", "@container": "@set"},
    "bar": {"@id": "http://example.com/bar", "@type": "@none", "@container": "@set"},
  },
  "@graph": [{
    "foo": [{"@value" : "foo-value"}],
    "bar": [{"@value": "bar-value",  "@language": "en"}]
  }]
}

Note that if @id or @value had term aliases, they would be used within the compacted values.

[azaroth42]

There could be two contexts, but I don't know of any project or spec that does that. I think the cost of a new keyword (or similar) is much lower than making everyone create two contexts if they want this sort of functionality. -0.9

[gkellogg]

JSON-LD has always had the notion of expanding an input and re-compacting with a new context, so there's really nothing new here. No new keyword necessary. If you don't like the expandContext option, then just make two API calls. Trying to add something that separates the expansion and compaction parts within a single context seems much more of a challenging concept for people to me.

[azaroth42]

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