JSON-LD Working Group Telco — Minutes

Date: 2018-08-24

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Simon Steyskal, David Newbury, Adam Soroka, Gregg Kellogg, Harold Solbrig, Benjamin Young, Ivan Herman, Tim Cole, David Lehn

Regrets: Dave Longley

Guests:

Chair: Rob Sanderson

Scribe(s): David Newbury, Rob Sanderson

Content:

1. Minutes approval

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

Benjamin Young: +1

Gregg Kellogg: +1

Rob Sanderson: +1

Simon Steyskal: +1

Harold Solbrig: +0

David Newbury: +1

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

2. Announcements

Rob Sanderson: Announcements: regular TPAC announcements
… any others?

Adam Soroka: If you’re from an institution with a travel program, the rates from your institution may be better. Not a critique of the committee, but a good thing to see

Benjamin Young: the rooms in the block are already gone, anyway

Harold Solbrig: Johns Hopkins is in the process of buying a membership, so he’s trying to join again.

Rob Sanderson: If it takes a while, we can invite you as an expert
… no need for introductions

3. Issues

3.1. Warn or error on non-keyword string with @?

Rob Sanderson: first issue, should we warn or error on non-keywords that start with @?

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

Gregg Kellogg: this raises a compatibility issue with 1.0, warning against the use but treating it like any other aliased term
… but there’s a problem with schema.org example, that hasn’t been fixed, though benjamin has put a pull request there for it, where it was using @url where they meant @id, and since they’re using @vocab,it did not do what was expected
… and there’s no way to know that in a standards-compliant way
… should we come down on this and be firm about not using @words? We can’t generate warnings now, but…we could encourage implementations to do so
… pushback on complicating the project for a development concern
… consensus may be won’t-fix

Ivan Herman: there was a bug in the data or the vocabulary…we can’t handle all the bugs. The nature is that if you do what they did, the rubbish you produce is a URL and we can’t stop that.
… that’s life.
… why would we have to add a feature to solve this?

Benjamin Young: it looks like just a typo, and get confused that Urls are IDs…from a syntax standpoint, if we’re not reserving, then we’re limiting our forward compatibility.
… if we just let it exist, it becomes a broken link, but it will limit our options in the future

Gregg Kellogg: For example, we’re using @none in maps in 1.1

Harold Solbrig: We were talking about a comment tag before…that opens us up to non-standard processing.
… if we don’t say anything about them, we’re going to allow them to add special processing instructions as they feel

Simon Steyskal: https://schema.org/ItemList#ItemList-gen-306

Simon Steyskal: I was going to say that in this example, there’s less about wanting to say @id, but just a copy-paste error
… they have a url, but without the @, and they copy/pasted it wrongly

Adam Soroka: I agree with benjamin and harold’s point…the ticket was described as dev vs. production…I’m not very happy about that characterization. It’s also my data vs. data from the world.
… that is not to claim I’ve seen a lot of that, but I don’t think that it’s dev/prod, but it’s also provenance. How accepting do you have to be of other’s messes? Postal’s law is important here, and we want to be accepting
… throwing an error could make that hard, but an warning would be very helpful.

Rob Sanderson: +1 to ajs6f

Simon Steyskal: +1

Adam Soroka: it may be hard, but there may be a middle road where we add non-normative language and you could admit warnings as being useful…

Harold Solbrig: +1 to ajs6f

Rob Sanderson: I wanted to ask about webIDL and warnings…surely this must have come up in other WGs?
… is there a precedents?
… warnings have never come up?

Gregg Kellogg: there are two avenues: promises work or they don’t. IN my use, I add warnings to a logger.
… I think that it would be good to add a note that implementations should inform seeing something that might be a problem, but we can’t standardize things like that, and it would be optional.
… something like that might induce developers to provide extra info in the APIs
… Second things: We treat things that look like keywords differently in the body then we do in the context.
… we had this problem in 1.0, and we weren’t checking for extra terms, or in containers, and we’ve updated that now, and we could do more
… so adding @comment in a context would context would error, but in a doc would cause it to be ignored unless there’s a default vocab
… but the rules do vary between the body and doc

Harold Solbrig: with respect to Adam’s comment, to say something in the doc non-normative telling users that some processors may not agree with the use of other tokens for warnings
… so the absence of statement is an excuse to go wild

Tim Cole: I think we want to keep it simple, and the useful language is that if you do this, add @keys, then the results are unpredictable.
… implementers can do what they want, so don’t do it
… non-normative

David Newbury: forward compatibility is a good reason not to do this

Proposed resolution: Add a non-normative note to -api to recommend exposing warnings when @ symbols are used for tokens other than keywords (Rob Sanderson)

Adam Soroka: +1

Ivan Herman: +1

Simon Steyskal: +1

Gregg Kellogg: +1

Rob Sanderson: +1

Benjamin Young: +1

Tim Cole: +1

David Newbury: +1

David Newbury: -q

David Newbury: +1

Gregg Kellogg: I don’t agree with this–it’s predictable, and if you have a keyword that’s mapped one way or the other, it’s predictable, and we should check or add tests for that

Harold Solbrig: +1

Gregg Kellogg: but the behavior of a processor should be predictable

Rob Sanderson: if you’re in a single processor mode, it must be predictable. I think the unpredictable might be between versions
… and you wouldn’t know if you didn’t keep up

Adam Soroka: sidebar, part of what that’s tricky is that we’re on the verge of metadata about processing…right ow we don’t have a way to admit it. Not a good time to think hard about it, but if things like this pile up, we might need to come back to this

Resolution #2: Add a non-normative note to -api to recommend exposing warnings when @ symbols are used for tokens other than keywords

Rob Sanderson: leave this one open, flag it as editorial?

Gregg Kellogg: leave it open, change the tags

Rob Sanderson: onto the next one

3.2. Revisit empty string as term

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

Gregg Kellogg: 1.0 had a restriction on the use of the empty string as a key, since PHP didn’t handle it well
… however, since JSON-LD tries to process JSON, and JSON does not restrict empty string keys, not doing this is a hole
… but the sentiments that have been expressed are around the lack of use case for it
… not worth the change without a use case

Rob Sanderson: this came up about languages, which we changed with @none, but this would have been an alternate solution
… could have been a use case
… id as empty string, or even worse a type…it seems dangerous, unless there’s a good use case, since it could be very, very confusing
… anyone?

Proposed resolution: close #12 won’t fix, no use case and introduces confusion rather than value (Rob Sanderson)

David Newbury: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Simon Steyskal: +1

Harold Solbrig: +1

Tim Cole: +1

Ivan Herman: +1

Adam Soroka: +!

Benjamin Young: +1

Resolution #3: close #12 won’t fix, no use case and introduces confusion rather than value

David I. Lehn: +1 but it makes me sad to limit the ability to write obfuscated json-ld!

3.3. Initial context

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

Rob Sanderson: #44. Should we have an initial context, like RDFa, where the common terms are defined

Rob Sanderson: RDFA initial context: https://www.w3.org/2011/rdfa-context/rdfa-1.1

Rob Sanderson: like xsd or rdf. Precedent in RDFa
… here are a bunch of prefixes that are baked in
… some discussion very early on in JSON-LD, when it was rejected without prejudice due to lack of usecase

Ivan Herman: two things: I did put in the RDFa, but I don’t think we should take everything that’s there. Very RDF oriented, and JSON-world may not need all of that
… the original reason was around documentation
… why do we need yet another thing, when we can use existing terms from RDF or DC
… that’s a valid thing, but then you have to go to the hassle to add something to the context
… for the very wildly used one, it would make the life of many people easier

Adam Soroka: I see the value in the human sense, not an incentive to best practice–but it’s a best-practice, not something that…I’d have to think about it harder, but I’d be concerned about mapping things into there
… would be so generic that people who need to override them would be annoyed.
… the value may be diluted
… I think we can get a lot of the benefit through non-normative best practices

Gregg Kellogg: See https://prefix.cc/about/json-ld

Benjamin Young: I’m concerned about the risk of this one
… best practices may be the best way to do it
… the RDFa one leans on the fact that they’re just defining prefixes

Rob Sanderson: +1 to bigbluehat and ajs6f

Benjamin Young: but in JSON-LD world, that makes it weird since you don’t have to use namespaced predicates, schema:name as the default, since nobody is going to type that.
… afraid for strange JSON, and fighting the default
… why is this @thing here anyway…
… now we’ve polluted the raw JSON namespace, making everything annotation like

Rob Sanderson: I also wanted to talk about ID and TYPE, one is that unless you’re constrained, @id to id, @type to type…and then we’re stepping into the data level. Also nervous.
… as a difference with RDFa, because you can pull in multiple contexts, it’s trivial to come up with a good default context, perhaps us
… a best-practice context, and that could get most of the benefit, and save people a lot of time without making it a requiremetns

Adam Soroka: +1 to making a default context available without requiring it

David Newbury: from my perspective the default context feels like magic. When trying to explain it’s easy to say that they’re the ones defined in the context
… it’s harder to say the terms are in the context, other than the ones defined over there
… context like things should be contexts :)

Adam Soroka: +1

Gregg Kellogg: Again, see https://prefix.cc/context

Harold Solbrig: I was going to ask what prevented people from coming up with fragments, and we could consider publishing a context in a well-known location. No need to go beyond that

Ivan Herman: I didn’t even consider an initial context for terms. My initial idea was only for prefixes
… so people could just use DC terms, I realize namespaces can be seen as heresy, but it makes it easier for people. Having a default would be a good idea
… I don’t know who did it, but there’s a JSON-LD context that mimics the RDFa context

David Newbury: gkellogg: we saw a lot of prefixes in the RDFa world that seemed like the prefix was a scheme

David Newbury: …in JSON-LD the namespace is rarely used–only used in automatic prefixes when converting from another RDF.

David Newbury: …the general use is terms without namespaces. It’s more common in contexts for common prefixes like RDFS or XSDS

Ivan Herman: jsonLD has a bunch of affordances for this already

Rob Sanderson: one thing we’ll get to is importing contexts in a circular context
… if we have a normative context, and if that imports any other contexts, that could cause issues
… a normative context could help prevent that
… not today’s issue, but it could help.

Benjamin Young: maybe a best-practices to indicate what the common prefixes? This could be useful, and others others than Gregg could do

Tim Cole: One advantage of the context built-in to avoid the weakness of prefixes, where people who use the common one, but not the right common one. It doesn’t look like they’re talking together.
… having a nice context invents many, many URLs for RDF.
… best practices help, but people don’t always do ti.

Gregg Kellogg: If context is in the remote contexts array, a recursive context inclusion error has been detected and processing is aborted; otherwise, add context to remote contexts.

Ivan Herman: Just for the minutes: https://www.w3.org/2013/json-ld-context/rdfa11 is the list of RDFa prefixes…

Gregg Kellogg: regarding the danger of circular contexts, there’s language around that
… and raises an error
… we can catch it, but there may be other uses
… you’re not in the chain of context processing
… I don’t think we can get run-awats here
… One thing that there was an attack vector where you were given a context that is auto-generated, that is automatically generated to create another…and then you can get a run-away, but by exploiting a malefactor giving you a context that causes a stack-overflow
… there are suggestions, the JS and python can deal with it, as does the ruby, but we should add language that deals with stacks of contexts

Proposed resolution: Close syntax/#14 won’t fix, and open a new issue for a suggested best practice context (Rob Sanderson)

Ivan Herman: +0.99999

David Newbury: +1

Rob Sanderson: +1

Gregg Kellogg: +1

Benjamin Young: +1

Simon Steyskal: +1

David I. Lehn: +1

Adam Soroka: we’ve had two ideas, the proposal, and also the idea to have a non-normative but provide a suggested default context

Tim Cole: +0.5

Adam Soroka: do we have machinery to emit that as a product out of the working group–put it up at an address? Yes, we can

Rob Sanderson: we can do that

Adam Soroka: +1

Harold Solbrig: +1

Resolution #4: Close syntax/#14 won’t fix, and open a new issue for a suggested best practice context

Rob Sanderson: we’re at the end of the agenda. Any other business?

4. AOB

David I. Lehn: a use case for empty terms. A theory to see if you could do compression on JSON-LD
… you could compress and decompress, and it would save a character.
… silly
… but a use case.

Rob Sanderson: I personally think, while clever, compression over the document might be a better idea

4.1. Process

Rob Sanderson: my question: is the process working? 3 issues a call
… people are participating, work continues, but is everyone else feeling OK with it?

Gregg Kellogg: I think that the rate that issues are added looks like a bell-shaped curve, and I don’t know where we are, and we may still be rising, and I’m responsible for raising thorny things…
… but I think that if we’re getting behind, is getting more effective use of the issue list leading to shorten some of the discussion might be a way to deal with it if we feel pressue

Benjamin Young: I’ve been working on signposting between this and the community list, and I’d love help with that
… more people should be in this room, or watching, we’re a small group, but more interest would be good
… help would be good. Ping me.

Gregg Kellogg: if you search for JSON-LD 1.1, and you’re taken to the site, not w3c. We should point those

Ivan Herman: there have been issues in the past few weeks where the impression tat there was a consensus on Github. Perhaps an email proposal, with 4-5 days of response? We’re fine, but more will come and the pace may be too slow

Gregg Kellogg: +1 to ivan

Ivan Herman: 3 a day may not be a good pace
… if we an get rid of trivial issues we already agree with, and focus on thorny ones on the call

Benjamin Young: +1 to “obvious consensus” issues being closed without call time or with a “any objections to closing the following N issues”?

Rob Sanderson: thanks, everyone, and see you next week

5. Resolutions