Re: General proposal for sealec context processing

Thanks a lot Gregg, this is looking good.

You didn't keep the notion of "effective seals", from my original proposal.
I'll try to better explain what its role was. This is also an attemt to
address Ivan's concern that the proposal was too implementation-oridented.

Attached is a PDF describing 2 hypothetical sealed context
(context_a.jsonld and context_b.jsonld), and a document using both of them
(data.jsonld). The areas in color in data.jsonld represent the parts of the
document where each seal is effective. Theoretically, this "area of
effectiveness" can be defined as a subtree of the JSON tree, rooted in the
node where the sealed context is activated (here, the top-level node), and
deprived of the subtrees reachable through "foreign" terms.

The rationale is that "plain JSON" implementations will only traverse terms
they know, so they will ignore foreign terms and everything below them. So
"plain JSON" implementations expecting context_a (resp. context_b) will
only explore the light-green (resp. light-red) part of the document.

As a consequence (and this is where Gregg's implementation diverges, IIC,
from my mental model), the subtree 37 to 39, is *not* prorected by the seal
of context_a. It would be possible for an embeded context to override a_p1,
for example...

And by the way, it would still be possible to override a_p1 in the
light-red area (e.g. by inserting an embeded context between lines 35 and
36. Unless I'm missing something, Gregg, your implementation currently
allows that. So "re-sealing" the term line 37 seems rather vain...

 best

On Sat, 2 Feb 2019 at 22:13, Gregg Kellogg <gregg@greggkellogg.net> wrote:

> So, I haven’t completed all tests, but I have an implementation which is
> close to my original that I think handles the use cases. Note that it still
> supports `@sealed` on individual terms, but that could be eliminated if we
> so desire.
>
> In the Context Processing Algorithm:
>
> The algorithm now has a `from term` optional parameter, which is either
> set from the `active property` in the Expansion algorithm, or `null`,
> depending (as described below).
>
> When parsing a context from an IRI, the IRI is used as the `context id`,
> otherwise some new unique value. (Note, we don’t actually use `context id`,
> so it could be anything, but it might be useful for warning reporting.
>
> Let `current seal` be the `context id` associated with `from term` in the
> active context, if any. An attempt to clear the active context by setting
> to null is ignored and a warning is issued if `current seal` is set.
>
> Pass `sealed` from the value the `@sealed` member in the local context, if
> any, `current seal`, and `context id` to the Create Term Definition
> algorithm.
>
> In the Create Term Definition algorithm:
>
> 6) If `current seal` is set, and the active context has an existing term
> for `term`, and that term is sealed, issue a warning and skip the term
> definition.
>
> 12) Set `sealed` in _definition_ to `context id` if the value of the
> `@sealed` member in _value_ is true, or the value of _sealed_ if there is
> no such member.
>
> In the Expansion algorithm:
>
> 6) pass `active property` as `from term` when calling the Context
> Processing Algorithm. — prevents overriding sealed terms from the same
> context
>
> 7.1)  pass `active property` as `from term` when calling the Context
> Processing Algorithm. — prevents overriding sealed terms from the same
> context (for @type scoped contexts)
>
> 9.5) do not pass `from term` when calling the Context Processing
> Algorithm. — allows a scoped context for a property to redefine terms
>
> 9.8.2.1) pass `active property` as `from term` when calling the Context
> Processing Algorithm. — prevents overriding sealed terms from the same
> context (for type maps)
>
> I think this achieves what we want. Expansion is called with the active
> property, which may be associated with a sealed context, except when
> processing scoped contexts on property (allows a sealed term to make
> changes). If the active property is not sealed, the context processing
> algorithm will allow changes to sealed terms.
>
> Gregg Kellogg
> gregg@greggkellogg.net
>
> > On Jan 30, 2019, at 11:54 PM, Pierre-Antoine Champin <
> pierre-antoine.champin@univ-lyon1.fr> wrote:
> >
> > Hi all,
> >
> > before I try myself on the API document, I would rather submit to you
> the general ideas I have about how we can achieve what I described in the
> Syntax document. Let me know if that makes sense.
> >
> > The general idea is to assign a unique *seal ID* to each sealed context.
> This seal ID will be included, in the active context, on every term
> definition created by the sealed context. Also, the active context will
> have an additional attribute, 'effective seals', which is a list of seal
> IDs.
> >
> > The context processing algorithms will have an optional 'current seal'
> input parameter. The rationale of this parameter is to remember that we are
> "inside" a given sealed context, and as such should be able to override its
> own term definitions.
> >
> > More precisely, when we are about to override a term definition, we will
> fail if :
> > * the previous term definition has a seal ID AND
> > * that seal ID is in the `effective seals` list AND
> > * that seal ID is different from the `current seal`
> >
> > In other words, a term definition can be overriden if
> > * it is not sealed (it has no seal ID) OR
> > * its seal is not active OR
> > * the overriding originates in the same sealed context
> >
> > The `effective seals` list is managed that way;
> > - when building the active context, we add to the list the seal ID of
> every sealed context we encountered.
> > - During expansion, when we traverse a property, we check its term
> definition and only keep in the list of `effective seals` the seal ID of
> this property, if any. Otherwise, the list is emptied.
> >
> > What do you think?
>
>