JSON-LD Working Group F2F meeting in Washington DC, USA — First day — Minutes

Date: 2019-02-07

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Simon Steyskal, Harold Solbrig, Gregg Kellogg, Benjamin Young, Rob Sanderson, Jeff Mixter, David Newbury, David I. Lehn, Pierre-Antoine Champin, Adam Soroka, Dave Longley

Regrets:

Guests:

Chair: Rob Sanderson

Scribe(s): Harold Solbrig, Adam Soroka, Rob Sanderson, Jeff Mixter, David Newbury, David I. Lehn


From left to right: David Lehn, Rob Sanderson, Harold Solbrig, David Newbury, Ivan Herman, Jeff Mixter, Gregg Kellogg, and Adam Soroka. (Pierre-Antoine Champin, Benjaming Young and Simon Steyskal dialed-in to the call)

Content:

1. planning, admin

Rob Sanderson: first CR end of August, then time for implementations to be written/updated
… targeting full PR by next June

Rob Sanderson: still have primer to do, to discuss later…
… possible other documents as well
… still need to deal with security and privacy. Comments from Microsoft, Google and ?
… concerns about lightbulbs looking up people’s habits via context. Any network access gives information
… i18n – may or may not be an issue
… hopefully we will push to a future RDF working group
… TR - at least 1 candidate recommendation that can be implemented. By end of CR, 2 independent implementations of every feature
… correction: two implementations for every feature.
… then to PR w/ AC approval. PR has to be at least 6 weeks

Ivan Herman: when PR is published, documents are frozen beyond spelling and grammatical errors
… if some feature doesn’t get enough implementation, must be removed from PR
… we have to close technical issues by time of PR
… a new process may come out in 2020 that makes it easier to update recommendations.
… may consider keeping group alive to take advantage of this. Defer may not mean freeze for 5 years

Simon Steyskal: do we also have to check 1.0 features as well or just new features?

Ivan Herman: we are required to concentrate on new, but have to prove that no impact on old, so checking all might be easier
… we should have enough implementations, emerging from 1.0 continuance
… would propose testing the whole thing as is

Jeff Mixter: how permanent does implementation have to be? Research projects?

Ivan Herman: W3C requirement is that we know it can be implemented. Research is fine…

Rob Sanderson: need to focus on the technical issues and either solve or toss…
… can’t add or remove remove features in CR, so be “judicious but brutal”…
… if too complicated, defer.

Rob Sanderson: virtual white board: https://docs.google.com/document/d/1FcbySJzY5QyBW6HcCtO0LCUmppgIJqQzv565BqC5bOU/edit?pli=1#heading=h.sup6uw56yj6j

2. Sealed contexts

Ivan Herman: If we can’t get to a clear model and agreement on sealing today, I propose we defer it.

Adam Soroka: If we happen to do that, what do we say to verifiable claims, etc?

Rob Sanderson: (reads guiding principles)

Rob Sanderson: https://www.w3.org/2018/json-ld-wg/WorkMode/guiding_principles

Rob Sanderson: sealed contexts - goal is to solve by end of day

Ivan Herman: one thing from last week’s discussions - sealing seems to be a very dangerous thing to do…
… if Google decides to put a seal on schema.org, community will be unhappy …

Gregg Kellogg: we need to understand who we’re serving. Not there for schema.org, rather verifiable claims
… specs as verifiable claims have a shared vocabulary, with some domains wide open, but people can’t change semantics
… in spec, intentionally or otherwise

Benjamin Young: chief aim of proposal is that json and json-ld world co-exist. Term sealing is to guarantee that …
… json and json-ld authors work on exact same shape
… maybe take a step back from sealing and see what other options there may be
… notion of foundational shape surviving framing

Ivan Herman: what I understand from ver. claim. is that they have a wrapper w/ properties whose value is an object…
… want to give total freedom for another vocabulary to leave locally. How about a syntax that says this is an extension point…
… @context null + specific situation that is sealing + @context null
… concentrate on this use case and try not to generalize

Rob Sanderson: sealing doesn’t solve actual shapes - just relationship between key and class. Not producing necessary structure
… it is intersection of RDF semantic layer and JSON keys. Not shape thing as an API. Mapping not API

Pierre-Antoine Champin: goal of sealing is not to guarantee LD has same shape as plain JSON, but JSON LD that has the same shape…
… has the same semantics.
… agree with ivan – sealed is sealed from point to rest of subtree and not try to address unsealed point.

David Newbury: Use case for unsealing is to insert user specified documents into structure. Unstructured JSON into LD…

Ivan Herman: may try to pick up json literal again

Ivan Herman: some examples don’t want literal, but piece of RDF graph but based on another vocabulary on its own

David Newbury: do we need ability to interpret unsealed part in context of whole document?

Gregg Kellogg: yes

David Newbury: do we have use cases where sealed and unsealed need to be interpreted?

Rob Sanderson: I think so

Rob Sanderson: Note - if we can’t solve by the end of the day, revisit the fallback position of JSON literals

Gregg Kellogg: We’re making this too hard. A sealed context is a collection of sealed terms – maintains original interpretation
… an extension point is where you use a term that is not sealed…
… say there is a named term in VC that has a given meaning, but want to be able to add other properties that aren’t sealed…
… also need a “this is a place for you to put stuff” – creating a scoped context where properties can be re-interpreted.
… sealed terms have fixed meaning when you use them.

Pierre-Antoine Champin: a term may be sealed (i.e. its meaning, esp. its IRI, can not be overridden) and an extension point (allow sealed terms to be overridden in its subtree)

David I. Lehn: common use will be use an example, preserving semantics and adding on…

Adam Soroka: we have ways to control shapes of json and RDF, but now we’re talking about a third way… controlling semantics

Pierre-Antoine Champin: gregg says extension points are properties that aren’t sealed — sealed means one cannot override

Gregg Kellogg: one approach is sealed context that allows context underneath to be unsealed…

Pierre-Antoine Champin: thanks @gkellogg, that’s clearer :)

Ivan Herman: i would like to hear a description of the exact sealing proposal

Gregg Kellogg: that would be pchampin’s PR

Ivan Herman: if we cannot explain where we are, we have a problem

Pierre-Antoine Champin: I agree with first 2 parts of the PR, the 3rd one is related to extension points
… we don’t have the same model for unsealing
… especially when it happens automatically
… I think the sealed definitions in a context cannot be overwritten by anything in that context

Ivan Herman: if you seal a context, then the only way the terms can be overridden is in a scoped context within the sealed context?

Pierre-Antoine Champin: I think so

Gregg Kellogg: explicates example on whiteboard Test so03

David I. Lehn: there are problems with this example because the inner context has no effect

Ivan Herman: we often use such examples, which I find a little unnatural

Harold Solbrig: That confuses me

Ivan Herman: [discusses example]

Gregg Kellogg, Ivan Herman, Rob Sanderson: [edit and discuss example]

Ivan Herman: sealing seems to mean that the terms are cast in concrete

Ivan Herman: it is very difficult to explain exception

David I. Lehn: Not sure why it’s unnatural?

Ivan Herman: if the context says “Sealed” that would seem to me to mean that everything is cast in concrete
… but that doesn’t seem to be the case
… we can change things with scoped contexts etc

Gregg Kellogg: this comes out of discussion of multiple sealed contexts

Harold Solbrig: by changing this one term to add a typo, I can open up everything I thought I was sealing

David Newbury: I would have assumed that by sealing a term, it would remain sealed

Gregg Kellogg: so once sealed, always sealed

Gregg Kellogg: that didn’t work for Verifiable Claims because they don’t want to intro a constraint on the JSON-LD within the wrapper

jeff mixer: can I constrain the type of value used with a term this way?

all: no, JSON-LD has no way to constrain the types of values

Adam Soroka: Agree completely. The wrapper compresses the protocol into the document
… It pulls us toward sealing other things beyond just the mapping, but into complex chains

Harold Solbrig: preventing people from accidentally overwriting contexts seems within our scope, but not all the further ramifications

Pierre-Antoine Champin: re: when terms become unsealed
… it is genuinely hard to explain
… I would say that a sealed term is sealed anywhere, except when the sealed context opens it
… there are two situations in which one can redefine a sealed term
… plain JSON users don’t expect the semantics to be sealed any more
… we should leave the decision of when to unseal terms to the authors of the sealed context

Ivan Herman: an extension point means a combination of “context now” and “I cannot touch what is on the upper level”

Gregg Kellogg: {discusses Ivan’s example]

Ivan Herman: how about a keyword “extension” that means you cannot redefine anything you inherit?

Gregg Kellogg: not quite @context: null.

David Newbury: if we have a context that defines ‘name’ within a sealed context, [points to examples]

Gregg Kellogg: [discusses examples]
… it may be simpler in the end to say that sealed terms are always sealed except for @context:null
… but subtleties arise when two sealed contexts interact

Rob Sanderson: can we do that example?

Ivan Herman: the only place where @context:null would have a nuclear option would be in the context that is sealed

Adam Soroka: [discussion of various examples]

Gregg Kellogg: [refers to examples]

David Newbury: ditto

Pierre-Antoine Champin: [example of two contexts conflicting]

David Newbury: the confusion caused by accounting for the complex interactions outweighs the utility

Harold Solbrig: what if we turned the pattern inside out and let contexts signify that they don’t intend to override?
… if you want to enforce that, you do it on a vocabulary-specific basis
… with rules for that particular context

Gregg Kellogg: so if a context lacked that flag, it would be harder to reuse it

Harold Solbrig: depends on how much you care about this relationship between the contexts

Adam Soroka: [discussion of what is or is not in scope for the use case and interoperability concern]

Gregg Kellogg: not clear how to specify that

Ivan Herman: going back to David’s example

Ivan Herman: [discusses example]

Rob Sanderson: [discusses example]

Gregg Kellogg: @context: null has a specific meaning and we are altering it

Ivan Herman: if we go down the road of “sealing”, then @context:null is going to conflict in some way and we will have to resolve it

Harold Solbrig: that’s why I went for an extension-based approach

Gregg Kellogg: we have until noon!

Harold Solbrig: can we get the use case in a more concrete form?

David Newbury: I’m increasingly fond of Harold’s idea to put in an “extension” property that errors if something with it overrides a term
… this allows me to write extensions that will work, but it may not be what VC need

Pierre-Antoine Champin: I have to think about that idea (Harold’s idea). gkellogg convinced me to try to explain again how a context becomes ineffective.
… I’m in favor of saying that whenever I traverse a term that is not part of a sealed context, it’s not sealed anymore
… after which a term could have been redefined: no guarantees about the semantics!
… as for @context:null– maybe the “extension” idea is a better way to make extension points; it makes the unsealing specific
… to make @context:null work one goes through both extension properties

Gregg Kellogg: let’s for the moment let’s put off the table any terms from a non-sealed context
… the behavior I heard dlongley describe
… is that history is wiped out and we start from scratch

Ivan Herman: I’m good so far

Gregg Kellogg: but if you do want to allow a mixture of sealed and unsealed terms, we get into the case that pchampin discussed
… two ways to have an extension point: 1) an unsealed term, under which anything goes, 2) a sealed term that is defined as an extension point
… and 2) doesn’t satisfy the use case

Ivan Herman: let’s say I have a claim, and I put into the context a @context:null to make an extension point.
… the danger is that I will redefine a term from VC, accidentally or maliciously
… IIUC VC, it’s a bit like Annotation
… outsiders are expected to use their own vocabularies with these guys, without having to understand VC or Annotation

Gregg Kellogg: one case is that everything is wiped out, but the other is that you intermingle the use of properties

Ivan Herman: so I can add my own context

Gregg Kellogg: but not redefine terms
… we would end up with semantics that differ between JSON and JSON-LD

David I. Lehn: the way that Activity Streams does this is to say “You must not override or change contexts” as a normative piece (see https://www.w3.org/TR/activitystreams-core/#jsonld)

Rob Sanderson: people do this now by ordering the contexts

Rob Sanderson: [returns to examples]

Rob Sanderson: you can say that a sealed context can have an extension
… having sealed on the context is confusing and makes more sense at the term level

Ivan Herman: what is the difference between sealed and extension
… if extension was not true then there would be a warning

Ivan Herman: why not just say extension:true – it’s not setting a context?

Rob Sanderson: to distinguish from the case of this term being an extension

Gregg Kellogg: two different keywords that act on the context are unclear

Rob Sanderson: the change is that the default condition is “sealed”

Dave Longley: i’m on another call and can’t join, so i apologize… but was reading what’s here and thought i’d throw this in here… if there is a fear that schema.org (or contexts like it) might get sealed … we could allow {"@context": [{"@contextref": "http://schema.org", "@sealed": false}, ...]} and the reason that would be ok for the sealed case we care about in VC community and so on, is because JSON processors would reject that … the context MUST be specified as a simple string, that’s what JSON-only processors would be looking for: {"@context": ["https://w3id.org/credentials/v1", ...]}

David Newbury: I thought we were talking about three use cases, one of which is ability to delete context, which is @context:null
… are we trying to prevent people from overriding accidentally or maliciously?

Gregg Kellogg: we can’t prevent malice

Ivan Herman: it’s a clean slate… but not

Harold Solbrig: @context:null is often too much

Adam Soroka: gkellogg and ivan: [thrash more examples]

Rob Sanderson: we fundamentally don’t want the semantics to slip between JSON and JSON-lD

Rob Sanderson: [more examples]

Rob Sanderson: gkellogg: “extension” unseals everything, which is not @context:null

Adam Soroka: [discusion of @context:null and whether it is a problem for the original use case]

Gregg Kellogg: if there’s another context with sealed terms and extension points

Rob Sanderson: regardless of which context has the sealing, extension overrides it.

Gregg Kellogg: that’s the simplest way

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-442896360

Benjamin Young: dlongley and I discuss term ordering and inheritance
… there is a problematic example there
… [discusses vocabulary]

Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-454485321

Benjamin Young: this example shows how to avoid that by being verbose
… [discusses problems that concern @type usage and inheritance]

David Newbury: if I have two sealed contexts that define the same term, who wins?

Gregg Kellogg: last one in

Rob Sanderson: Reviewing the rules that we think we’re talking about.

Adam Soroka: the use case is to avoid semantic slippage around terms when interpreted as JSON.

Rob Sanderson: If @extension:true is encountered in scoped context definition, then attempts to redefine terms from the active context will succeed.

Ivan Herman: If this is the rule, in the embedded context, I can also change the ID of that term?

Rob Sanderson: yes. You can redefine anything.

Ivan Herman: so if I have @extension : {}, the extension of the original key remains.

Gregg Kellogg: the effect of extensions: true is to update the active context and remove the sealed status of all terms within that context
… allowing those terms to be renamed within the value of the extension property

Ivan Herman: so inside, something may be different than outside?

Gregg Kellogg: yes. It only makes sense within a scoped context, and only makes sense on a sealed term.
… if you extend an unsealed property…

Gregg Kellogg: within an extension property, we can only define additional properties within that context.

Rob Sanderson: this is an error: [{"extension": { @id: extension_property, @sealed:true, @context: {@extension:true}}}}, { "extension":{@id: extension_propery}]

Rob Sanderson: extending unsealed terms is dumb, but not an error.

Pierre-Antoine Champin: I’m fine with this…in practice, this would mean that the plain JSON interpretation can only trust terms from the sealed context in the subtrees I defined.
… because when there is a term from another context, theydon’t know anything about that term.
… if we’re happy with this, we’re happy, but it seems like a lot of work to get to the same point.

Gregg Kellogg: I don’t think we’re at the same point.
… it’s only when we transition to a property when it’s extension: true that we transition

Pierre-Antoine Champin: the assumption that JSON-only is the same–it’s only trustworthy when looking at sealed terms.

Gregg Kellogg: that’s consistent with the spec.

Pierre-Antoine Champin: right. that’s why I’m OK with this.

Rob Sanderson: the thing we’re not able to deal with is nulling out terms and then redetermining them. So it works.
… so for VC, the context for the claim can start with null, which wipes out their context.
… so I don’t think that VC will use extension: true.

Gregg Kellogg: do we have a use case for this?

Ivan Herman: I thought that they want to avoid that anyone includes in the claim things that redefine things within verifiable claims

Gregg Kellogg: I think that applies to the envelope
… within the envelope, naive applications may not need to understand them.
… for example, annotation properties
… they come from another context
… so if you introduce another term in the envelope, those envelope extensions won’t override the VC

Rob Sanderson: don’t mess with our stuff
… vs:issuer should not be overridden, but if an extension defines ex:date, that’s fine. but the extension should not be able to override vs:issuer.

Gregg Kellogg: …explaining his example…
… since we have both a sealed context and schema, name remains it’s context. within the extension, something could set the scoped context to null.
… it could add a new context, and it could be anything.
… thus, VC does not need extension

Ivan Herman: why are we doing this?
… if this can be met with sealed and nullification, what is the use case for extension?
… this is the simplest thing that can work. That’s what we should do.
… do we need extension at any point?

Gregg Kellogg: I agree.

Adam Soroka: so there’s no need for nullification
… (i mean extension)

Gregg Kellogg: what we determined is that we’re not going to restrict @context: null. In that case, we don’t need the exceptions.
… you can always do @context: null
… thus, you can do it in a scoped context
… meeting VC’s use case

Benjamin Young: this VC is something that we haven’t discussed
… We don’t have anything that addresses it .
… since it’s type term usage, not property-term usage
… can we describe it as a use-case?
… term inheritance works…they don’t need sealing…
… but the scoped context around @type breaks things
… see the comment further down about getting around this by being verbose, but…this is how those things are extended.
… using a base type, and adding additional types…so type ordering matters.
… endorsed by handwaving, but would like a better mechanism
… but this is where things are breaking

Benjamin Young: example description is here https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-442896360

Benjamin Young: verbosity “solution” is here https://github.com/w3c/json-ld-syntax/issues/20#issuecomment-454485321

Gregg Kellogg: this example: we would process the scoped context for specificCredential…issue is defined in an example.
… this is dlongley’s example, not mine
… he was saying that the context ordering gets nullified by scope contexts and type…core vocabulary at the end doesn’t work, since types can override that.

Gregg Kellogg: scoped context would not override this if issuer is a sealed term

Benjamin Young: we have two inheritance orders: CSS and FIFO
… so we would flip them, so if sealing isn’t done properly, then we have problems
… don’t know if there’s a solution here…other than a core vocabulary that comes first

Rob Sanderson: this seems to me to be application-logic-layer
… so VC would have a sealed context…

Benjamin Young: {"@context": {"@sealed": "http://vc-data.example/", "@extensions": ["http://extension-1.exampe/", "http://other.example/extension"]}}

Rob Sanderson: …typing on the whiteboard…

Gregg Kellogg: so there’s a new extension keyword that imports without redefining?

Benjamin Young: this is something totally different

Rob Sanderson: this just inverts where the properties live

Benjamin Young: this means that the core is at the top, and the extensions below

Rob Sanderson: with would work with term definitions

Benjamin Young: currently, you put the core last.
… now you need to move it to the top, or potentially to both places

Gregg Kellogg: this means that the thing at the front and seal it, then it can’t be changed

Rob Sanderson: to me, sealing is the inversion of the property rules.

Benjamin Young: this means that the scope documents now need to be explicitly 1.1

Rob Sanderson: if you’re using 1.1, but interpreting as 1.0, it will be strange.

Gregg Kellogg: I think we can only talk about what 1.1 will do
… the reason that 1.1 is needed, so that if a 1.0 processor sees it, it will die

Benjamin Young: so in 1.1 we’re inverting the order?

Gregg Kellogg: I don’t see it as inverting, I see it as a new effect.

Benjamin Young: this sounds like !important in CSS

Gregg Kellogg: it continues to work

Benjamin Young: even if someone else seals it first?

Gregg Kellogg: I think we need to table multiple contexts that seal
… I don’t think it’s what we’re promoting
… as a best practice, there should be only one
… as a corner case, we should…

Ivan Herman: the usage of sealed in the grand scale of things will be minimal
… if it’s awkward, then that’s OK, because this is rarely used.

Adam Soroka: we don’t know this will be rare

Ivan Herman: our schema discussion showed us that we should not use sealed regularly.
… common, vague vocabularies should not used sealed.
… there are good use cases, but let’s be careful.

Gregg Kellogg: IMO, sealed should only be used by contexts defined in specifications where there is a dual JSON/JSON-LD processing mode, and then only rairly

Rob Sanderson: the other thing that’s important to put down is sealed is not a guarantee that it can’t be changed, but to prevent unintentional.
… you can always put in a version 1.0…

Gregg Kellogg: you can’t go back

Ivan Herman: the @context:null option is there, so we can not defend against all malicious use

Rob Sanderson: so we don’t need extension: true, because there’s no use case and we can cover it by nulling and re-i porting?
… so are we back to the simple rule?
… If @sealed: true is encountered on a term definition, then attempts to redefine the term will fail and result in a warning.

Gregg Kellogg: with a note about using context:null

Adam Soroka: so there’s no way that a term picks up an unintentional meaning

Harold Solbrig: can I put a @sealed on the external context?

Gregg Kellogg: you can’t do that

Ivan Herman: you can’t seal someone else’s context

Harold Solbrig: I would still like to be able to make sure that I don’t unintentionally reuse terms

Gregg Kellogg: can this be solved with SHEX?

Harold Solbrig: maybe…

Pierre-Antoine Champin: what happened to redefining a term within a sealed context?

Gregg Kellogg: we said that’s not possible.
… the only way to do this is to null the context

Pierre-Antoine Champin: so context:null could happen anywhere?

Rob Sanderson: correct

Pierre-Antoine Champin: so sealing prevents explicit redefining the sealed terms, but not guaranteeing their stability.

Gregg Kellogg: correct

Rob Sanderson: context: null is the way out of things, and you’d only do that in the VC case if you were trying to be malicious, and we’ve decided we can’t guard against that.
… the intent is to avoid unintentional redefining.
… to fix that, you need a preprocessor.

Adam Soroka: is sealing now to strong a name?

Gregg Kellogg: it is sealed in the active context.

Pierre-Antoine Champin: I disagree; freezing (and sealing, for that matter) in JS is a quite different thing

Ivan Herman: let’s make a resolution, and go to lunch

Proposed resolution: Adopt the following rules for sealing - 1: If @sealed:true is encountered on a term definition in the active context, then attempts to redefine the term will fail and result in a warning. 2 - If @sealed:true is encountered on a context, then all terms defined within the context should be treated as having @sealed:true in their definition. 3- If @sealed:false is encountered on a term definition in the active context, where the context has been sealed with @sealed:true, then the sealing for that term is removed. (Rob Sanderson)

Harold Solbrig: if there’s a sealed: false for an unsealed term, what happens?

Rob Sanderson: +1

Ivan Herman: +1

Gregg Kellogg: nothing–that doesn’t mean anything

Adam Soroka: should we warn?

Gregg Kellogg: +1

Jeff Mixter: +1

David Newbury: +1

Simon Steyskal: +1

Harold Solbrig: +1

Pierre-Antoine Champin: +0.5

Gregg Kellogg: we SHOULD

Adam Soroka: +1

Benjamin Young: +0 (would like to see use case mappings for all these things)

David I. Lehn: +1

Resolution #1: Adopt the following rules for sealing - 1: If @sealed:true is encountered on a term definition in the active context, then attempts to redefine the term will fail and result in a warning. 2 - If @sealed:true is encountered on a context, then all terms defined within the context should be treated as having @sealed:true in their definition. 3- If @sealed:false is encountered on a term definition in the active context, where the context has been sealed with @sealed:true, then the sealing for that term is removed.

Dave Longley: “If @sealed:false is encountered on a term definition in the active context, where the context has been sealed with @sealed:true, then the sealing for that term is removed.” <– this sounds like a big problem as written …

Dave Longley: is this saying that with {"@context": [1, 2]} that 2 can unseal anything it wants?

Dave Longley: if so, that defeats the purpose of sealing … so i can only imagine that something else was meant by that text.

Dave Longley: it sounds like an attacker that defines 2 can get a VC to be successfully processed by a JSON-only processor in a different way from a JSON-LD processor under that condition

Dave Longley: i’ll check back here later to see if there’s a clarification

Dave Longley: if the ability to unseal a sealed context is a requirement (as opposed to just extending in an acceptable way) … it seems like we could do it without messing up JSON-only processors by using some other syntax that they would otherwise reject.

Dave Longley: JSON-only processors will be looking for {"@context": [<specific string>, <specific string>, ...ignored]}

Dave Longley: or could perhaps be further limited to: {"@context": [<specific string>, <specific string>, ...<must be a string but value is ignored>]}

Dave Longley: in other words, any deviation from some very rigid rules would cause a JSON-only processor to reject the input … which could be potentially used to our advantage if we need to cover other use cases where we are fearful of people sealing things that JSON-LD aware entities would like to unseal in a way that would not impact JSON-only processors.

Dave Longley: but what is key is that that any mechanism that is used to unseal would not impact JSON-only processors.

Dave Longley: if we can abide by that rule, i don’t see why i wouldn’t be supportive.

Rob Sanderson: dlongley: The @sealed:false would only work for the original definition, no subsequent attempt to redefine it

Rob Sanderson: It overrides the @sealed:true on the context

Rob Sanderson: But not @sealed:true on a term

Dave Longley: azaroth: ok, if I understand you I think that’s fine

Adam Soroka: https://github.com/w3c/json-ld-syntax/issues/87

2.1. closing related issues

Proposed resolution: Close #87, as unnecessary given above rules. (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Gregg Kellogg: +1

David Newbury: +1

Jeff Mixter: +1

Simon Steyskal: +1

David I. Lehn: +1

Resolution #2: Close #87, as unnecessary given above rules.

Simon Steyskal: https://github.com/w3c/json-ld-syntax/issues/98

David Newbury: +1

Ivan Herman: +1

Proposed resolution: Close #98, as @context: null clears context definitions (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

Harold Solbrig: +1

David I. Lehn: +1

Resolution #3: Close #98, as @context: null clears context definitions

David I. Lehn: https://github.com/w3c/json-ld-syntax/issues/116

David I. Lehn: discussion of [https://github.com/w3c/json-ld-syntax/issues/116#issuecomment-460681505]

David I. Lehn: [missed scribing much back and forth, trying to catch up on the gist]

Gregg Kellogg: [pointing out current algorithm could be modified based on some rules to handle the partial redefinition]

Ivan Herman: [concerns about backwards compatibility]

Gregg Kellogg: based on algorithm, 1.0 would fall through to new 1.1 behavior

Ivan Herman: sounds like adding more hacks

Dave Longley: also want it to be easier for json authors

Gregg Kellogg: we go towards side of being easier for authors

David Newbury: hard to follow what is going on without knowing all the processing steps

Gregg Kellogg: not overriding term itself […?]

Rob Sanderson: more authors to explain to than people needing to understand this feature. on side of authors.

David Newbury: issue with how things are overridden. seeing next term definition would think it fully overrode first one.

Ivan Herman: [worries about more complications]

David Newbury: example seems like json in json-ld

David I. Lehn: it’s a mix in this case, using json tools to process json-ld. would want to know the context of the data.

Rob Sanderson: [discussing how some examples would be processed]

Ivan Herman: adding new features to already complex system. really worried about it.

Dave Longley: understand ivan. A goal is to make ergonomics of 1.1 easier for users and better than 1.0

Proposed resolution: if @id is not present in a term definition, and there is no default vocabulary, but has an expansion to an absolute IRI in the active context, then the @id of the new definition is taken from the active context (otherwise this is still an error) (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Simon Steyskal: +1

Gregg Kellogg: +1

Dave Longley: +1

David I. Lehn: +1

Jeff Mixter: +1

David Newbury: +0.5

Adam Soroka: +1

Resolution #4: if @id is not present in a term definition, and there is no default vocabulary, but has an expansion to an absolute IRI in the active context, then the @id of the new definition is taken from the active context (otherwise this is still an error)

Proposed resolution: Once previous is done, we can close #116 (Rob Sanderson)

Harold Solbrig: +1

Ivan Herman: +1

Rob Sanderson: +1

David Newbury: +1

Simon Steyskal: +1

Jeff Mixter: +1

David Newbury: +1

Rob Sanderson: +1

Harold Solbrig: +1

Adam Soroka: +1

Ivan Herman: +1

Rob Sanderson: Really 116 :)

David I. Lehn: +1

Resolution #5: Once previous is done, we can close #116

Proposed resolution: We agree with the processing order per #61: scoped definition from property, then from type, then embedded. PR to update docs to come. (Rob Sanderson)

Ivan Herman: +1

Rob Sanderson: +1

Adam Soroka: +1

David I. Lehn: +1

Simon Steyskal: +1

David Newbury: +1

Jeff Mixter: +1

Harold Solbrig: +1

Gregg Kellogg: +1

Resolution #6: We agree with the processing order per #61: scoped definition from property, then from type, then embedded. PR to update docs to come.

Harold Solbrig: scribnic hsolbrig

Gregg Kellogg: what if you said context null?

Rob Sanderson: it would wipe out all definitions

Gregg Kellogg: you could also seal activities

3. circular context references

Adam Soroka: https://github.com/w3c/json-ld-api/issues/14

Rob Sanderson: but object could be also be the top level node

Gregg Kellogg: the reason we keep a list of imported context is to prevent ourselves from running away but someone figured out an attack…
… that created contexts that imported themselves, so we established a max depth.

David I. Lehn: error in the spec or error in an implementation?

Rob Sanderson: the verifiable claim that talks about a verifiable claim has the circular issue as well.

Gregg Kellogg: issue is a document that includes a document that is an array that includes itself.

Ivan Herman: if you put an array of context that is activity context, activity. What is left in the end is only things that overlap, so in this case the
… activity context rules.

Gregg Kellogg: propose that instead of seeing that something is included in the array, check a max size. Essentially elimate 3.2.2

Gregg Kellogg: limit mandated or set by application.

Ivan Herman: example in issue isn’t recursion …

Gregg Kellogg: If we keep the inclusion array, but once we’ve stopped we get rid of it .. but it doesn’t solve the attack problem. If we add in …
… a limit on the stack size

Gregg Kellogg: Move away from how the issue is handled and specify behavior instead.

Gregg Kellogg: we should have tests for both situations

Proposed resolution: Update the algorithm to describe desired behavior of disallowing unbounded loading of contexts, still allow ping-ponging between two contexts in the document (or scoped contexts). (Rob Sanderson)

Ivan Herman: +1

Jeff Mixter: +1

Rob Sanderson: +1

Simon Steyskal: +1

Harold Solbrig: +1

David I. Lehn: +1

Gregg Kellogg: +1

Adam Soroka: +1

Resolution #7: Update the algorithm to describe desired behavior of disallowing unbounded loading of contexts, still allow ping-ponging between two contexts in the document (or scoped contexts).

4. JSON Literal

Harold Solbrig: https://github.com/w3c/json-ld-syntax/issues/4

Ivan Herman: to do this, we will have to define an RDF data type for JSON

Ivan Herman: look at RDF concepts document - 3 or 4 lines

Rob Sanderson: https://www.w3.org/TR/rdf11-concepts/#section-html

Gregg Kellogg: what we need to do that those didn’t is to deal with white space…

Ivan Herman: the only thing we have to do is to say there is a string, declared to be JSON

Ivan Herman: it makes cannonicalization difficult so we’d have to find or referenc it
… the fact that there are html data types that makes cannonicalization difficult or impossible
… so if you want to do cannonicalization, html is the big kahuna, and json is secondary
… you may want to answer question about json equality, but is that our responsibility.

Gregg Kellogg: when you parse html or xml, value elements preserve white space. As a result, indentation variations give different literals.
… in json, parsing is done after parser is completed and parsers don’t preserve white space. Serializers can be told no unnecessary white space
… which avoids html and xml problem and allows us to be relatively immune. Ordering may be different but …
… parsers aren’t required to be order preserving, so literals from 2 parsers might not compare. We could state that they appear
… equivalent as objects in testing infrastructure.
… so we just need to state that values aren’t stored without extra white space.

Ivan Herman: not sure that specification should require that when not a question of testing.

Ivan Herman: question is whether it is up to us to define when two pieces of JSON are equal

Ivan Herman: we can be very pragmatic and say that someone else has to take care of this.

Gregg Kellogg: I think we need to say something about this. We need to say something about how that serialization is performed.
… we need to say how you create that string from the objects.

Adam Soroka: consider the case of GeoJSON …

David I. Lehn: is there another solution than complete serialization?

Rob Sanderson: Use case p168 property has range rdf literal with all sorts of possible values, but you can’t add a json literal because there is no id.
… if we want to make it easy for authors to do the right thing, then json as (readable) json is what is needed.

Harold Solbrig: http://build.fhir.org/medicationexample0301.json.html

Harold Solbrig: http://build.fhir.org/medicationexample0301.ttl.html

Rob Sanderson: spec above is completely silent about html canonicalization
… we aren’t adding a new problem, but just another type that doesn’t define canonicalization

Rob Sanderson: can we punt on it and say will be canonicalized when there is a canonicalizatin spec for json?

Ivan Herman: in publishing we put out jsonld not for any reason except it has been accepted by schema.org
… any author who cares about being found by schema.org will put it in jsonld vs. json literal

David Newbury: this will allow people to progressively add semantics vs. having to do everything up front

Benjamin Young: doing this without canonicalization is painfully naive and dangerous. If isn’t consistent between python and js…
… we’re just asking for a world of pain.

Rob Sanderson: question is the extent to which … (if we don’t do complete canonicalization…) … are we doing a better or worse job than nothing?

Gregg Kellogg: coming around to saying it is undefined until spec exists.

Gregg Kellogg: signature specs will need to call out some canonicalization spec or define one that should be used by jsonld processors …
… suggest that canonicalization of jsonld literals is not supported, so can’t sign graphs that contain it…

David I. Lehn: is there a way to know which ones aren’t supported?

Ivan Herman: no because anyone can define a datatype in an RDF graph.

David Newbury: unless codepaths do unicode canonicalization, we’ve still got issues…

Ivan Herman: are there good reasons to do this in jsonld?

Ivan Herman: do we want to have json literals or not?

David I. Lehn: I’m worried about people misusing it but…

Gregg Kellogg: if there WAS a standard for it, we’d say it must be in that form …

Rob Sanderson: there are many terrible things people can do today. I’m highly reluctant to use “it could be misused” as a good reason to not do something.

David Newbury: when we talk about misuse, do we mean security or misuse of RDF in the world (decreasing the amount of semantics in the universe)

Ivan Herman: From a W3C perspective… what we could do is put this into the document w/ a note that says it could be done but we want to have…
… feedback from the community that we are not sure that it is a good idea and seek input.

Gregg Kellogg: we did something like this in spec w/ bnode identifiers and document base url …

Jeff Mixter: reason that WikiData chose JSON rather than JSONLD … they may have opinions about injecting into … document.

Proposed resolution: Add JSON data type to RDF, with support in JSON-LD processors for managing parsed JSON in the internal form. We will seek feedback via blogpost, and in Berlin. (Rob Sanderson)

Ivan Herman: +1

Gregg Kellogg: +1

Rob Sanderson: +1

David Newbury: +1

Jeff Mixter: +1

David I. Lehn: +0.9

Harold Solbrig: +1

Resolution #8: Add JSON data type to RDF, with support in JSON-LD processors for managing parsed JSON in the internal form. We will seek feedback via blogpost, and in Berlin.

5. Agenda review for tomorrow

6. Issue #33

Rob Sanderson: how to shorten the compaction path

Ivan Herman: (API Issue)

Rob Sanderson: this has gone away from our use cases because we said that everything needs a type

Gregg Kellogg: this might be useful for compaction and to help keep a consistance to the data - the @none

Rob Sanderson: would be useful for indexing in ES or Solr

Rob Sanderson: so let us undefer it and talk about it tomorrow

7. Resolutions