JSON-LD Working Group Telco — Minutes

Date: 2018-09-28

See also the Agenda and the IRC Log

Attendees

Present: Adam Soroka, Gregg Kellogg, Rob Sanderson, Simon Steyskal, Ivan Herman, Jeff Mixter, David Newbury, David I. Lehn

Regrets: Tim Cole, Benjamin Young

Guests:

Chair: Rob Sanderson

Scribe(s): David Newbury

Content:

1. Approve minutes of previous call

Proposed resolution: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-21-json-ld (Rob Sanderson)

Rob Sanderson: +1

David Newbury: +1

Simon Steyskal: +1

Jeff Mixter: +1

Gregg Kellogg: +1

Ivan Herman: 0

Resolution #1: Approve minutes of previous call: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-09-21-json-ld

2. Announcements / Reminders

Rob Sanderson: announcements. TPAC, the standard update, though perhaps we should talk about logistics.
… Rob has filled out the AV requirements, and each room comes with a screen, etc. So we’re OK.
… in the next block, we will have agenda, and we will need to have WEBEX setup.

Ivan Herman: If we need it, I will set up the webex. Are there people who would want to dial in?

Jeff Mixter: that would be helpful for me - won’t be able to attend in person

Rob Sanderson: There are at least two people who might want to dial in.

Ivan Herman: then there will we webex:-)

Action #1: Ivan Herman to set up webex for TPAC

Ivan Herman: The registration will go up on Monday. Do it now.

Simon Steyskal: Asking about the link–we were supposed to write our name somewhere, but I’ve misplaced it? Do we need to do so?

Ivan Herman: link: https://docs.google.com/document/d/1qTLztv7nqbYuUsZbwhPhOyG5tHTJrTt9tGKWnD5Xa5A/edit

3. Logistics

3.1. TPAC Agenda

Rob Sanderson: We need to come up with an agenda.
… Looking at the participants,
… plus up to 20 other people who have not been on a call
… one assumes that some of the observers will drop out, but here is the project link

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

Rob Sanderson: in the gihub project there is a column that is face-to-face where we’ve put some of the more involved or controversial discussions, plus ones where we’ll need external contributors.
… to get those people here, we need an agenda built.
… if we can go over those seven topics, we can do some dragging of little cards around

Gregg Kellogg: two uses cases for content-addressable. Schema.org wants to announce that the context is not downloaded, but pre-compiled in and that would be announcable
… the second would be web of things or similar where there’s background signaling and off-line support, which is the gist of the content-addressable thing
… so you can determine that a side-loaded file is a valid one to use

Rob Sanderson: so we should talk to web of things, and dan

Gregg Kellogg: Dan’s likely there, and I’m sure we can get him to participate

David I. Lehn: Another use case is caching–avoiding having lots of requests if you’ve got a local contact

Gregg Kellogg: we have HTTP caching

Ivan Herman: don’t have to solve it now

Gregg Kellogg: We should know what we’re talking about so we can raise with other people

Ivan Herman: #8 might not be that complicated

Rob Sanderson: it’s there so that the we can align with another working group

Rob Sanderson: There’s a question about #18–absence of being

Gregg Kellogg: this is about null and empty list
… but that’s a non-RDF list
… it’s not really even an OWL thing
… you can talk about carnality, but not null–the pattern language thing is where that gets expressed.

Rob Sanderson: I don’t think it’s a TPAC issue

Gregg Kellogg: it’s not so much emptiness, but RDF-like processing that happens outside of the RDF algorithms, and we’re a bit scattered about it anyway

Rob Sanderson: Those seven are good candidates, and there’s nothing obvious, and we can work our way backwards if we finish those
… oh, six
… I will take on a draft agenda, and reach out to web of things, data exchange, and see if they can be present at any specific time to schedule those ones.
… other things?

Action #2: Rob to draft agenda from issues plus other WG interactions

Ivan Herman: Looking at this, I would expect that it would not completely fill out the two days.
… I think we should discuss how we will attack the issue of testing implementation
… the working group doesn’t have a long charter, so we should be prepared.
… Lots from previous working group, and I don’t remember when the CR is to be published, but this might be the last face-to-face before that, and we should have an agreements about this beforehand.
… we can at least start that conversation in person.

Gregg Kellogg: We’ve also talked about other publications, non-normative ones, say, and splitting them, and we could talk about YAML, HTML, Named Graphs, and are pretty-large in our documents

Ivan Herman: And I think that we’ve chatted about reorganizing the documents…

Gregg Kellogg: we’ve accomplished that already

Rob Sanderson: Manu will be there, and we can talk about the blank node issues

Gregg Kellogg: if we can target, we can coordinate a time to talk about that, since he’ll be there.
… maybe find a time to do a joint session between us and Verifiable Claims?
… or just crash their meetings
… and I think we’re going to need to be increasingly needing to raise the “more implementations” issue

Rob Sanderson: that’s a good set of things, and I’ll circulate on the mailing list

Rob Sanderson: anything else TPAC?

3.2. Echidna publishing

Rob Sanderson: OK. Moving onto publishing
… This is the tool that lets up publish to W3C site with less hassle.
… particularly without more systematic process for the first working draft.

Ivan Herman: You’ve seen what this means for the first working draft
… there are some details that we have to work out, but the goal is that we will have a separate branch in each repo and if we commit, there is a CI process that will create a new version of the specs
… there are groups that do that frequently (every draft) and what usually happens is that each equilibrium point, t here is a draft. This is a good example–it would be acceptable to do a publication right now, since it’s better than what’s out there now.
… formally, we need a resolution for that.
… to do an automatic publishing through the tool so he can get the API keys and the like.

Rob Sanderson: do we have enough background on this?

Proposed resolution: We will use echidna publishing WDs for all three rec track documents (Rob Sanderson)

Rob Sanderson: +1

David Newbury: +1

Jeff Mixter: +1

Gregg Kellogg: +1

Simon Steyskal: +1

Adam Soroka: +1+1

Ivan Herman: +1

David I. Lehn: +1

Resolution #2: We will use echidna publishing WDs for all three rec track documents

Ivan Herman: I’ll get that set up next week.

Action #3: Ivan Herman to get the echidna API codes

4. New Issues

4.1. Fragment identifiers with “:”

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

Rob Sanderson: moving on to issues
… This was discovered as a bug over the past day
… We’ve been discussing it, and it’s valid to have : in fragment ids, some we need to fix this in the spec

Gregg Kellogg: I think that issue is that JSON-LD does not have a syntax for compact IRIs vs. URLs like RDFa so you can recognize prefixes vs. what is a URI scheme
… in this case, this is a bug
… since the pound sign is not a scheme, and it’s not a defined term
… if it were, there wouldn’t be a concern.
… the case we’re running across is that #test and #test:2 the first is a relative URI, since it’s interpreted as a ID
… so it’s a IRI or a document-relative IRI. The second case, it could be a compact IRI or an absolute IRI
… by tightening up the language, it must either match a term or the scheme production and a hash test would not match that production
… but there are other corner cases
… where there are other places where the hash sign may occur
… we need to come up with more breaking cases and tests
… what about a:b where the base includes a hash?
… a does match the production of the scheme, and could be an absolute IRI

Rob Sanderson: so long as it’s deterministic, but it’s these cases where it’s legal, but not permitted according to the algorithm where there’s the issue
… for fixing it, have we tried it?

Gregg Kellogg: I haven’t fixed it, but I think it’s straightforward if we tighten up what a URI scheme is

Rob Sanderson: We can fix this in 1.1, but we should also errata 1.0

Gregg Kellogg: I think we should not change the requirements, but highlight the issue

Ivan Herman: has it yet been submitted in the errata list?

Gregg Kellogg: no

Ivan Herman: We should document it
… editorially, when we have the list of changes, we should make a reference to the errata so we can change 1.0 because it’s a bug

Proposed resolution: Accept the bug, submit errata 1.0 and fix in 1.1 by tightening the definition of a URI scheme (Rob Sanderson)

Ivan Herman: this is explicit in our charter

Gregg Kellogg: +1

Adam Soroka: +1

Ivan Herman: +1

Rob Sanderson: +1

David Newbury: +1

Jeff Mixter: +1

David I. Lehn: +1

Simon Steyskal: +1

Resolution #3: Accept the bug, submit errata 1.0 and fix in 1.1 by tightening the definition of a URI scheme

Adam Soroka: Process: When we submit an errata, are we supposed to do something, or is it an action?

Ivan Herman: just describing it

4.2. @vocab property expansion

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

Rob Sanderson: This one is about the expansion of @vocab properties and the issue claims that it is counter-intuitive
… from my perspective, it goes back to #7 (won’t-fix) that the processing model for @type shouldn’t be able to customized
… more than allowing @container: @set
… to avoid monkeying around and overcomplicating
… the response is that that fixes #7, but you can’t fix this issue with scoped contexts
… but Gregg has an example that fixes it…

Gregg Kellogg: well…..
… his feeling is that he’s willing to do things in a context to hide this, but @base is restricted from being in a remote context, and that doesn’t satisfy him
… this is about discrepancies between vocabularies space and document space, where you can use @vocab: “”
… and that might get to a point where you’re not surprised, but there’s overlap with Manu’s blank-nodes as properties, where @vocab is a solution, but not a wide enough oe
… maybe we need to make that a bit wider, make it any relative IRI relevant to the document base
… in 1.0, you can generate an error with this, and we could make it document relevant, which widens what we can put in vocal, which handles both this and Manu’s request

Rob Sanderson: can you talk through why the first Barney expands this wy?

Gregg Kellogg: if we look at Barney, it’s value is a node definition. In any context, ex2:barney evaluates to the URl
… But fred has the value, with the value parnet
… string values are intended to be treated as an IRI within the vocab space, so if barney is the string value of fred, we evaluate barney as vocab-relevant
… there is no @vocab defined, but barney is a term, so we ill now interpret them as iris, so it’s got a value of ex2:barney
… so when we evaluate things in the vocabulary space, it will look to terms and compact IRIs
… so it satisfies the term use case
… when we look at it as ID, which makes it @id, which is in doc space, and we do not interpret things in that space relative to the vocabularies
… in document space, it cannot be a bare term, so we don’t evaluate it
… it could have been barney:, which would work.
… he asked why ID can’t be treated in the vocab space, and that goes back to our decision
… why didn’t we want terms to be values?
… since we allow compact terms?
… typically, where you see this conflation, you are closer to being in the use case where you’re defining a vocabulary
… where it does make sense

Rob Sanderson: was that clear?

Ivan Herman: so I’m not ashamed to say, no.
… It is because it is not complicated, bu what this means for us and readers, is that expansions, and the bifurcations, we should have that in a note and understand it
… frankly, I don’t have a clear idea how things work
… the other comment is that we should have a rule that when an issue is put in, and when it has an example, the example should be reduced.
… from the point of this issue, there are additional things that make things more complicated

Rob Sanderson: +1

Ivan Herman: we should really ask them to make it more simple and to be careful, since much here is not relevant

Adam Soroka: whatever comes out of this, we might really need a note lays out the spaces around expansion, since the suspicion is that this arises because it’s really hard to understand this

Gregg Kellogg: I think that the API document is fairly consistent is clear about this, and the people who are the most likely to be confused are unlikely to read this
… so we’re stuck with the JSON vocab, in turtle there are pnames or iris. In JSON, we can’t do that, so we need to discern the intent around meaning
… thus the bifurcation between the spaces
… it’s laid out, and it’s easy to get lost, and adding another note in syntax documents.
… how much detail to be need to get into?
… we need a primer
… and we need a champion for that primer

Ivan Herman: I get the problem, and it’s not 1.0, it’s just…terrible.
… and I don’t think it needs to be in the specification, and a primer would be the ideal place for it.
… authors will never read the API, and I don’t want to. I just want to put data in JSON-LD
… that’s why the primer is required.
… otherwise people will be lost

Jeff Mixter: the explanation is helpful, and it would be helpful to have the example to be recreated to be realistic, and it’s really confusing with freds and barneys
… it might be better to have real-world examples

Rob Sanderson: a complication with #33

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

Rob Sanderson: It would be nice to have the Uris compact to not just ID, but also to @id. Doesn’t this mean changing the space?

Gregg Kellogg: the way I take this option is to not compact to allow properties, but not values
… that things would remain in their expanded state.
… doing this wouldn’t add additional space
… it’s how you interpret string values. If you’ve got an object, it’s unambiguous

Rob Sanderson: If the context wanted ID: barney to be compacted to id: barney, and another term compacted to a string, then those two otherwise identical lines would have different value spaces

Gregg Kellogg: if you were able to specify the value space of a term, as in the first comment of #33…I think the issues comes down to wanting to specifiy for a property when compacting, you want to compact the term, but not the value.
… if you do this, it continues to be unambiguous, …something about strings…

Rob Sanderson: is there a proposal?

Gregg Kellogg: do we need a issue to change the rules about @vocab to use relative IRIs in document space
… I can create that issue

Ivan Herman: I would like to move this to face-to-face

Gregg Kellogg: sure

Rob Sanderson: sure

Adam Soroka: could we leave a note for the primer?
… maybe a label?
… about the spaces?

Gregg Kellogg: we should create an issue for the primer about that

Rob Sanderson: gregg, create the issue about vocabs, adam, about the primer, and we’ll defer this to face-t-face

Adam Soroka: +1 to that!

5. Resolutions

6. Action Items