Precedence of term redefinition in scope contexts

[pchampin]

As I understand, there are three ways to locally redefine a term:

• with a scoped context in the term definition of a property,
• with an embedded context in a node object,
• with a scoped context in the term definition of a type.

If I read the expansion algorithm correctly, they are processed in that order, the latter ones potentially overriding the former ones.
So, in the following example, the embedded context overrides the property's scoped context.

{
	"@context": {
		"foo": {
			"@id": "ex:foo",
			"@context": {
				"name": "rdfs:label"
			}
		}
	},
	"foo": {
		"@context": {
			"name": "schema:name"
		},
		"name": "this is schema:name"
	}
}

So, in the following example, the type's scoped context overrides the property's scoped context.

{
	"@context": {
		"foo": {
			"@id": "ex:foo",
			"@context": {
				"name": "rdfs:label"
			}
		},
		"Person": {
			"@id": "foaf:Person",
			"@context": {
				"name": "foaf:name"
			}
		}
	},
	"foo": {
                "@type": "Person",
		"name": "this is foaf:name"
	}
}

And in the following, the type's scoped context overrides the embedded context.

{
	"@context": {
		"foo": {
			"@id": "ex:foo"
		},
		"Person": {
			"@id": "foaf:Person",
			"@context": {
				"name": "foaf:name"
			}
		}
	},
	"foo": {
		"@context": {
			"name": "schema:name"
		},
                "@type": "Person",
		"name": "this is foaf:name, while it should(?) be schema:name"
	}
}

and I find that latter example quite counter-intuitive, opposite to the general convention that "local overrides global".

If 1) my interpretation above is correct, and 2) we agree that the local embedded context should override any scoped context (including those of the types), I think that the solution would simply be to invert the order of steps 6 and 7 in the expansion algorithm. But I'l like a second opinion ;-)

PS: edited as suggested by @davidlehn ; "@type": "Person" was indeed missing from the last example

[davidlehn]

In the last example is "@type": "Person" supposed to be in the value of foo? If so, please edit the example.

[gkellogg]

and I find that latter example quite counter-intuitive, opposite to the general convention that "local overrides global".

Yes, indeed. It fell out of the normal processing order for the expansion algorithm. We could change it to look at @type-based scoped contexts before embedded contexts by switching 6) and 7) easily enough, and I would support doing this.

[gkellogg]

One consequence of inverting the order and processing contexts scoped on types before embedded contexts, is if the embedded context defines the term for a type, the scoped context won't be defined yet. For example, the expansion test c009:

{
  "@context": {
    "@vocab": "http://example/",
    "Foo": {"@context": {"baz": {"@type": "@vocab"}}}
  },
  "@type": "Foo",
  "bar": {"baz": "buzz"}
}

When processing, there are no scoped contexts defined for "Foo", so we proceed to the embedded context, which defines the term "Foo". It would work for something defined at a lower level, but this is unexpected.

I suggest that we need to change the processor order back to the following:

1. Scoped contexts defined on a property term,
2. Embedded contexts,
3. Scoped contexts defined on an @type term.

This would keep the processing steps as they are.

[pchampin]

@gkellogg you are right, my proposal makes this example behave in an unexpected way. However, I find it a little convoluted... Why the "double indirection" through type Foo? Why not simply write

{
  "@context": {
    "@vocab": "http://example/",
    "baz": {"@type": "@vocab"}
  },
  "@type": "Foo",
  "bar": {"baz": "buzz"}
}

or maybe

{
  "@context": {
    "@vocab": "http://example/",
    "bar": {
      "@id": "http://example/bar",
      "@context": {"baz": {"@type": "@vocab"}}
    }
  },
  "@type": "Foo",
  "bar": {"baz": "buzz"}
}

[gkellogg]

@pchampin I wasn't suggesting that it was good form to depend on such a processing dependency, but that if it is done, it should behave as expected. You can certainly write examples to avoid the issue.

[pchampin]

I think I figured out some use cases for your example. And so now I'm unhappy with both options :-(
But I can't think of anything that solves all examples, so I'll (reluctantly) close the issue.