<azaroth> scribenick: timCole

Approve minutes of last call

<bigbluehat> +1

<gkellogg> +1

<azaroth> PROPOSAL: Approve minutes of last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-03-json-ld

<ivan> +1

<bigbluehat> +1

<ivan> +1

+1

<jeff_mixter> +1

<azaroth> +1

RESOLUTION: Approve minutes of last call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-03-json-ld

Announcements

azaroth: reminder about TPAC
... any other announcements?

<gkellogg> https://github.com/w3c/json-ld-api/pull/16

gkellogg: we don't have an issue for PR 16, json-ld api, but we need input

azaroth: hearing no further announcement, move to next
... how much discussion does PR need?

gkellogg: I think we approved the idea, we would like another implementation to make sure we've got it right for the PR

azaroth: Dave Longley could be helpful, but not on call

<Zakim> bigbluehat, you wanted to ask about version compatibility

<Zakim> ivan, you wanted to comment on something purely procedural

ivan: procedural - this PR is a new feature not in the Community Report, so we need to make sure we list it

gkellogg: there is a recently added entry in the changes since 1.0

ivan: thanks

<Zakim> bigbluehat, you wanted to ask about version compatibility & mention new implementors

bigbluehat: about getting more implementators in the room

<bigbluehat> https://github.com/json-ld/json-ld.org/pull/667

bigbluehat: I've been reaching out to other developers and json-ld.org
... hoping that will at least watch repositories
... is this something that needs the 1.1 toggle? OR can json 1.0 handle it?

gkellogg: 1.0 processor might generate a list of list error
... it's a matter of what happens when a processor encounters it
... in the test suite there is an option for this
... this does not require to put the processor in the 1.1 mode
... but we could discuss / debate
... there is no change in the context processing

bigbluehat: as I talk to implementers, there's always the 'we'll implement it when it's ready'
... so is this the kind of thing that they could start working on ahead of final 1.1 syntax rollout
... encourage implementers to get started on new features as soon as viable

gkellogg: I try to test as the API changes go into the draft spec

<azaroth> +1 to longer versioning discussion later

ivan: would like to take versioning / singaling probably needs a longer discussion independent of this PR

<Zakim> gkellogg, you wanted to ask about a sense of the WG acceptance of CG features in general.

ivan: let's add it to a near term agenda

gkellogg: bigbluehat raised question of when features are stable enough to begin implementing
... so do we need some form of a statement of when developer can implement something without having to worry about it going away

azaroth: good if worded carefully so we don't paint ourselves into a corner
... for example, in the frozen and sealed context, we may come up with a solution that is different than some change the CG came up with
... so we could say something like, 'lacking further reasoning, we accept the CG drafts, but...'

ivan: even that may be too much. There may be features CG added that don't fit with WG criteria/charge
... so we have to be very careful.
... I remember from RDFa group that some of us went through implementation for features subsequently thown out.

bigbluehat: to clarify, I wasn't wanting promises outside normal publishing cycle, but would like others to be paying attention
... so they can see what's happening and get ready for, and if excited take a crack at it to inform our discussions.
... looking for ways to involve developers sooner rather than later

azaroth: back to PR do we need to wait for further review?

gkellogg: not urgent, and we have some review already, but would like for this and future PRs to make sure changes we make to API are up to snuff

Documentation Issues

azaroth: issue #32 was split into 4 potential issues, 3 of which have been written up and Manu commented about the 4th
... propose we discuss in order, 40, 42, 43

<azaroth> SUBTOPIC: Inline metadata escaping

<azaroth> Link: https://github.com/w3c/json-ld-syntax/issues/40

azaroth: Harold send regrets, but clarified end of line question that came up
... proposal is that we use '@@' to indicate that the following value is not processed.
... processors not expected to retain through any transformation
... convention is that '@@' and its value must be ignored
... so, we reserve '@@' and is should not appear in a context
... what do we all think about that proposal

gkellogg: two-fold concerns - example he points to, the comment is outside the context
... second, is asethic

bigbluehat: example also shows using the key over and over, which creates duplicate keys

azaroth: my objection is that proposal is really a bikeshed paint color on @comment
... not what we want

gkellogg: we now have 5 minuses on this issue

ivan: in another group, thumbs up and thumbs down not frozen, so we cannot rely on github comments for formal vote

ajs6f: if i understand correctly we can't use github to record votes, we could use it to vote and then record these votes in the minutes
... if its convenient

ivan: in this case all the thumbs down are members of the WG, but in general we should be careful not to record non-WG votes

<azaroth> PROPOSAL: Close #40 wontfix.

<bigbluehat> +1

<azaroth> +1

+1

<gkellogg> +1

<ivan> +1

<ajs6f> +1

RESOLUTION: Close #40 wontfix.

<jeff_mixter> +1

<azaroth> SUBTOPIC: @documentation keyword

<azaroth> Link: https://github.com/w3c/json-ld-syntax/issues/42

<azaroth> scribenick: azaroth

timCole: This stems in part from the discussion last week and on #32 that we should allow use of a keyword like @documentation that can point to external information about a context or frame
... there were a couple constraints suggested that it could appear only at the root of the context and not within term definitions
... Avoids allowing people to put @documentation everywhere. Ivan mentioned documenting data. This lets you connect something to the context
... it's at times unnecessary, if you've done a good job like schema has. But there is value in having human readable information about the scheme you're using as a whole
... so I still like the idea

<scribe> scribenick: timCole

<Zakim> bigbluehat, you wanted to support this, but to ask how we'd prevent scope creep

bigbluehat: reasonable as a fallback to next approach we will discuss
... my concern is that key will be mis-used, e.g., for each term definition
... people will expect that they can use it wherever
... could even start showing up in data

<ajs6f_> \q+

bigbluehat: may not be avoidable

gkellogg: well if it does show up outside of context it will be ignored
... there is evidence that use of @ is already an issue
... within in term definitions if it appeared that would generate an error
... other question to what extent is it ignored, e.g., should @documentation appear in compacted document

<azaroth> (The @ as keyword issue: https://github.com/w3c/json-ld-syntax/issues/16)

gkellogg: generally ambivalent, given that follow your nose works pretty well maybe not needed

<Zakim> azaroth, you wanted to suggest making it an error condition that processors must check and to ask if the issue is blocked by the @keyword issue?

gkellogg: could create questions we'll likely stumble over

azaroth: to bigbluehat's point we could require that @documentation could only appear in particular places
... but what does the group think about relationship to issue #16, should we table until we discuss that issue
... for example, if we say non-defined keywords starting with @ not allowed, then any misuse would generate warning or error

ivan: to clarify, @documentation is for context as a whole
... but I could still put @documentation in a nested context

azaroth: yes

gkellogg: anywhere @version could exist, @documentation could exist

<Zakim> bigbluehat, you wanted to ask about implementations of this

ivan: co-context not nested

bigbluehat: continue to be concerned about scope creep

<gkellogg> +1 to bigbluehat’s concern

<jeff_mixter> +1 to bigbluehat's cocerns

ajs6f: my concern is similar, additionally not sure this meets the concern we started with

<azaroth> +1 to ajs6f

ajs6f: while this might be useful, may not align with original concern

<azaroth> scribenick: azaroth

timCole: In terms of benjamin's concern, I think that's a reason to defer until we face #16. If we outlaw @keys except those defined, then the issue goes away as it's not a special case, it's just a misuse
... I think Adam's concern is relevant, but that it is still useful to do

<scribe> scribenick: timCole

azaroth: any further comments?
... to summarize, there is general agreement that it doesn't really solve original use case from #32, but we generally have agreed we're not going to solve that
... 2nd there is concern about mis-use, which might be affected by decision on issue #16
... regardless of original, I think I've heard that documentation in general might be useful, but let's quantify
... do we think documentation of context is a valeuable thing to specify somehow?

<ivan> 0

+1

<gkellogg> 0

<azaroth> +1

<ajs6f> 0

<bigbluehat> 0

<jeff_mixter> 0

ivan: my problem is that in practice I belive that proper documentation of data is really much more important
... in practice people reuse other people's context, so this is secondary

<ajs6f> +1 to ivan

azaroth: so while no one is dead set against it, there seems minimal support for the feature we should close, won't fix
... and leave whether you'll use content neogtiations as a best practice.

gkellogg: if we decide not to go forward it doesn't mean that the issue has gone away, we could still talk about this in best practice
... a way to solve without adding new features

ivan: reason I raised issue #44, I'd rather make it easier for developers to use existing mechanisms
... so we should focus on making it easier for users to make use of these mechanisms

gkellogg: doesn't solve documenting context, but..l.

<azaroth> PROPOSAL: Close documentation issues won't fix and defer a future best practice non-normative discussion

<gkellogg> There are other mechanisms we’ve discussed for documenting a context that don’t require adding to the language, these should go in best practices.

<ajs6f> +1

<azaroth> +1

<gkellogg> +1

+1

<jeff_mixter> +1

<ivan> +1

<bigbluehat> +1

<dlehn> +1

RESOLUTION: Close documentation issues won't fix and defer a future best practice non-normative discussion

ivan: can processors mix yaml and json-ld? can I decide to write my context in yaml?

<Zakim> bigbluehat, you wanted to ask about https://github.com/w3c/json-ld-syntax/issues/43 as best practice

gkellogg: we've opened the door, but we have not place normative requirements on processors

bigbluehat: you can write json file inside of yaml
... is there work needed now (for best practices) on content-negotiation

azaroth: let's come back to it a little later

<jeff_mixter> +1 to Ivan to not close

<dlehn> i've put json-ld with comments in yaml files before and just processed the data into json later. works fine.

ivan: may not want to close that issue but mark it as postponed

azaroth: i will open a new issue to make sure we discuss later
... do we need a best practice label?

<azaroth> ACTION: Rob to create new best practice issue, tracked back to 43,42,40,32 and whether WG or CG should do it

gkellogg: do we or the CG make the best practices?

azaroth: should we summarize the type issues to encourage comments over the next 7 days?

@type issue block

<azaroth> link: https://github.com/w3c/json-ld-api/issues/4

gkellogg: sure - issue #4 would relax an existing constraint that only one alias for a keyword, e.g., both type and profile as aliases for @type

<Zakim> azaroth, you wanted to describe use case

azaroth: useful if coming from an existing json that has multiple ways to say the same thing

bigbluehat: examples would be good

azaroth: we should reach out to original commentor

<azaroth> ACTION: Rob to put in pointer to #4

<azaroth> Link: https://github.com/w3c/json-ld-syntax/issues/34

gkellogg: issue #34 would allow us to use containers to put type in array form

azaroth: what we wanted to do was have a resource with only a single type where the type was given in an array
... if it can ever have multiple values, then it is always an array (json best practices)
... but because type is defined by specification, in the context you can't specify that it is always an array.
... the playground example shows that it doesn't work

<Zakim> wants, you wanted to ask why the restriction was instituted?

gkellogg: the concern (#7) is that the way type is expanded can be influenced by a number of things

<azaroth> link: https://github.com/w3c/json-ld-api/issues/7

gkellogg: initial requestor wants to customize the model for this, CG had a lot of discussion, will review before next time.

azaroth: please review the type issues and comment before next call.
... adjourn.

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/=1/+1/
Present: Rob_Sanderson Benjamin_Young Gregg_Kellogg ajs6f ivan dlehn Tim_Cole jeff_mixter
Regrets: ivan hsolbrig dlongley
Found ScribeNick: timCole
Found ScribeNick: azaroth
Found ScribeNick: timCole
Found ScribeNick: azaroth
Found ScribeNick: timCole
Inferring Scribes: timCole, azaroth
Scribes: timCole, azaroth
ScribeNicks: timCole, azaroth
Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Aug/0007.html
WARNING: Could not parse date.  Unknown month name "08": 2018-08-10
Format should be like "Date: 31 Jan 2004"

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

People with action items: rob

WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)