- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Mon, 5 Feb 2018 12:17:23 -0700
- To: Linked JSON <public-linked-json@w3.org>
Thanks to Benjamin Young for scribing this week! The minutes for this week’s JSON-LD CG teleconference are now available: https://json-ld.org/minutes/2018-02-05/index.html.
Full text of the discussion follows for W3C archival purposes.
Gregg Kellogg
gregg@greggkellogg.net
JSON-LD Community Group Minutes for 2018-02-05
Agenda:
https://lists.w3.org/Archives/Public/public-linked-json/2018Feb/0000.html
Topics:
1. Announcements: new playgrounds!
2. Updates on the Charter
3. https://github.com/json-ld/json-ld.org/pull/487
4. https://github.com/json-ld/json-ld.org/pull/573
5. https://github.com/json-ld/json-ld.org/pull/573
6. https://github.com/json-ld/json-ld.org/pull/574
7. https://github.com/json-ld/json-ld.org/pull/578
8. https://github.com/json-ld/json-ld.org/pull/582
Resolutions:
1. Have one playground that handles both 1.0 and 1.1 ; explore
ways to make the processing mode as user friendly as possible
2. merge #487
3. Merge #573
4. (process) Use github milestones to manage PRs (to try and
merge) and Issues (to discuss)
5. Don't merge #582, resolve #477 as won't fix (with rationales
from the call)
Action Items:
1. merge 574 and 575
2. merge 578
3. Update the charter to explicitly call out framing as a
deliverable
Organizer:
Gregg Kellogg and Rob Sanderson
Scribe:
Benjamin Young
Present:
Robert Sanderson, Ivan Herman, Niklas Lindström, Victor
Charpenay, David Newbury, Benjamin Young, Gregg Kellogg, David I.
Lehn
Audio:
https://json-ld.github.io/minutes/2018-02-05/audio.ogg
Robert Sanderson: :(
Ivan Herman: Trying to connect with linphone, it seems to do
something but then breaks
Ivan Herman: Giving up...
Niklas Lindström: I'm having rther choppy sound :/
Victor Charpenay: Hi! I tried to connect to the provided SIP
addresses but all three time out.
David Newbury: I'm here, as well
Victor Charpenay: Am I missing something?
Benjamin Young is scribing.
Topic: Announcements: new playgrounds!
Robert Sanderson: You can now try out the in-progress 1.1 spec
...gkellogg would you like to say more?
Gregg Kellogg: I think there is an open question if we want to
keep 1.0 playground as primary
...or if we want to move to a single playground
...regarding compatibility, the dev playground does work for
all the specs
...with the exception of Framing
...but I'm working on that feature for the playground now
Robert Sanderson: So. one playground or more
...given the version compatibility scenario/compatibility, we
might need to make it clear
Niklas Lindström: Maybe just a visual switch in the interface
...so you can test them both in one playground, but switch
between them
Niklas Lindström: I was thinking something similar
Niklas Lindström: I type
Niklas Lindström: I agree, something visual
Niklas Lindström: But a very clear "pending / in development" cue
for 1.1 mode
Gregg Kellogg: I'll point out that 1.1 is almost entirely
compatible with 1.0
...so unless you use new features in 1.1, you should have no
trouble using a single playground
...compacting IRIs is different
...also, the playground does do sanity checking on definition
keywords and container values
...whereas the 1.0 spec did not
...so I'm not sure that there's a value to switching between
processors
...maybe it would help someone to have the fallback to test
things
...but from the way a processor should operate, they should be
the same
Robert Sanderson: So. I ran into is issue #581
...it's hard to understand the fallback handling
Gregg Kellogg: So. maybe some switch in the HTML to invoke one
version of the processor
...there are two ways to turn on the mode
...either the @version in the @context
...or via the API
...right now we're mostly talking about using the API to toggle
it
...to avoid using @version all the time
...there are also other API flags we might want to expose also
David I. Lehn: I do agree there's good stuff we can expose
...but I would be concerned about it getting too complicated
Robert Sanderson: Sounds like everyone's +1 on a single
playground, but with some way to make it user friendly for
switching
Gregg Kellogg: Do we want to put an action or proposal out
there?
PROPOSAL: Have one playground that handles both 1.0 and 1.1 ;
explore ways to make the processing mode as user friendly as
possible
Robert Sanderson: +1
David I. Lehn: +1
Gregg Kellogg: +1
Benjamin Young: +1
Niklas Lindström: +1 (Preferably with 1.0 as default until 1.1 is
REC)
RESOLUTION: Have one playground that handles both 1.0 and 1.1 ;
explore ways to make the processing mode as user friendly as
possible
Robert Sanderson: As niklasl_ said we should discuss default
...I believe the default has to be 1.0
...and you'd have to use UI or @version to toggle it on
Gregg Kellogg: Well. the way that the proposal was worded, it's
a bit unclear
...is it a 1.0 implementation and a UI to switch to a 1.1
implementation?
...or is it a 1.1 implementation with a toggle to process the
1.0?
Niklas Lindström: True. Yes, I think that'd be wise. (With a
caveat about the default having the known 1.0 bugs perhaps...)
Robert Sanderson: Perhaps an amendment to the proposal would
clarify it to a 1.1 implementation to a 1.0 default and the
ability to toggle it
David Newbury: That sounds reasonable to me.
PROPOSAL: (amendment) The playground handles 1.0 with a 1.0
implementation, rather than a 1.1 algorithm in 1.0 mode. 1.0 will
be the default algorithm.
Robert Sanderson: Bigbluehat you had thoughts on evangelism?
Robert Sanderson: +1
Benjamin Young: We'd like to encourage folks to use 1.1, but not
too quickly as they're still using 1.0 in the wild
Gregg Kellogg: +1
Niklas Lindström: +1
David I. Lehn: We'll have to make sure that's doable given
namespace collisions
Gregg Kellogg: Could you just switch libraries as you can with
switching HTML pages?
David I. Lehn: Possibly. it depends on the details, but we can
sort those out if that's what's wanted
Robert Sanderson: I'd suggest we move on to the other topics
Gregg Kellogg: I would like to look at open pull requests on the
call today
Topic: Updates on the Charter
Robert Sanderson: Bigbluehat has volunteered to co-chair the
group
...should it be approved
Gregg Kellogg: https://json-ld.github.io/charter/
...along with iherman as our staff contact
...so far, there's not been much of an opportunity to step
forward, but if anyone has a concern, please email me
...assuming everything goes according to plan, we have our two
chairs
...so we can be sure we have enough folks to do calls and admin
stuff
...we have our editors
...and a staff contact
...it was announced to the Advisory Board (AB)
...no one seemed to flinch or bat an eyelid, so it's so far so
good
...we have to work out the details of what, by when, and by
whom
...but it looks promising to become a WG in the not too distant
future
Gregg Kellogg:
https://github.com/json-ld/json-ld.org/wiki/Changes-in-Community-Group-Drafts-Targeted-for-1.1
Gregg Kellogg: Just a note to say the charter points to this
wiki page
...which explains the changes in the CG drafts
Robert Sanderson: Anything else we need to add here
Gregg Kellogg: https://github.com/json-ld/json-ld.org/pulls
Gregg Kellogg: There are pull requests that need addressing
...if we could add those to the agenda
...along with the other open issues you highlighted
...there is a longstanding PR on authorship
Topic: https://github.com/json-ld/json-ld.org/pull/487
Robert Sanderson: https://github.com/json-ld/json-ld.org/pull/487
...issue #487 handles adding a few more authors based on
contribution
...it's something the group ultimately needs to decide on
PROPOSAL: merge #487
...the other ones are basically pulling through open PRs
Gregg Kellogg: +1
Robert Sanderson: +1
Niklas Lindström: +1
David Newbury: Apologies--have to drop off early.
RESOLUTION: merge #487
Gregg Kellogg: PR https://github.com/json-ld/json-ld.org/pull/573
Topic: https://github.com/json-ld/json-ld.org/pull/573
Gregg Kellogg: This one's about relative IRIs in JSON-LD
...this updates it to more clearly define them relative to the
document
...rather than relative to the vocabulary
...the issue remains open, though, for dealing with vocab
position
...such as @type
...that's been confusing for some folks coming from the RDF
field
...this PR clarifies the intention of what the documents say
curently
...and its been properly accepted by the people who raised the
issue
Gregg Kellogg: Example <#foo>
Robert Sanderson: So. for example.
In Turtle that might be a property location relative to the
document
Gregg Kellogg: {"#Foo": "bar"}
...you can't do that in JSON-LD where you might have {"#foo":
"bar"}
...and unless you've setup your vocabulary to handle that, it
might be ignored
...we might want to setup some text that describes what happens
if a term starts with an IRI delimiter
Gregg Kellogg: "@Vocab": "@base"
...or a way to say the vocabulary base is the same as the
document base
...such as "@vocab": "@base"
...but none of those concerns really need to prevent this PR,
because this leaves the door open to more discussion
...while still clarifying things
Robert Sanderson: Right, so this is a clarifying PR, not a
change in functionality
Gregg Kellogg: I'm trying to remember why we chose string
concatenation vs. IRI processing
Topic: https://github.com/json-ld/json-ld.org/pull/573
Gregg Kellogg: https://github.com/json-ld/json-ld.org/issues/488
Gregg Kellogg: Let's take that back to issue #488
Niklas Lindström: Clarification: terms aren't *resolved* against
vocab, they are string-concatenated.
...so we can at least get the text inline with current behavior
Robert Sanderson: Any other questions?
PROPOSAL: Merge #573
Niklas Lindström: .... This because vocab can end with "#", and
if we didn't concatenate, keys (and type values) would have to
begin with a "#".
Robert Sanderson: +1
Gregg Kellogg: +1
Benjamin Young: +1
Niklas Lindström: +1 (With clarification on vocab concatenation)
David I. Lehn: +1
RESOLUTION: Merge #573
Niklas Lindström: ... This concatenation is equal to prefix
handling in Trig/Turtle, RDFa and RDF/XML
Gregg Kellogg: PT https://github.com/json-ld/json-ld.org/pull/574
Topic: https://github.com/json-ld/json-ld.org/pull/574
Gregg Kellogg: This is about a document relative flag
...it seems to be entirely editorial
...and #575 is also editorial
...trying to make it scan more easily for people
...but does not change anything technically about it
Robert Sanderson: Take a quick look at #574
...any objections?
ACTION: merge 574 and 575
...similarly any objections to #575?
...it does make things easier to read, so it'd be hard to
object to :)
Topic: https://github.com/json-ld/json-ld.org/pull/578
Gregg Kellogg: This is to make the example match what actually
happens
...it gets closer, but it's still not quite there
...as a positive side-effect this extracts the examples
...which has value for use in the playground
...there's also been discussion of using YAML instead of JSON
Robert Sanderson: So this isn't even merely editorial, just
infrastructure tweaks?
Gregg Kellogg: Correct
Robert Sanderson: No actually content changes
...so not sure we even need a proposal
David I. Lehn: I have a question around why we're merging things
like this?
...vs. just using GitHub?
Gregg Kellogg: Well, it's about establishing process around how
changes are made
...if all of these had already had discussion and acceptance,
then that'd be one thing
...but this gives us a chance to get some feedback
David I. Lehn: Yeah...understand, but it just feels weird for
the few of use that are here to confirm stuff already available
online
Robert Sanderson: Mainly we're trying to keep things up-to-date,
and processing things on the call helps push things forward
...and re-enforces process
...and as we move to a WG, it will become more important
...does that help taaz ?
David I. Lehn: Yeah. it's fine, I guess
Gregg Kellogg: Yeah. it also goes back to the roll of the editor
...if there's controversy, then the editor should seek to get
it resolved
...I do think it's helpful to get things discussed
Benjamin Young: Maybe we could use milestones for the calls?
...we could group the issues to be considered/closed in the
milestone
ACTION: merge 578
PROPOSAL: (process) Use github milestones to manage PRs (to try
and merge) and Issues (to discuss)
Gregg Kellogg: +1
Robert Sanderson: +1
Benjamin Young: +1
David I. Lehn: +1
Niklas Lindström: +1
RESOLUTION: (process) Use github milestones to manage PRs (to try
and merge) and Issues (to discuss)
Topic: https://github.com/json-ld/json-ld.org/pull/582
Gregg Kellogg: PR https://github.com/json-ld/json-ld.org/pull/582
Gregg Kellogg: This PR explains the spec text around framing
...it doesn't change any of the substance in the framing
document
...it just moves it into the API document
Robert Sanderson: Travis-ci isn't happy
Gregg Kellogg: Yes. that's because CI is applied and there's an
issue with an earlier PR
...I've since turned that off
...we do hope to turn it back on
...to validate examples and things
Niklas Lindström: I do have a concern about this making the API
document longer
Niklas Lindström: Sure
David I. Lehn: I may be repeating what niklasl_ has mentioned
...is merging this going to cause problems for implementors?
...what if someone doesn't want to include framing?
Niklas Lindström: I've been a bit concerned that framing is a bit
complex, and I've done alternate approaches in a couple of
implementations
...won't implementers need to include framing to pass
validation?
Gregg Kellogg: Not sure there are any out there that don't
support framing
...google's maybe
David I. Lehn: Yeah. that's one of the key ones to be concerned
about
Gregg Kellogg: It might be useful to suggest different levels of
conformance
Niklas Lindström: Rdflib-jsonld doesn't have one; it has a
pending one which is simpler, it just "autoframes" based on @id
...for instance, expansion and things are easier to implement
without getting into compaction
...so the bar is lower for integrating with RDF toolsets
...and framing might be a feature that's beyond compaction
Robert Sanderson: As niklasl_ says, one of the python
implementations doesn't
...and framing seems like a separate beast than compaction
...I'm not -1, but I'm not sure we need to have a single API
document
Gregg Kellogg: The issues I was seeing were around options
Niklas Lindström: Recall that e.g. redland (librdf) hasn't gone
near json-ld because "too complex"
...and having framing here means a single set of options for
both
...perhaps a way to handle it is through different levels of
conformance
Niklas Lindström: Really, it only needs expansion to get any
json-ld into RDF, and it does only have to emit expanded json-ld
to be useful for "full" json-ld processors...
Gregg Kellogg: Related issue
https://github.com/json-ld/json-ld.org/issues/477
Benjamin Young: Getting a gold star from the W3C via testing
goes up with very MUST in the text
PROPOSAL: Don't merge #582, resolve #477 as won't fix (with
rationales from the call)
Gregg Kellogg: So we need a counter proposal for not-merging
Gregg Kellogg: +0.5
Benjamin Young: +1
Niklas Lindström: +1 (We can still publish a separate framing doc
for 1.1 REC if we want to, right?)
Robert Sanderson: So, requirement in specs can cascade, but the
testing tools don't get that conditional nature of the text
...where "if you do section X, then you MUST do the following"
RESOLUTION: Don't merge #582, resolve #477 as won't fix (with
rationales from the call)
...the testing just doesn't map to that
Gregg Kellogg: We should also then reconsider our charter text
ACTION: Update the charter to explicitly call out framing as a
deliverable
...to make sure its clear which dcuments contain which thing
Robert Sanderson: K. we're a bit past time, so off we go
...gkellogg thanks so much for your work here!
...and we'll also be looking into our voip options before next
call
...thanks everyone!
Robert Sanderson: Adjourn :)
Robert Sanderson: Oh, and thanks to Benjamin for scribing!
You're welcome! :)
Robert Sanderson: Anything else you need from me?
Robert Sanderson: I don't think so
Robert Sanderson: I'll add the comment to #477 about rationale
for wontfix
Received on Monday, 5 February 2018 19:17:50 UTC