Compacting `@graph` as array.

[timothee-haudebourg]

Hi,

The expected output of compact#t0080 is

{
  "@context": {
    "@vocab": "http://example.org/",
    "input": {
      "@container": "@graph"
    }
  },
  "input": {
    "@id": "http://example.org/gid",
    "@graph": {
      "value": "x"
    }
  }
}

wheras in my output, the @graph value is compacted into an array:

"@graph": [
    {
      "value": "x"
    }
]

I don't see why my output is incorrect here. Reading step 12.8.5 of the compaction algorithm I thought it was clear that members of a graph should be added with as array to true:

Initialize as array to true if container includes @set, or if item active property is @graph or @list, otherwise the negation of compactArrays.

I'm obviously doing something wrong here, but I can't find what.

[pchampin]

I quickly ran the test in the playground and in the Ruby distiller, and both give the same result as your code. Yet, their respective underlying libraries are both marked as passing that test. :-)

My guess is that the JSON-LD Object comparison section of the test manifest is lacking a point: an 1-element array is considered equal to its sole element (unless the array is the value of a @list attribute). @gkellogg @dlongley would you agree?

[gkellogg]

I quickly ran the test in the playground and in the Ruby distiller, and both give the same result as your code. Yet, their respective underlying libraries are both marked as passing that test. :-)

It's possible you didn't set them up properly, as when I run the test, I do get the expected results, here's a playground link. Note that the test uses the expanded input:

[{
  "http://example.org/input": [{
    "@id": "http://example.org/gid",
    "@graph": [{
      "http://example.org/value": [{"@value": "x"}]
    }]
  }]
}]

However, re-compacting with the result does give a slightly different value (the value of the embedded @graph is an array vs an object), so there is a lack of symmetry. However, this is not in conflict with the specification that input is a graph container, and it does compact to not use an array form.

The test is somewhat tricky, as the value of input is a named graph named with an IRI, and it is not an anonymous named graph, which is what the pattern implies, but it is unambiguous. , Arguably, the input term should not be chosen, as it doesn't match.

So, it's reasonable that, when compacting, the value of input is an object and not an array containing an object, but the value of the embedded graph being an array containing an object is not related to the @container: @graph defined for input, itself.

[pchampin]

It's possible you didn't set them up properly

Yeah, "quicky" was the keyword here... I stupidly used the expected output instead of the input.

To answer @timothee-haudebourg's question, I think the answer is that you should go through step 12.8.8.4 ("otherwise does not match one of the previous cases"). Indeed, none of the other cases are matched:

• 12.8.8.1 requires container to also contain @id
• 12.8.8.2 requires container to also contain @index
• 12.8.8.3 requires expanded item to be a simple graph object, hence to have no @id (this is what makes this test tricky, as pointed out by @gkellogg).

And in 12.8.8.4.1 sets the value of @graph without putting it into an array, regardless of as array.

[timothee-haudebourg]

Thanks, that was useful, I found the problem. It was indeed a problem in step 12.8.8.4 where I thought I could factorize some code where I should have not.