Re: [MINUTES] W3C JSON-LD CG Call 2018-02-05

It’s automated based on IRC contributions, but I can edit to remove you.

Sorry it didn’t work out (again); we’ll try something different next time.

Gregg Kellogg
gregg@greggkellogg.net

> On Feb 5, 2018, at 11:54 AM, Ivan Herman <ivan@w3.org> wrote:
> 
> To be precise: I don't think I should be listed as present. I could not connect and for other reasons I couldn't use my landline either. So I had to give up...
> 
> Ivan
> 
> ---
> Ivan Herman
> Tel:+31 641044153
> http://www.ivan-herman.net
> 
> (Written on mobile, sorry for brevity and misspellings...)
> 
> 
> 
>> On 5 Feb 2018, at 20:17, Gregg Kellogg <gregg@greggkellogg.net> wrote:
>> 
>> 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 20:08:31 UTC