JSON-LD Working Group F2F meeting — Second day — Minutes

Date: 2019-02-08

See also the Agenda and the IRC Log

Attendees

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

Regrets:

Guests:

Chair: Rob Sanderson

Scribe(s): Jeff Mixter, Harold Solbrig, Adam Soroka, David Newbury


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:

Simon Steyskal: whiteboard link https://docs.google.com/document/d/1FcbySJzY5QyBW6HcCtO0LCUmppgIJqQzv565BqC5bOU/edit?pli=1#heading=h.vjeyyuqsyju9

1. Sealing … again

Pierre-Antoine Champin: not ok with the decision with context null being able to wipe everything. It is brittle and using a nested context that could have null. It is not necessary to seal terms
… we are overwriting context null
… solution is to separate the functions and create a new keyword that can be used to unseal all of the current sealed terms. @unseal no would unseal all terms for example
… sealed terms would not be touched
… a third benefit would make it easier to deal with the situation where you import a sealed context

Ivan Herman: what this means is that a context null wipes out everything except what is sealed?

Pierre-Antoine Champin: no opinion on how this would function but sealed terms would not be affected

David Newbury: for the use case where you have an area in the document we would need to use unsealed and context null

Rob Sanderson: you could unseal everything and adding null to blow everything away

Gregg Kellogg: is you see the @seal today it would have problems

Ivan Herman: this is very similar to the extension conversation we had yesterday

Pierre-Antoine Champin: this is a separation of concerns to unseal terms and/or wipe the context

Ivan Herman: yesterday we came to this a realized that we do not have a real use case for this

Ivan Herman: if you look at the examples at the end we decided to seal individual terms so in the current proposal we should rather look being able to unseal individual terms

Gregg Kellogg: there is the asymmetry of unseal and seal - unseal unseals everything. This need does not seem to exist in the wild.
… not in favor of doing this

Pierre-Antoine Champin: agrees that the syntax is a bit odd but regarding the use cases from yesterday we were looking for a way to unseal the entire context. the use case here is when you encounter random sealed contexts in the wild

Gregg Kellogg: if we allow you to fix wild sealed contexts we lower the need/concern to get the use of seal correct
… better option is to have the community decide what should be sealed

David Newbury: if we provide a mechanism to unseal sealed context that defeats the original point of this issue

Adam Soroka: thought is was more of a strong suggestion to not unseal not a restriction to unseal

Pierre-Antoine Champin: my concern about context null we are defeating the reason for seal but in a more sneaky way. this proposal clearly defines what we are doing and can imply why we are doing it

Gregg Kellogg: wanted to note that we can not expect sanctity around contexts sealed, unsealed, null, etc
… more comfortable with context null

Rob Sanderson: also prefer context null because it raises the stakes for the user as opposed to just unsealing the terms. with null, you need to start all over

Adam Soroka: if you want to unseal the context terms, you need to know all of the terms to unseal but if you can unseal at the context level
… it is not a huge problem

Ivan Herman: we should put in a proposal and move on

Rob Sanderson: sounds like we prefer the decision from yesterday

Proposed resolution: After discussion, we agree on no change to sealed contexts from yesterday (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Pierre-Antoine Champin: +1

Harold Solbrig: +1

Jeff Mixter: +1

Ivan Herman: +1

David I. Lehn: +1

Simon Steyskal: +1

Resolution #1: After discussion, we agree on no change to sealed contexts from yesterday

2. adding metadata to contexts

Rob Sanderson: github: https://github.com/w3c/json-ld-syntax/issues/108

Rob Sanderson: from the discussion around sealing
… beyond being able to seal we want to check if a context has changed
… you should be able to annotate the context to know its version or a checksum to test it
… there is a spec that already does this SRI
… a 1.1 processor could use this to see if a context has changed and if so do something

Simon Steyskal: link to SRI https://www.w3.org/TR/SRI/

Ivan Herman: originally this type of feature was based on the desire to create a helping hand for implementations that want to use caching for contexts
… this is also what SRI is used with in HTML

Ivan Herman: -> https://github.com/w3c/json-ld-syntax/issues/108#issuecomment-460201634 another syntax

Ivan Herman: as an alternative we could have data that points to the nearest stored version of the context similar to how CSS works
… extra metadata for the context could be added and might be useful

David Newbury: how is this related to hash links?

Ivan Herman: SRI is around and tested
… for SRI it is an existing implementation feature in HTML so all we have to so is refer to the SRI documentation

Benjamin Young: question the value of encoding this in the context
… concerned about adding all of the metadata for contexts into the context

Rob Sanderson: spec: https://tools.ietf.org/html/draft-sporny-hashlink-02

Benjamin Young: msporny’s write up of hashlink’s value to JSON-LD (and friends) https://lists.w3.org/Archives/Public/public-json-ld-wg/2019Jan/0000.html

Gregg Kellogg: this seems like we are in the HTML domain based on the use cases
… like the idea of pathing but feel like we should not bake that into the standard

Benjamin Young: +1 to gkellogg’s thoughts

Harold Solbrig: this seems like a general problem not specific to JSON-LD

Rob Sanderson: against hashlinks because it is not normative. This is not prohibited but we do not need to explicitly say so. Do not want to focus just an a HTML approach

Adam Soroka: maybe we could offer best practices

Rob Sanderson: +1 to best practice note

Adam Soroka: should we kick this issue up for the broader community to discuss

Ivan Herman: do not see the relation to HTML as relevant. For SRI all we need is a clear definition of what the hash value we are using is referring to

Adam Soroka: do we need to specify what to do with the hash value

Ivan Herman: no

Adam Soroka: is this a protocol level question?

David I. Lehn: the readability could be a concern

Rob Sanderson: reliance on the http headers seems not feasible. Since a document can load in multiple contexts where should that information be stored and acted upon.

Gregg Kellogg: if the integrity checking is not done on the processor than it will not work

Harold Solbrig: this is another feature we are adding to JSON-ld
… what do we gain for adding this into the spec?

Ivan Herman: if you want to help folks that are on a bad network connection - this could solve that problem.

Harold Solbrig: what about support for current integrity versioning approaches that work and are used?

David Newbury: to implement this we will need to add a third way to reference contexts

Ivan Herman: we could defer this because it opens a lot of questions that we would need to address

Ivan Herman: what do say to the folks that have this problem now
… we do not have anything in our spec to address this use case concern

Gregg Kellogg: this is a resource caching issue and there is ways to solve this currently

David Newbury: is we allow metadata in context - we could also rethink adding documentation in the context

Adam Soroka: is integrity also part of the concern?

Ivan Herman: there are a few reference implementations. They should try to implement the best possible caching control and see how it work and document how to do it

Ivan Herman: all of these implementations should serve as examples on how to solve this problem

Benjamin Young: current CG “best practice” for caching https://json-ld.org/spec/latest/json-ld-api-best-practices/#cache-context

Rob Sanderson: the issue of integrity is related to versioning - want to ensure that the contexts that are being loaded are not mutable

Harold Solbrig: this is sort of what http expire headers are used for

Harold Solbrig: if we did SRI we would need to explain how it works and what to do with it

Rob Sanderson: we should propose that this is an issue but we are not the folks to deal with it

Ivan Herman: agreed but we might want to also say that we will be more rigorous about documenting how implementors do this

Proposed resolution: Defer the integrity/context metadata related issues, and request early horizontal review from security, privacy and TAG. (Rob Sanderson)

Ivan Herman: +1

Gregg Kellogg: +1

Jeff Mixter: +1

Rob Sanderson: +1

Simon Steyskal: +1

Benjamin Young: +1

David Newbury: +1

Pierre-Antoine Champin: +1

Resolution #2: Defer the integrity/context metadata related issues, and request early horizontal review from security, privacy and TAG.

3. “itemref”, issue 19

Rob Sanderson: issue occurs when resource occurs multiple times in the graph. What would be nice that if you knew that terms got used repeatedly…
… would be nice if you had references from the inclusion to included. JSON API calls it “included”
… JSON Schema has $ref.

David Newbury: https://jsonapi.org/format/1.1/#document-top-level

David Newbury: an example of it in the JSON-API spec is here: https://jsonapi.org/format/1.1/#document-compound-documents

Rob Sanderson: useful in graph context so you can use references rather than values
… is this a frame issue or syntax? We decided both - could go into framing to know that “included” is not a predicate, it is the inclusion
… references block rather than <base#>included.

Gregg Kellogg: did you consider the RDFa approach, where there is a way to output triples where after parsing there is a reasoning step?

Ivan Herman: I thought that was more directly done…

Gregg Kellogg: … that was microdata. RDFa is more directly — reasoner takes triples and outputs w/ different subject.

Jeff Mixter: is there a way to solve this with @graph?
… I have a first block of JSON which is object outside of a graph and add subgraphs with aliased keyword

Ivan Herman: this is mixing levels — syntax is similar but this is not a graph

Gregg Kellogg: inverse properties? Included have reverse relationships to items that are included
… is classificaton_of is at term that is an @reverse – achieves separation of concerns but also includes expanding, compacting and framing for round trip

Rob Sanderson: would still need an @nest property.

Ivan Herman: there are two ways to look at this:
… 1) enum:c6 is an internal reference that we could handle with fragment id in graph, but I have an extra triple in the graph …
… you get extra links
… 2) conceptually expect value of enum:c6 to be physically replicated and put back into the node
… itemref did the replication option
… JSON Schema creates a fragment identifier, but is this what you are looking for?

David Newbury: our use case is the latter case
… because in a JSON only environment, knowing where to go is difficult.

Ivan Herman: Option 2) requires duplication and massaging in graph…

Rob Sanderson: gregg’s proposal w/ included : {"@container": "@id"} (sort of) works

Ivan Herman: included should be a nest

David Newbury: how do I get option 2) (included under classification)?

Gregg Kellogg: we’d still need an inverse thing. If I have an id map but want to say it is sort of transparent…

Ivan Herman: if a term is defined to be @nest, does @id still work or do you ignore that once and for all?

Gregg Kellogg: @nest allows me to use an intermediate property to hold things which are pushed up. We want subtree to be somewhere else

Ivan Herman: if included is @nest, is @container: @id still valid?

Gregg Kellogg: round tripping is an issue as well.

Benjamin Young: posted playground example above that uses “embedded”. Seems to do what you want. Note that “included” is an array in
… json API not an object. Also introducing a non-JSON reference mechanism

Ivan Herman: what you do is define a graph, not the content of the graph

Rob Sanderson: there is a blank node _:b0 which has a name and a type

Gregg Kellogg: use a preprocessing tool or do it the way RDFa does it?

David Newbury: I could do this but it wouldn’t be valid JSON-LD …

Gregg Kellogg: It would be, but it wouldn’t be the graph you are looking for

Harold Solbrig: (discussion about examples on FTF document… w/ @nest and rather than containing , references object…)

David Newbury: in practice we use @id in our main document and use a placeholder in data, but requires an addition piece of semantic ata

Pierre-Antoine Champin: 2 questions. 1) Do we agree that the enum term should be defined as well? (a: yes)
… 2) is "@type": "@nest" the way it would be written? (a: no)

Rob Sanderson: nest: https://www.w3.org/TR/json-ld11/#ex-65-defining-property-nesting

Gregg Kellogg: could handle it with n3 reasoning?
… it seems like we are trying to do things at a totally different level.

Adam Soroka: one other wrinkle … this would play oddly with a streaming processor.

Gregg Kellogg: this is the reason we did rdfa the way we did

Ivan Herman: in rdfa we define terms and additional semantic rules, which is what we do here.

Gregg Kellogg: it has already been done, we could just reference it.

Gregg Kellogg: https://www.w3.org/TR/html-rdfa/#property-copying

Ivan Herman: done through RDF, but way too complicated…

Pierre-Antoine Champin: reminds me of the very first version of RDF rdf:aboutEach

Rob Sanderson: http://tinyurl.com/ydgfcgl4

Harold Solbrig: (azaroth using playground example between jane and john…)

Ivan Herman: copying vs. referencing. We can say that copying stuff is outside json-ld.
… reference, however, might be doable. What do we need to make the example on the screen (enum:c6, … in issue #19) work
… . included is there because of bookkeeping. The approach feels natural
… if included is nested, you take it out of the equation altogether…

Rob Sanderson: needs to be a new syntax ("@id": "@nest"?)

Simon Steyskal: works as expected on playground but @id: @nest doesn’t work

Pierre-Antoine Champin: https://json-ld.org/playground-dev/#startTab=tab-nquads&json-ld=%7B%22%40context%22%3A%5B%22http%3A%2F%2Fschema.org%2F%22%2C%7B%22labels%22%3A%7B%22%40id%22%3A%22%40nest%22%7D%7D%5D%2C%22%40type%22%3A%22Person%22%2C%22labels%22%3A%5B%7B%22familyName%22%3A%22Doe%22%7D%2C%7B%22givenName%22%3A%22Jane%22%7D%5D%7D

Gregg Kellogg: is there a way through @nest to subsume @graph while defining a bush

Gregg Kellogg: today, nesting requires the object

Gregg Kellogg: There’s obviously work to be done…

Rob Sanderson: how much?

Gregg Kellogg: (waffles and ponders…) involves extending id of nesting… there a lot of angles to this, man.

David Newbury: to clarify, we’re not addressing framing right now, correct?

Ivan Herman: workergnome – is this approach still ok? Does it accomplish what you want?

Proposed resolution: Continue to explore @nest with additional features, such as @container:@id, as a solution to issue #19 (Rob Sanderson)

Ivan Herman: +1

Simon Steyskal: +1

Rob Sanderson: +1

Jeff Mixter: +1

Harold Solbrig: +1

Gregg Kellogg: +1

David I. Lehn: +1

Adam Soroka: +1

Pierre-Antoine Champin: +1

David Newbury: +1

Resolution #3: Continue to explore @nest with additional features, such as @container:@id, as a solution to issue #19

Benjamin Young: +1

Action #1: explore effect of @nest+@container:@id on compaction and expansion (Gregg Kellogg)

Action #2: explore effect of @nest+@container:@id on compaction and expansion (Pierre-Antoine Champin)

4. YAML? CBOR?

Simon Steyskal: charter https://www.w3.org/2018/03/jsonld-wg-charter.html

Rob Sanderson: [quotes from charter]

Ivan Herman: I have no idea how that got there
… i.e. who wanted that there

Gregg Kellogg: there was some yaml-ld out there
… but CBOR is more interesting

Rob Sanderson: CBOR: http://cbor.io/

Benjamin Young: YAML: https://yaml.org/

Ivan Herman: we should ignore the complexites of CBOR
… that go beyond JSON

Gregg Kellogg: support for native types in CBOR would be useful if we do CBOR

Benjamin Young: the CBOR idea is more complicated, but more valuable
… the broader question is whether someone intends to process this kind of stuff w/o conversion to JSON first

Ivan Herman: tbc, we cannot publish a recommendation on this, but we can publish a note

Benjamin Young: CBOR is important in the space of crypto, signing, etc.

David I. Lehn: YAML has a lot of advanced features, e.g. linking, a type system
… that’s all interesting, but it doesn’t match JSON-LD at all
… that feels like a different spec

Gregg Kellogg: we could offer spec text such that the native types could be extended
… we might be bale to provide an extension model for that

Ivan Herman: we are a small group
… anything we have here requires ownership from someone
… if I have to choose, the one that has a market is CBOR
… much as I like YAML, it has a small usage

David I. Lehn: YAML is used a lot for configuration

Ivan Herman: just trying to be realistic

Harold Solbrig: bioinformatics and biology used the heck out of YAML, not so much JSON

Ivan Herman: do we have someone who will own this?

Rob Sanderson: Is anyone willing to own a document that describes the relationships between these languages

Harold Solbrig: there may be interest from my group, let me check into it

Ivan Herman: if we can do one, we should do CBOR! It’s binary.
… we would get a binary format for free

Ivan Herman: has anyone tried conversion to see what the gain is?

Adam Soroka: [discussion of potential space gains]

Simon Steyskal: http://cbor.me

Adam Soroka: [discussion of CBOR]

Rob Sanderson: we can put some priorities into the various notes documents we’ve discussed
… the community would benefit much more from the primer than anything about YAML

Adam Soroka: [general agreement]

Ivan Herman: There is also http://cbor.io/ for the spec and overview

*Proposed resolution: Defer CBOR / YAML / * -LD until primer document is under way ; hsolbrig to investigate if he can be editor for *-LD** *(Rob Sanderson)

Rob Sanderson: +1

Adam Soroka: +1

Simon Steyskal: +1

Harold Solbrig: +1

Gregg Kellogg: +1

David I. Lehn: +1

David Newbury: +1

Ivan Herman: +1

Resolution #4: Defer CBOR / YAML / * -LD until primer document is under way ; hsolbrig to investigate if he can be editor for *-LD

Rob Sanderson: we have completed our agenda, which other issues shall we tackle?

Rob Sanderson: project: https://github.com/orgs/w3c/projects/4

5. Issue Triage

5.1. Feature Detection in JSON-LD Processors

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

Gregg Kellogg: Close won’t fix for #33?

Rob Sanderson: +1 to close wontfix, due to lack of time and the extent of the new work

Gregg Kellogg: this would injure interoperability

Rob Sanderson: agreed
… and it’s a big ask to prescribe all the features

Ivan Herman: do we close it? or defer it?

David I. Lehn: This was a while ago
… we were coming up with lots of features

Gregg Kellogg: and then mediatypes have been used for just this

David Newbury: I would happily close
… this kind of version inspection– the complexity outweighs any benefit
… we want to put the burden on implementors, this does the opposite

David I. Lehn: one place this might help is with something like JSON literals,

Rob Sanderson: that goes right to the interop question

Gregg Kellogg: the reason we needed @version is to make a 1.0 processor die because it would not check the range of various keys
… which we’ve tightened up in 1.1.
… we used to leave that open
… so adding something more specific to @version would be gratuitous, in that sense

Ivan Herman: why would this help the user?
… I don’t care about the devs– they will manage
… but this will complicate life for the users!
… I don’t see who would gaim

Proposed resolution: Close #33, wontfix. Extension mechanism is just to add features to the context that a processor does not understand. (Rob Sanderson)

Ivan Herman: +1

Gregg Kellogg: +1

David Newbury: +1

Jeff Mixter: +1

Rob Sanderson: +1

Simon Steyskal: +1

Harold Solbrig: +1

ajs6f>ajs6f: has joined #json-ld

ajs6f>: <ajs6f>+1

Resolution #5: Close #33, wontfix. Extension mechanism is just to add features to the context that a processor does not understand.

5.2. Streaming Profiles for JSON-LD to/from RDF

Rob Sanderson: ref: https://github.com/w3c/json-ld-api/issues/5

ajs6f>gkellogg: there are savings to be realized if one could spec a profile for streaming

Gregg Kellogg: this profile would say, “to be streamed, a JSON_LD serialization would need to have the following characteristics

Ivan Herman: analysis of the format with this in mind

Ivan Herman: I’d say defer
… this might be interesting enough that someone might publish something before this WG ends

Gregg Kellogg: we could publish something that invites people to work on this

Proposed resolution: Streaming is interesting, but not high priority for work given current participants ; highlight in a blog post (Rob Sanderson)

Gregg Kellogg: +1

Adam Soroka: +1

Rob Sanderson: +1

Benjamin Young: +1

Simon Steyskal: +1

Ivan Herman: +1

David I. Lehn: +1

Jeff Mixter: +1

Harold Solbrig: +1

David Newbury: +1

Resolution #6: Streaming is interesting, but not high priority for work given current participants ; highlight in a blog post

5.3. Define media profile for frames

Adam Soroka: https://github.com/w3c/json-ld-framing/issues/21

Adam Soroka: https://github.com/w3c/json-ld-framing/issues/28

Gregg Kellogg: the framing document that did not become a rec has a mimetype in it
… but that was a bad idea– we have profiles!
… we have a profile param that identifies a context
… we don’t require that the context be published with that profile
… should we require that of frames?
… you might want to do that because frames use different keywords

Rob Sanderson: if you push a frame document into a regular JSON-LD proc, it should beef

Gregg Kellogg: [describes framing in general]

Rob Sanderson: ref: https://www.w3.org/TR/json-ld11-framing/ ;)

Ivan Herman: gkellogg: should this be a profile or a separate mediatype?

Ivan Herman: a mediatype points to a specific document that describes that mediatype. those docs are different in this case, so the mediatypes should be different

Gregg Kellogg: using the parameter would allow us to negotiate for a context

David Newbury: thinking about the IIIF use case, being able to request docs as either a context or a frame

Gregg Kellogg: if you reference a context but it comes back as a frame, you could change you inx model to account for that

David Newbury: IIIF use a “context” as we use a “profile”, e.g. to include a version
… but that seems okay because we could do it either way

Gregg Kellogg: we describe the behavior of downloading a context and we would need to account for this there.

Ivan Herman: if you don’t register a new mediatype for frame, we will have to change our docs, so which one requires more work?

Rob Sanderson: if we say separate mediatype, we need tests for that
… frames out there in the wild would now fail

Rob Sanderson: if that is decisive, we should rec that a profile SHOULD be used
… to avoid that

Proposed resolution: Use ld+json with a profile for media type of frames, import frame keywords to syntax with reference out. (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Harold Solbrig: +1

Gregg Kellogg: +1

Simon Steyskal: +1

Adam Soroka: +1

David I. Lehn: +1

Jeff Mixter: +1

David Newbury: +1

Benjamin Young: +1

Resolution #7: Use ld+json with a profile for media type of frames, import frame keywords to syntax with reference out.

Proposed resolution: the use of the media type for a frame is RECOMMENDED not a MUST (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Adam Soroka: +1

Gregg Kellogg: +1

Simon Steyskal: +1

David Newbury: +1

David I. Lehn: +1

Harold Solbrig: +1

Resolution #8: the use of the media type for a frame is RECOMMENDED not a MUST

Jeff Mixter: +1

5.4. URL-s vs. IRI-s

Ivan Herman: https://github.com/w3c/json-ld-syntax/issues/25

Proposed resolution: Close syntax #25 wontfix, we stick with IRI rather than using URL (Rob Sanderson)

Gregg Kellogg: +1

Adam Soroka: +1

Rob Sanderson: +1

Ivan Herman: +1

Harold Solbrig: +1

David Newbury: +1

Simon Steyskal: +1

Benjamin Young: +1

Jeff Mixter: +1

Resolution #9: Close syntax #25 wontfix, we stick with IRI rather than using URL

5.5. Relax the colliding keywords constraint for @type

Rob Sanderson: ref: https://github.com/w3c/json-ld-api/issues/4

Gregg Kellogg: there is no identified use case for this

Rob Sanderson: the complications outweigh any benefit

Proposed resolution: Close api#4 wontfix, use case is covered with scoped contexts, and no other known use cases to justify the complexity (Rob Sanderson)

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: +1

Jeff Mixter: +1

Adam Soroka: +!

Harold Solbrig: +1

Benjamin Young: +1

Simon Steyskal: +1

David I. Lehn: +1

David Newbury: +1

Resolution #10: Close api#4 wontfix, use case is covered with scoped contexts, and no other known use cases to justify the complexity

5.6. Term definitions in context that support multiple values for @type?

Rob Sanderson: ref: https://github.com/w3c/json-ld-syntax/issues/121

Rob Sanderson: this came out of the sealing discussion
… timc notes that schema.org has properties that take either text or resource
… should we be able to say that a property accepts either type A or type B but not type C

Gregg Kellogg: schema.org should have different properties for differently-typed values

Ivan Herman: not really practical for schema.org users

Rob Sanderson: you can rep this in the instance doc itself, inline
… I say close won’tfix because it is unambiguous but ugly

Gregg Kellogg: e.g. if you have a property ‘author’ it could have values of many different types

Rob Sanderson: validation is not JSON-LD’s job, just mapping

Ivan Herman: in the context of schemo.org, can they properly define that something is say, a resource or a text?/

Ivan Herman: is it a case of “if it can be parsed as a URI it should be treated as such”?

general: no, that’s too error-prone

Ivan Herman: they (schema.org) have a canonical order of expectation

Gregg Kellogg: and schema.org doesn’t really use linked data

Proposed resolution: Close #121 wontfix, as the solution that isn’t ambiguous is very very complicated (Rob Sanderson)

Ivan Herman: +1

Adam Soroka: +1

Rob Sanderson: +1

Gregg Kellogg: +

David Newbury: +1

David I. Lehn: +1

Benjamin Young: +0 (missed most of the debate)

Gregg Kellogg: also http://linter.structured-data.org, which does it’s best to figure it out.

Gregg Kellogg: +1

Jeff Mixter: +1

Resolution #11: Close #121 wontfix, as the solution that isn’t ambiguous is very very complicated

Harold Solbrig: +1

5.7. Option to specify level of compaction for literals & resources

Rob Sanderson: ref: https://github.com/w3c/json-ld-api/issues/33#

Rob Sanderson: https://github.com/w3c/json-ld-api/issues/33#issuecomment-418518683

Gregg Kellogg: what happens if you see data that’s a string? Answer: you won’t.
… but the alg. has to do something.
… provide a way to compact a document that does IRI compaction (aka turn IRIs into terms/compact IRIs) probably to reduce the use of arrays so you don’ t use it unless you need it.
… so we would always have objects with @id and @value. If they were aliased, it would be that, etc, etc.
… so the question that Rob raised is what if you see an input that has @value that looks like a URI, and that has @type: none. What would happen?
… this wouldn’t happen, because you’d expand that makes this unambiguous. But what id you did?
… I would say that you’d probably treat these as strings.

Rob Sanderson: I agree

Adam Soroka: It seems that it’s a little surprising, but this should be explained clearly, since it can be counterintuitive.

Gregg Kellogg: and where does this go?
… it’s not really part of the syntax.
… that matters in compaction, but to an author, I don’t think that @none has an effect, because it only matters in context evaluation
… the syntax document leaves the rules to the API document

Ivan Herman: I would welcome this into the syntax document
… people don’t read the API document.

Gregg Kellogg: but it’s not useful to understand the syntax, but only the operation of the compaction

Ivan Herman: if there are ways to control compactions, I should know them in the API document

Adam Soroka: does this go in the primer?

Gregg Kellogg: when you’re reading an document, and you see an embedded context, you get the mental model of what expansion does. Similarly, when compacting, you get the idea of how to turn an ID into a string.
… you can understand the mental model.

Ivan Herman: where is that documented?

Gregg Kellogg: there’s an incomplete description in the syntax document, and a full description would make the syntax document even MORE complicated.

Adam Soroka: Can we put a note in somewhere?

Gregg Kellogg: we need a note for it now

Rob Sanderson: let’s see what the documentation looks like

Gregg Kellogg: agreed, and someone should read through it and see what’s missing.

Adam Soroka: ajs6f: +1 to responding to something concrete

Gregg Kellogg: framing is a different, since it embodies more.

Proposed resolution: Use @type:@none to force compaction to generate object values ; Ivan and Adam will review for understandability (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Jeff Mixter: +1

David Newbury: +1

Ivan Herman: +1

Adam Soroka: the primer should talk a lot about shapes.

Adam Soroka: +1

David I. Lehn: +1

Harold Solbrig: +1

Resolution #12: Use @type:@none to force compaction to generate object values ; Ivan and Adam will review for understandability

5.8. Provide an option for all terms to get a default "@container"

Rob Sanderson: ref: https://github.com/w3c/json-ld-framing/issues/31

Gregg Kellogg: I had discussed putting in a default container set unless set otherwise.
… which is less disruptive than the graph id
… not a framing issue, but a compaction issue

Rob Sanderson: just a convenience mechanism
… is the value of this higher enough to warrant a new default?

Gregg Kellogg: can’t be done in framing, must be in compaction.
… is it valuable enough?

Ivan Herman: this is what schema would do. They are very systematic in mapping this.
… this will make schema.org will get there automatically

Gregg Kellogg: currently, list and set are incompatible, though we’ve discussed this.

David Newbury: .. one used to be ordered, and one unordered…but we’ve overridden that already.

Rob Sanderson: for this issue, if you were to set a default container at @language

Gregg Kellogg: that would be scary. Everything would be a language map.
… and you’d have to define that.

Rob Sanderson: if you snuck this away…

Rob Sanderson: how would you undo this if it was @set?

Gregg Kellogg: … empty array? @container: null?

Rob Sanderson: in my opinion, the value is outweighed by the danger

David Newbury: I don’t think that we need better ergonomics for creating contexts…

Rob Sanderson: so we propose that this is valuable, but can they provide more use cases other than it being a bit redundant?

Proposed resolution: push back to original commenter, asking for more use cases. Saving context authors some keystrokes is not a high priority (Rob Sanderson)

David Newbury: +1

Jeff Mixter: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: …

Proposed resolution: Close framing #31, wontfix, with request for further discussion if they can provide more information to support its inclusion (Rob Sanderson)

David Newbury: +1

Rob Sanderson: +1

Ivan Herman: +1

Jeff Mixter: +1

David I. Lehn: +1

Action #3: put comment in to #31 requesting more info (Rob Sanderson)

Gregg Kellogg: +1

Harold Solbrig: +1

Resolution #13: Close framing #31, wontfix, with request for further discussion if they can provide more information to support its inclusion

5.9. TriG graphs in JSON-LD

Rob Sanderson: ref: https://github.com/w3c/json-ld-syntax/issues/128

Gregg Kellogg: The concern is that TRiG does not use the value, insomuch as it’s just a set of graphs, names, etc, where JSON-LD has the object being the name of something in the default graph.

Ivan Herman: that’s what the issues says. What dave put in is a solution that technically works. It’s awful, and you can put in a fig leaf by aliasing @graph, but…
… what did come up is that Pierre Antoine put in a proposal for a solution and the syntax was wrong, but the way that it is now after our discussion this morning it probably works, but it is consistent.
… what he has here will work once we’ve done the cognates.
… that’s the figleaf

Gregg Kellogg: I like that more than one problem is solved with a single solution

Rob Sanderson: should we validate that it expands correctly one the fixes are in?

Gregg Kellogg: something might expand oddly…

Ivan Herman: expanding is for machines. I don’t care. But for humans, what P.A. has put in is fine.

Proposed resolution: Verify that @nest solution for #19 solves issue in #128 and defer until then (Rob Sanderson)

David Newbury: +1

Jeff Mixter: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Ivan Herman: +1

Rob Sanderson: we should make sure it’s solved before closing

Harold Solbrig: +1

David I. Lehn: +1

Resolution #14: Verify that @nest solution for #19 solves issue in #128 and defer until then

Adam Soroka: +1

5.10. datasets and graphs

Rob Sanderson: ref: https://github.com/w3c/json-ld-syntax/issues/30

Ivan Herman: I don’t like the way that this is done, but it turned into a philosophical argument, and I can just close it.

Ivan Herman: to clarify, I want to close it because it’s way too late.

5.11. Framing blank node unnamed graphs

Rob Sanderson: ref: https://github.com/w3c/json-ld-framing/issues/27

Gregg Kellogg: how can SHeX validate verifiable claims?
… there was no reasonable way for SHeX to figure out where to start in that graph to begin validation. Why not just reuse the blank node as the default subject of the graph?

Ivan Herman: I remember, and I am opposed to this.

Rob Sanderson: if it was not a blank node, does the problem go away?

Gregg Kellogg: if it had an identity, it wouldn’t get to this point.

Gregg Kellogg: if you use a graph container, should we use the blank node as the default subject for the graph?

Ivan Herman: that’s semantically wrong.

Rob Sanderson: is this a RDF problem?

Ivan Herman: no. A blank node for the graph and a blank node within the graph are two different things.

Gregg Kellogg: JSON people have a tree-based view, and graphs are not required to have a root.
… so it’s not unreasonable to add a property to indicate in the root.

Gregg Kellogg: this is used in framing, where the top node has a id

Harold Solbrig: I object to bnode, because if there’s not a stake in the ground, having magic to b-nodes…

Gregg Kellogg: fragment identifiers would be a better solution.

Proposed resolution: close framing#27 wontfix, as there’s no justification for the required RDF layer requirement that the blank node identity of the named graph is the default subject of the triples in the graph (Rob Sanderson)

Gregg Kellogg: +1

Rob Sanderson: +1

David Newbury: +1

Ivan Herman: +1

Harold Solbrig: +1!

David I. Lehn: +1

Jeff Mixter: +1

Adam Soroka: +0

Resolution #15: close framing#27 wontfix, as there’s no justification for the required RDF layer requirement that the blank node identity of the named graph is the default subject of the triples in the graph

6. Resolutions

7. Action Items