JSON-LD Working Group Telco — Minutes

– DRAFT Minutes –

Date: 2020-02-21

Attendees

Present: Gregg Kellogg, Pierre-Antoine Champin, Ruben Taelman, Tim Cole, Dave Longley, David I. Lehn, Benjamin Young, Harold Solbrig

Regrets: Ivan Herman, Rob Sanderson

Guests:

Chair: Benjamin Young

Scribe(s): Harold Solbrig, Benjamin Young

Benjamin Young: Meeting Agenda 2020-02-21: https://lists.w3.org/Archives/Public/public-json-ld-wg/2020Feb/0022.html

1. Scribe Selection

2. Announcement / Reminders?

Harold Solbrig: I posted something on the mailing list about a semantic web meeting in Raleigh
… I’ve got 90 minutes to say good things about JSON-LD
… I can fill the 90 minutes, but wanted to share the opportunity with others who might want to chip in

Gregg Kellogg: there’s some past material that might be useful

Gregg Kellogg: https://json-ld.org/learn.html

Harold Solbrig: yeah, I’ve been digging through those, but hope to take a different approach
… I’m going to go from the RDF side and then to JSON-LD
… which is what finally helped me understand it all
… 90 minutes is a long time, and I’d love other contributors

Gregg Kellogg: would be great to get these on json-ld.org

Harold Solbrig: yeah, that’d be great.

Benjamin Young: sadly can’t make it, but wish I could

Harold Solbrig: David Booth is presenting content on Easier RDF

Gregg Kellogg: yeah, that’s a community group

Harold Solbrig: yeah, much of that seems covered by JSON-LD
… and it’s just a matter of understanding what you can do.

Gregg Kellogg: https://github.com/w3c/EasierRDF

Benjamin Young: Ruben got his PhD
… . loud applause

3. Issues

3.1. [monitor] Consider context by reference with metadata

Benjamin Young: https://github.com/w3c/security-review/issues/24

Benjamin Young: Born out of https://github.com/w3c/json-ld-syntax/issues/108

Benjamin Young: I think it was plh who posted this issue, not sure what solicited the issue
… issue 108 discussed last week
… if you are curious, subscribe to it
… we should watch in case conversation begins before we hear about it
… Ivan put out transition request for CR

3.2. Transition request for syntax and api https://github.com/w3c/transitions/issues/230

Benjamin Young: formal request – subscribe if you are interested in monitoring its progress

Gregg Kellogg: effective pub data needs updated
… will also be publishing an update to the framing document. All three have CR end date extended to March 30
… so far mine is the only implementation report in there. jsonld.js should be ready soon

Gregg Kellogg: https://w3c.github.io/json-ld-api/reports/

Benjamin Young: we expect other IR’s to submit reports as described in this document
… anyone willing to jump in on testing their implementation

robensworks: report on streaming parser - 83% of the to-rdf spec tests pass
… majority of failing are due to type-scoped context, still needs implementation

Dave Longley: The only thing jsonld.js needs is the html piece – also a bit of framing
… could put an interim report up there

Gregg Kellogg: if we have incomplete reports, it gives a sense of progress

Ruben Taelman: I think I can run reports later today

Harold Solbrig: is @included implemented?

David I. Lehn: it’s done, but not released yet

Harold Solbrig: some of the stuff we’re doing will be much prettier once that stuff shows up
… we’re using it to tack on an ontology header
… right now we’re using @graph which makes peoples brains hurt

David I. Lehn: we should be close

Harold Solbrig: as an aside, we forked the playground and put samples in for our use cases

David I. Lehn: yeah…the playground is out of date…and it’d be great to get fresh content there

Harold Solbrig: some of these are specific to us, but may be helpful to others
… it might encourage others to use the playground other places

Gregg Kellogg: https://github.com/schemaorg/schemaorg/issues/2468

Benjamin Young: There is an issue with schema.org conneg

Gregg Kellogg: recommends that the highest priority context type … results in getting html, which is wrong
… hopefully there will be an update on their site.

Benjamin Young: python code has been merged – an hour ago

Gregg Kellogg: merge references something in my implementation.

Benjamin Young: you may be able to rerun the tests shortly
… On to issues

3.3. Suggestion about `@prefix` https://github.com/w3c/json-ld-syntax/issues/329

Harold Solbrig: ah yes. that was quite a discovery
… some of the prefixes an upstream group used weren’t making it through
… we chased it down to an errata on 1.0
… if the URI didn’t end in # or /, then it was being treated different

Gregg Kellogg: gendelim characters

Harold Solbrig: before that errata came through, they were doing all sorts of things with URIs
… one part of the issue is related to 1.0
… and hopefully anything we do for 1.1 can be back rev’d
… we first looked at 1.1’s expanded context form processing
… we started using @prefix: true to call these out
… but folks are using JSON parsers as well as JSON-LD parsers

Gregg Kellogg: ”CHEBI”: {“@id”: "http://example.org/CHEBI_”, “@prefix”: true}

Harold Solbrig: i.e. they’re only using strings for prefix values
… "CHEBI": "http://...."
… one proposed alternative was @prefix: true on the surrounding @context object
… but in further discussions with the group, it still gives them some major work to do
… what they asked (and I think makes sense) was, can we add a parameter to the API as if it was @prefix: true
… now, I’d still like to look at the @prefix on the surrounding @context object as it organizes the intent
… it’s otherwise not always obvious what the author meant
… but in the immediate term, if we could get something at the API level, that would be helpful
… we forked jsonld.js and made this change, and got it working for this communities use case

Gregg Kellogg: sadly, the problem we face is that we’re in our second round of CR
… and have been in feature freeze for sometime
… and all of these are normative changes
… so that would mean either a third CR
… or postpone what we’re doing to address some of these other late-breaking suggestions
… there’s a few things here:
… @prefix directly on @context
… your API parameter–which I’m less in favor of, but understand the motivation of
… if Ivan were here, he would not be pleased
… and I’m not sure how we would address such late breaking changes

Pierre-Antoine Champin: big +1 to what gkellogg just said
… seems to me there might be another solution that might be as breaking
… that could perhaps even be considered non-normative
… the errata on 1.0 was to avoid any arbitrary IRI to be used as a prefix
… but the use case here isn’t about that
… they’re consistently using an underscore…corect?

Harold Solbrig: sadly, no. it ends in _, =, and even : or alphanumeric characters

Pierre-Antoine Champin: gendelim includes : at least
… but alphanumerics…no…

Gregg Kellogg: gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / “@“

Pierre-Antoine Champin: my idea was to “extend” the use of gen-delims in this case
… but that sounds like it won’t work

Harold Solbrig: this was an early adopter community, and I’d hate to break this for them

Pierre-Antoine Champin: so, my proposal would be…asking the group around CR compliance….
… that the intention of the gen-delim choice would be preserved even if we proposed extending that list of characters

Gregg Kellogg: we specifically call out a lot of this use in the docs…
… we could do some of this at the API level, but I think it’s still normative changes
… really it’s the prefix: true behaviour that seems necessary
… it’s not a technical question really
… it’ll be normative regardless
… and I don’t see how we could do that without doing another CR

Dave Longley: do we still have time to push CR #2 back? and if so … how much time would we need?

Benjamin Young: I am not a CR cop and don’t know what we can and can’t do
… I second harold on supporting the new community
… this is not the first group to get tangled up in this
… probably there is a need to address this
… we need a staff contact to make this call from a staff contact
… we may have to table it until Ivan comes back

Dave Longley: do we still have time to push second CR back and how much time do we need
… which gets to next issue. Want to avoid slow drip drip drip…
… can we add a legacy flag which allows transitioning?
… I don’t see any other way than pushing CR back
… we should also talk about the next issue as well, which would also push CR back

Benjamin Young: I do think that situation is a mix of two paths – yea, that’s not quite JSON-LD vs. changing everything about how JSON-LD vs. bumping CR back

Gregg Kellogg: What we’re looking at is calendar math w/ June deadline, are we at the point where we’re going to have to ask for an extension

Benjamin Young: that used to be a bad thing, but maybe not so much
… now that we’re going to print, folks are starting to dive in. Very real reasons to get an extension done …
… propose we table this issue and 379, as likely cause for CR extension, will become broad topic for next week

3.4. Inconsistent management of empty terms https://github.com/w3c/json-ld-api/issues/379

Benjamin Young: API topic - Issue 379

Gregg Kellogg: this is not a normative change. We say term may not be an empty string
… we just don’t have any tests to validate processors.
… adding that doesn’t represent the same problem with prefixes

Harold Solbrig: as that was discovered, I asked about their use cases for ""
… they weren’t actually sure, but they wouldn’t object if they were flagged as errors
… they’re happy if the processor flags the errors and they’ll fix the errors

Benjamin Young: you mentioned they have “plain JSON” parsers also?

Pierre-Antoine Champin: this is already rejected by the playground

Harold Solbrig: yeah, but here it doesn’t matter. That was on the @prefix side of things
… they’re using a Java based JSON-LD processor and rdflib JSON-Ld

Benjamin Young: any actions?

Ruben Taelman: One possible why they used it is that they’re coming from formats like turtle
… which would be similar to this.

Harold Solbrig: yeah. it’s the same sort of issue we face with @base
… they import lots of @context files
… and @default doesn’t make sense for them

Gregg Kellogg: I don’t think this is close wont-fix
… I think we need to make sure processors throw proper errors
… and have specifics about it and tests

Benjamin Young: This isn’t close, don’t fix. Should be add a test to make sure the processors generate an error
… but that should be non-normative

Proposed resolution: pchampin to send in a PR for implementations to raise proper errors around "" + tests (Benjamin Young)

Dave Longley: +1

Gregg Kellogg: +1

Benjamin Young: +1

Tim Cole: +1

Pierre-Antoine Champin: +1

Ruben Taelman: +1

Harold Solbrig: +1

3.5. Expansion does not take property-scoped contexts for nested properties into account

Benjamin Young: https://github.com/w3c/json-ld-api/issues/380

Benjamin Young: dave mentioned that this might be potentially worth another CR

Dave Longley: I am surprised that this isn’t something we already cover – @gkellogg – will this one change get us to where we want to be

Gregg Kellogg: I think it is similar to last one. We don’t say anything about it, but it doesn’t mean it is a new feature
… for the most part, suggestion works for expansion. Haven’t looked at compaction
… implemenation impact is that you have to check impact when iterating through.
… I think we could handle this as needs tests and tweak, not a normative change.

Dave Longley: I would like a resolution from group that this is non-normative, we will handle this
… If we agree that it won’t effect CR, we can postpone

Proposed resolution: #380 would not need normative changes, but does needs tests. We will discuss further next week to confirm. (Benjamin Young)