JSON-LD Working Group Telco — Minutes
– DRAFT Minutes –
Date: 2020-02-21
See also the Agenda and the IRC Log
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
Content:
- 1. Scribe Selection
- 2. Announcement / Reminders?
- 3. Issues
- 3.1. [monitor] Consider context by reference with metadata
- 3.2. Transition request for syntax and api https://github.com/w3c/transitions/issues/230
- 3.3. Suggestion about
@prefix
https://github.com/w3c/json-ld-syntax/issues/329 - 3.4. Inconsistent management of empty terms https://github.com/w3c/json-ld-api/issues/379
- 3.5. Expansion does not take property-scoped contexts for nested properties into account
- 4. Adjourn
- 5. Resolutions
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)
Gregg Kellogg: +1
Dave Longley: +1
Harold Solbrig: +1
Tim Cole: +1
Benjamin Young: +1
Ruben Taelman: +1
David I. Lehn: +1
Pierre-Antoine Champin: +1
Resolution #1: #380 would not need normative changes, but does needs tests. We will discuss further next week to confirm.
Resolution #2: pchampin to send in a PR for implementations to raise proper errors around
""
+ tests
4. Adjourn
5. Resolutions
- Resolution #1: #380 would not need normative changes, but does needs tests. We will discuss further next week to confirm.
- Resolution #2: pchampin to send in a PR for implementations to raise proper errors around
""
+ tests