- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 5 Feb 2018 20:54:05 +0100
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: Linked JSON <public-linked-json@w3.org>
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 19:54:12 UTC