Gregg Kellogg

Sorry, a bit confused. Step 6.10 is the following: > 6.10) If _element+ has an `@graph` [entry](https://infra.spec.whatwg.org/#map-entry), recursively invoke this algorithm passing the value of the `@graph` [entry](https://infra.spec.whatwg.org/#map-entry) for _element_,...

In the past, we've been reluctant to tie too closely with XSD (other than for conversion of native datatypes like number and boolean). But, this can make things confusing, and...

Agreed, it might be treated as a set of lists, instead.

Other than for `@context`, the only place the spec is particularly restrictive in terms that look like keywords (e.g., `"@"1*ALPHA`) is in context processing. This is necessary, as other JSON...

> Thanks for the clarification, aren't `@id` and `@type` also reserved names for predicates? They have a pre-defined meaning, and a context can't define them otherwise. But, a context sees...

No, one level only. Basically, when compacting, we match to the term "baz" and see that it is nested on "n2". There is nothing to say that "n2" is, itself,...

For values of `@id`, I agree that we should be able to interpret other primitive types, such as number, as suitable for IRI expansion. We did use the URI templates...

It should work for any URI, and with unescaping, IRI. It is just restricted to generate URIs, not general string literals.

These should probably use the `json-ld-1.0` processing mode, although the treatment in 1.1 would be the same. However, blank nodes as predicates is obsolete in 1.1 (from definition of [property](https://www.w3.org/TR/json-ld11/#dfn-property)).

I suppose we could just change the processing mode on these tests, as it's still expected behavior of 1.1 systems, even though it's considered obsolete. That may be better than...