Should @graph be dropped during expansion?

[lanthaler]

@gkellogg's latest updates to the API spec (256734b) remove @graph during expansion. I think that's problematic considering how we intend to use it in the future. I think we should just leave it there as it might get some siblings like @id in the future. We would then just need to allow that form and everything would conitnue to work just as today (RDF conversion of course would have to be updated). I'm fine with dropping it during expansion if no other property is defined at the same level as @graph.

Related to this question is what should happen if a processor encounters, e.g., an @id/@graph combination? Should we throw an exception?

[gkellogg]

Well, that's the operation of @graph in expansion now. If we assign new semantics to @graph, we can consider the algorithm implications at that point. For example, the change I made could have meaning only if there is no active property.

The (original) reason for @graph was to be able to describe multiple unrelated resource definitions that need a common @context. Removing it when flattening is the only way to get back to the array representation.

Let's not over-complicate our lives at this point, and try to keep the statement of the algorithms as simple as we can. There are probably innumerable cases of incompatible syntax, and trying to enumerate each one explicitly might be overkill. At this point, the algorithm simply ignores other values. If we want to change the processing when another property (such as @id) is added, then we can handle that at that time.

[lanthaler]

I'm fine with that.

The only thing we need to do then is to specify the precedence order explicitly (also in the syntax spec). There are, as you say, numerous cases.. @graph, @value, @set, @list.. Which one wins is not clear without reading the algorithms.

[lanthaler]

I think I agreed without thinking enough about the consequences. I think the way we intended @graph to work was to define disjoint graphs. The way you defined it in the spec doesn’t reflect this at all. But to be fair, I think we said at one point that @graph should just be supported at the top-level object, right? If that’s true, @graph is completely useless - at least in the current version of the spec - and we should drop it. Let me try to show it based on an example:

{
  "@context": {
    "authored": {
      "@id": "http://example.org/vocab#authored",
      "@type": "@id"
    },
    "contains": {
      "@id": "http://example.org/vocab#contains",
      "@type": "@id"
    },
    "contributor": "http://purl.org/dc/elements/1.1/contributor",
    "description": "http://purl.org/dc/elements/1.1/description",
    "name": "http://xmlns.com/foaf/0.1/name",
    "title": {
      "@id": "http://purl.org/dc/elements/1.1/title"
    },
    "other": "http://other.test/"
  },
  "@id": "http://example.org/test#chapter",
  "description": "Fun",
  "title": "Chapter One",
  "other": {
    "@graph": [
      {
        "@id": "http://example.org/test#jane",
        "authored": "http://example.org/test#chapter",
        "name": "Jane"
      },
      {
        "@id": "http://example.org/test#john",
        "name": "John"
      },
      {
        "@id": "http://example.org/test#library",
        "contains": {
          "@id": "http://example.org/test#book",
          "contains": "http://example.org/test#chapter",
          "contributor": "Writer",
          "title": "My Book"
        }
      }
    ]
  }
}

What does that mean? Using the current algorithm it would expand to:

[
    {
        "@id": "http://example.org/test#chapter",
        "http://purl.org/dc/elements/1.1/description": [
            "Fun"
        ],
        "http://purl.org/dc/elements/1.1/title": [
            "Chapter One"
        ],
        "http://other.test/": [
            [
                {
                    "@id": "http://example.org/test#jane",
                    "http://example.org/vocab#authored": [
                        {
                            "@id": "http://example.org/test#chapter"
                        }
                    ],
                    "http://xmlns.com/foaf/0.1/name": [
                        "Jane"
                    ]
                },
                {
                    "@id": "http://example.org/test#john",
                    "http://xmlns.com/foaf/0.1/name": [
                        "John"
                    ]
                },
                {
                    "@id": "http://example.org/test#library",
                    "http://example.org/vocab#contains": [
                        {
                            "@id": "http://example.org/test#book",
                            "http://example.org/vocab#contains": [
                                {
                                    "@id": "http://example.org/test#chapter"
                                }
                            ],
                            "http://purl.org/dc/elements/1.1/contributor": [
                                "Writer"
                            ],
                            "http://purl.org/dc/elements/1.1/title": [
                                "My Book"
                            ]
                        }
                    ]
                }
            ]
        ]
    }
]

Perhaps that double array would also be optimized to a single one, but that doesn't matter. In the end, the output is exactly the same as if @set would have been used.

Exactly the same is true at the document's top level. Look, e.g., at expand-0009-in.json. If we would replace @graph with @set at the top level we would achieve exactly the same and only some minor algorithm changes would have to be made, i.e., the @set optimization would have to happen later in the algorithm.

Since I still can't get my head around how this would work with disjoint graphs (I don't think it will and should), I would therefore propose:

PROPOSAL: Drop support for @graph and change the expansion algorithm to achieve the same at a document's top level with @set.

[lanthaler]

I think it makes more sense to discuss this in a different context. I've created another issue and close this one here.