15:03:35 <RRSAgent> RRSAgent has joined #json-ld
15:03:35 <RRSAgent> logging to https://www.w3.org/2018/08/24-json-ld-irc
15:03:36 <ivan> rrsagent, set log public
15:03:36 <ivan> Meeting: JSON-LD Working Group Telco
15:03:36 <ivan> Chair: azaroth42
15:03:36 <ivan> Date: 2018-08-24
15:03:36 <ivan> Regrets+ dlongley
15:03:36 <ivan> Agenda: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Aug/0014.html
15:03:37 <ivan> ivan has changed the topic to: Meeting Agenda 2018-08-24: https://lists.w3.org/Archives/Public/public-json-ld-wg/2018Aug/0014.html
15:17:41 <azaroth> azaroth has joined #json-ld
15:50:36 <simonstey> simonstey has joined #json-ld
15:57:38 <workergnome> workergnome has joined #json-ld
15:58:30 <ajs6f> ajs6f has joined #json-ld
15:58:34 <workergnome> present+
15:59:19 <gkellogg> present+ Gregg_Kellogg
15:59:19 <simonstey> present+
15:59:34 <azaroth> present+ Rob_Sanderson
15:59:42 <azaroth> chair: azaroth
16:00:33 <ajs6f> present+
16:02:15 <azaroth> regrets+ dlongley
16:03:11 <hsolbrig> hsolbrig has joined #json-ld
16:03:26 <hsolbrig> present+ hsolbrig
16:03:54 <bigbluehat> present+ Benjamin_Young
16:04:04 <azaroth> scribenick: workergnome
16:04:23 <azaroth> TOPIC: Minutes approval
16:04:40 <azaroth> PROPOSAL: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-17-json-ld
16:04:42 <bigbluehat> +1
16:04:42 <gkellogg> +1
16:04:43 <azaroth> +1
16:04:45 <simonstey> +1
16:04:45 <hsolbrig> +0
16:04:54 <workergnome> +1
16:05:02 <azaroth> RESOLVED: Approve minutes of previous call https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2018/2018-08-17-json-ld
16:05:11 <ivan> present+
16:05:21 <azaroth> TOPIC:  Announcements
16:05:34 <workergnome> azaroth: Announcements:  regular TPAC announcements
16:05:40 <workergnome> ...any others?
16:06:00 <bigbluehat> q+
16:06:17 <azaroth> ack bigbluehat
16:06:21 <workergnome> ajs6f: If you're from an institution with a travel program, the rates from your institution may be better.  Not a critique of the committee, but a good thing to see
16:06:39 <hsolbrig> q+
16:06:42 <azaroth> ack hsolbrig
16:06:45 <workergnome> bigbluehat: the rooms in the block are already gone, anyway
16:07:19 <workergnome> hsolbrig: John Hopkins is in the process of buying a membership, so he's trying to join again.
16:07:29 <azaroth> q?
16:07:37 <timCole> timCole has joined #json-ld
16:07:39 <hsolbrig> s/John Hopkins/Johns Hopkins/
16:07:40 <workergnome> azaroth: If it takes a while, we can invite you as an expert
16:07:59 <azaroth> TOPIC: Issues
16:08:01 <workergnome> ...no need for introductions
16:08:12 <azaroth> SUBTOPIC: Warn or error on non-keyword string with @?
16:08:19 <workergnome> ...first issue, should we warn or error on non-keywords that start with @?
16:08:19 <azaroth> link:  https://github.com/w3c/json-ld-syntax/issues/16
16:08:28 <workergnome> ...greg?
16:08:55 <workergnome> gkellogg: this raises a compatibility issue with 1.0, warning against the use but treating it like any other aliased term
16:09:44 <workergnome> ...but there's a problem with schema.org example, that hasn't been fixed, though benjamin has put a pull request there for it, where it was using @url where they meant @id, and since they're using @vocab,it did not do what was expected
16:09:54 <workergnome> ...and there's no way to know that in a standards-compliant way
16:09:57 <ivan> q+
16:10:05 <bigbluehat> q+
16:10:23 <workergnome> ...should we come down on this and be firm about not using @words?  We can't generate warnings now, but...we could encourage implementations to do so
16:10:39 <hsolbrig> q+
16:10:40 <workergnome> ...pushback on complicating the project for a development concern
16:10:44 <simonstey> +q
16:10:46 <ajs6f> q+
16:10:48 <workergnome> ...consensus may be won't-fix
16:10:53 <azaroth> ack ivan
16:11:31 <workergnome> ivan: there was a bug in the data or the vocabulary...we can't handle all the bugs.  The nature is that if you do what they did, the rubbish you produce is a URL and we can't stop that.
16:11:34 <workergnome> ...that's life.
16:11:39 <gkellogg> q+ to discuss issues of forward compatibility with future keywords
16:11:46 <workergnome> ...why would we have to add a feature to solve this?
16:11:48 <azaroth> q?
16:11:54 <azaroth> ack bigbluehat
16:11:55 <workergnome> q+
16:12:19 <azaroth> q+ to ask about WebIDL warnings more generally
16:12:40 <workergnome> bigbluehat: it looks like just a typo, and get confused that Urls are IDs...from a syntax standpoint, if we're not reserving, then we're limiting our forward compatibility.
16:12:52 <gkellogg> q-
16:13:05 <workergnome> ...if we just let it exist, it becomes a broken link, but it will limit our options in the future
16:13:06 <gkellogg> For example, we’re using @none in maps in 1.1
16:13:11 <azaroth> q?
16:13:17 <azaroth> ack hsolbrig
16:13:23 <workergnome> q- Was going to say the same thing
16:13:47 <workergnome> hsolbrig: We were talking about a comment tag before...that opens us up to non-standard processing.
16:14:05 <azaroth> q?
16:14:06 <workergnome> ...if we don't say anything about them, we're going to allow them to add special processing instructions as they feel
16:14:07 <azaroth> ack simonstey
16:14:08 <gkellogg> q+
16:14:15 <simonstey> https://schema.org/ItemList#ItemList-gen-306
16:14:24 <azaroth> q- workergnome
16:14:28 <workergnome> simonstey: I was going to say that in this example, there's less about wanting to say @id, but just a copy-paste error
16:14:43 <workergnome> ...they have a url, but without the @, and they copy/pasted it wrongly
16:14:52 <azaroth> q?
16:14:54 <azaroth> ack ajs6f
16:15:58 <workergnome> ajs6f: I agree with benjain and harold's point...the ticket was described as dev vs. production...I'm not very happyy about that characterization.  It's also my data vs. data from the world.
16:16:38 <workergnome> ...that is not to claim I've seen a lot of that, but I don't think that it's dev/prod, but it's also provenance.  How accepting do you have to be of other's messes?  Postal's law is important here, and we want to be accepting
16:16:55 <workergnome> ...throwing an error could make that hard, but an warning would be very helpful.
16:17:27 <azaroth> +1 to ajs6f
16:17:29 <azaroth> q?
16:17:29 <simonstey> +1
16:17:30 <workergnome> ...it may be hard, but there may be a middle road where we add non-normative language and you could admit warnings as being useful...
16:17:33 <azaroth> ack azaroth
16:17:33 <Zakim> azaroth, you wanted to ask about WebIDL warnings more generally
16:17:33 <hsolbrig> +1 to ajs6f
16:18:02 <workergnome> azaroth: I wanted to ask about webIDL and warnings...surely this must have come up in other WGs?
16:18:09 <workergnome> ...is there a precedents?
16:18:15 <workergnome> ...warnings have never come up?
16:19:07 <workergnome> gkellogg: there are two avenues: promises work or they don't.  IN my use, I add warnings to a logger.
16:19:16 <azaroth> q?
16:19:17 <azaroth> ack gkellogg
16:19:34 <hsolbrig> q+
16:19:58 <workergnome> ...I think that it would be good to add a note that implementations should inform seeing something that might be a problem, but we can't standardize things like that, and it would be optional.
16:20:11 <workergnome> ...something like that might induce developers to provide extra info in the APIs
16:20:28 <workergnome> ...Second things:  We treat things that look like keywords differently in the body then we do in the context.
16:20:53 <workergnome> ...we had this problem in 1.0, and we weren't checking for extra terms, or in containers, and we've updated that now, and we could do more
16:21:05 <azaroth> q?
16:21:16 <workergnome> ...so adding @comment in a context would context would error, but in a doc would cause it to be ignored unless there's a default vocab
16:21:20 <azaroth> ack hsolbrig
16:21:27 <workergnome> ...but the rules do vary between the body and doc
16:22:02 <timCole> q+
16:22:03 <workergnome> hsolbrig: with respect to Adam's comment, to say something in the doc non-normative telling users that some processors may not agree with the use of other tokens for warnings
16:22:09 <azaroth> ack timCole
16:22:15 <workergnome> ...so the absence of statement is an excuse to go wild
16:23:02 <workergnome> timCole: I think we want to keep it simple, and the useful language is that if you do this, add @keys, then the results are unpredicatable.
16:23:15 <workergnome> ...implementers can do what they want, so don't do it
16:23:18 <workergnome> q+
16:23:22 <workergnome> ...non-normative
16:23:58 <workergnome> workergnome: forward compatibility is a good reason not to do this
16:24:00 <azaroth> PROPOSAL:  Add a non-normative note to -api to recommend exposing warnings when @ symbols are used for tokens other than keywords
16:24:16 <ajs6f> +1
16:24:17 <ivan> +1
16:24:20 <simonstey> +1
16:24:20 <gkellogg> +1
16:24:21 <azaroth> +1
16:24:22 <bigbluehat> +1
16:24:33 <timCole> +1
16:24:34 <workergnome> +1
16:24:40 <ajs6f> q+
16:24:45 <workergnome> -q
16:24:47 <workergnome> +1
16:25:24 <workergnome> gkellogg: I don't agree with this--it's predictable, and if you have a keyword that's mapped one way or the other, it's predictable, and we should check or add tests for that
16:25:25 <hsolbrig> +1
16:25:40 <workergnome> ...but the behaviour of a processor should be predictable
16:25:58 <workergnome> azaroth: if you're in a single processor mode, it must be predictable.  I think the unpredictable might be between versions
16:26:04 <azaroth> ack hsolbrig
16:26:09 <azaroth> ack ajs6f
16:26:10 <workergnome> ...and you wouldn't know if you didn't keep up
16:26:47 <dlehn> present+ David_Lehn
16:27:03 <workergnome> ajs6f: sidebar, part of what that's tricky is that we're on the verge of metadata about processing...right ow we don't have a way to admit it.  Not a good time to think hard about it, but if things like this pile up, we might need to come back to this
16:27:12 <azaroth> RESOLVED:  Add a non-normative note to -api to recommend exposing warnings when @ symbols are used for tokens other than keywords
16:27:32 <workergnome> azaroth: leave this one open, flag it as editorial?
16:27:40 <workergnome> gkellogg: leave it open, change the tags
16:27:59 <workergnome> azaroth: onto the next one
16:28:01 <azaroth> SUBTOPIC: Revisit empty string as term
16:28:10 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/12
16:28:40 <workergnome> gkellogg: 1.0 had a restriction on the use of the empty string as a key, since PHP didn't handle it well
16:29:13 <workergnome> ...however, since JSON-LD tries to process JSON, and JSON does not restrict empty string keys, not doing this is a hole
16:29:32 <workergnome> ...but the sentiments that have been expressed are around the lack of use case for it
16:29:40 <azaroth> q?
16:29:44 <workergnome> ...not worth the change without a usecase
16:30:02 <workergnome> azaroth: this came up about languages, which we changed with @none, but this would have been an alternate solution
16:30:12 <workergnome> ...could have been a usecase
16:30:54 <azaroth> q?
16:30:54 <workergnome> ...id as empty string, or even worse a type...it seems dangerous, unless there's a good use case, since it could be very, very confusing
16:31:30 <workergnome> ...anyone?
16:31:55 <azaroth> PROPOSAL: close #12 won't fix, no use case and introduces confusion rather than value
16:31:56 <workergnome> +1
16:31:58 <azaroth> +1
16:31:58 <gkellogg> +1
16:31:59 <simonstey> +1
16:31:59 <hsolbrig> +1
16:32:06 <timCole> +1
16:32:12 <ivan> +1
16:32:13 <ajs6f> +!
16:32:30 <bigbluehat> +1
16:32:32 <azaroth> RESOLVED: close #12 won't fix, no use case and introduces confusion rather than value
16:32:47 <dlehn> +1 but it makes me sad to limit the ability to write obfuscated json-ld!
16:32:52 <workergnome> azaroth: initial context
16:32:52 <azaroth> SUBTOPIC: Initial context
16:32:58 <azaroth> link: https://github.com/w3c/json-ld-syntax/issues/44
16:33:54 <workergnome> azaroth: #44.  Should we have an initial context, like RDFa, where the common terms are defined
16:34:22 <azaroth> RDFA initial context: https://www.w3.org/2011/rdfa-context/rdfa-1.1
16:34:25 <workergnome> ...like xsd or rdf.  Precedent in ARFa
16:34:34 <ajs6f> s/ARFa/RDFa
16:34:40 <ivan> q+
16:34:41 <workergnome> ...here are a bunch of prefixes that are baked in
16:34:54 <ajs6f> q+
16:35:11 <bigbluehat> q+
16:35:16 <workergnome> ...some discussion very early on in JSON-LD, when it was rejected without prejudice due to lack of usecase
16:35:16 <azaroth> ack ivan
16:35:46 <workergnome> ivan: two things: I did put in the RDFa, but I don't think we should take everything that's there.  Very RDF oriented, and JSON-world may not need all of that
16:35:57 <workergnome> ...the original reason was around documentation
16:36:10 <workergnome> ...why do we need yet another thing, when we can use existing terms from RDF or DC
16:36:33 <workergnome> ...that's a valid thing, but then you have to go to the hassle to add something to the context
16:36:47 <azaroth> q+ to ask about id and type aliases for @id and @type
16:36:52 <workergnome> ...for the very wildly used one, it would make the life of many people easier
16:36:52 <azaroth> ack ajs6f
16:36:55 <workergnome> +q
16:37:52 <hsolbrig> q+
16:37:52 <workergnome> ajs6f: I see the value in the human sense, not an incentive to best practice--but it's a best-practice, not something that...I'd have to think about it harder, but I'd be concerned about mapping things into there
16:38:05 <workergnome> ...would be so generic that people who need to override them would be annoyed.
16:38:12 <ivan> q+
16:38:12 <workergnome> ...the value may be diluted
16:38:14 <azaroth> q?
16:38:26 <gkellogg> q+
16:38:28 <azaroth> ack bigbluehat
16:38:29 <workergnome> ...I think we can get a lot of the benefit through non-normative best practices
16:38:39 <workergnome> bigbluehat: I'm concerned about the risk of this one
16:38:46 <workergnome> ...best practices may be the best way to do it
16:39:03 <workergnome> ...the RDFa one leans on the fact that they're just defining prefixes
16:39:12 <gkellogg> See https://prefix.cc/about/json-ld
16:39:34 <azaroth> +1 to bigbluehat and ajs6f
16:39:36 <workergnome> ...but in JSON-LD world, that makes it wierd since you don't have to use namespaced predicates, schema:name as the default, since nobody is going to type that.
16:39:49 <workergnome> ...afraid for strange JSON, and fighting the default
16:39:57 <workergnome> ...why is this @thing here anyway...
16:40:14 <workergnome> ...now we've polluted the raw JSON namespace, making everything annotation like
16:40:16 <azaroth> q?
16:40:18 <azaroth> ack azaroth
16:40:18 <Zakim> azaroth, you wanted to ask about id and type aliases for @id and @type
16:40:58 <workergnome> azaroth: I also wanted to talk about ID and TYPE, one is that unless you're constrained, @id to id, @type to type...and then we're stepping into the data level.  Also nervous.
16:41:27 <workergnome> ...as a difference with RDFa, because you can pull in multiple contexts, it's trivial to come up with a good default context, perhaps us
16:42:00 <workergnome> ...a best-practice context, and that could get most of the benefit, and save people a lot of time without making it a requiremetns
16:42:02 <azaroth> q?
16:42:05 <azaroth> ack workergnome
16:42:11 <azaroth> scribenick: azaroth
16:42:23 <ajs6f> +1 to making a default context available without reequiring it
16:42:31 <azaroth> workergnome: from my perspective the default context feels like magic. When trying to explain it's easy to say that they're the ones defined in the context
16:42:43 <azaroth> ... it's harder to say the terms are in the context, other than the ones defined over there
16:42:50 <azaroth> ... context like things should be contexts :)
16:42:51 <azaroth> q?
16:42:53 <azaroth> ack hsolbrig
16:42:58 <azaroth> scribenick: workergnome
16:43:28 <ajs6f> +1
16:43:29 <gkellogg> Again, see https://prefix.cc/context
16:43:31 <azaroth> q?
16:43:33 <azaroth> ack ivan
16:43:34 <workergnome> hsolbrig: I was going to ask what prevented people from coming up with fragments, and we could consider publishing a context in a well-known location.  No need to go beyond that
16:43:50 <azaroth> q+ to foreshadow api/#14
16:44:03 <workergnome> ivan: I didn't even consider an initial context for terms.  My initial idea was only for prefixes
16:44:32 <workergnome> ...so people could just use DC terms, I realize namespaces can be seen as heresy, but it makes it easier for people.  Having a default would be a good idea
16:44:46 <bigbluehat> q+
16:44:48 <workergnome> ...I don't know who did it, but there's a JSON-LD context that mimics the RDFa context
16:45:34 <azaroth> ack gkellogg
16:46:05 <workergnome__> workergnome__ has joined #json-ld
16:46:35 <workergnome__> gkellogg: we saw a lot of prefixes in the RDFa world that seemed like the prefix was a scheme
16:46:35 <azaroth> q?
16:47:08 <workergnome__> ...in JSON-LD the namespace is rarely used--only used in automatic prefixes when converting from another RDF.
16:47:09 <timCole> q+
16:47:41 <workergnome__> ...the general use is terms without namespaces.  It's more common in contexts for common prefixes like RDFS or XSDS
16:47:50 <workergnome__> scribenick: workergnome__
16:47:56 <azaroth> ack azaroth
16:47:56 <Zakim> azaroth, you wanted to foreshadow api/#14
16:48:08 <workergnome__> ...jsonLD has a bunch of affordances for this already
16:48:22 <workergnome__> azaroth: one thing we'll get to is importing contexts in a circular context
16:48:37 <gkellogg> q+
16:48:42 <workergnome__> ...if we have a normative context, and if that imports any other contexts, that could cause issues
16:48:49 <azaroth> q?
16:48:50 <workergnome__> ...a normative context could help prevent that
16:48:51 <azaroth> ack bigbluehat
16:49:00 <workergnome__> ...not today's issue, but it could help.
16:49:32 <workergnome__> bigbluehat: maybe a best-practices to indicate what the common prefixes?  This could be useful, and others others than Gregg could do
16:49:36 <ajs6f> q+
16:49:46 <azaroth> ack timCole
16:50:29 <ajs6f> q-
16:50:30 <workergnome__> timCole: One advantage of the context built-in to avoid the weakness of prefixes, where people who use the common one, but not the right common one.  It doesn't look like they're talking together.
16:50:47 <workergnome__> ...having a nice context invents many, many URLs for RDF.
16:50:57 <azaroth> ack gkellogg
16:50:59 <workergnome__> ...best practices help, but people don't always do ti.
16:51:10 <gkellogg> If context is in the remote contexts array, a recursive context inclusion error has been detected and processing is aborted; otherwise, add context to remote contexts.
16:51:18 <workergnome__> gkellogg: regarding the danger of circular contexts, there's language around that
16:51:27 <workergnome__> ...and raises an error
16:51:36 <workergnome__> ...we can catch it, but there may be other uses
16:51:39 <ivan> Just for the minutes: https://www.w3.org/2013/json-ld-context/rdfa11 is the list of RDFa prefixes...
16:51:43 <workergnome__> ...you're not in the chain of context processing
16:51:52 <workergnome__> ...I don't think we can get run-awats here
16:52:43 <workergnome__> ...One thing that there was an attack vector where you were given a context that is auto-generated, that is automatically generated to create another...and then you can get a run-away, but by exploiting a malefactor giving you a context that causes a stack-overflow
16:53:10 <workergnome__> ...there are suggestions, the JS and python can deal with it, as does the ruby, but we should add language that deals with stacks of contexts
16:53:11 <azaroth> PROPOSAL:  Close syntax/#14 won't fix, and open a new issue for a suggested best practice context
16:53:16 <ajs6f> q+
16:53:36 <ivan> +0.99999
16:53:38 <workergnome__> +1
16:53:39 <azaroth> +1
16:53:39 <gkellogg> +1
16:53:40 <bigbluehat> +1
16:53:41 <simonstey> +1
16:53:41 <dlehn> +1
16:53:52 <ajs6f> q+ about artifacts for best practice
16:54:31 <workergnome__> ajs6f: we've had two ideas, the proposal, and also the idea to have a non-normative but provide a suggested default context
16:54:33 <timCole> +0.5
16:54:54 <workergnome__> ...do we have machinery to emit that as a product out of the working group--put it up at an address?  Yes, we can
16:55:01 <workergnome__> azaroth: we can do that
16:55:22 <ajs6f> +1
16:55:24 <hsolbrig> +1
16:55:27 <azaroth> RESOLVED:  Close syntax/#14 won't fix, and open a new issue for a suggested best practice context
16:55:49 <workergnome__> azaroth: we're at the end of the agenda.  Any other business?
16:56:09 <workergnome__> simonstey: a usecse for empty terms.  A theory to see if you could do compression on JSON-LD
16:56:28 <workergnome__> ...you could compress and decompress, and it would save a character.
16:56:29 <workergnome__> ...silly
16:56:35 <workergnome__> ...but a use case.
16:57:23 <workergnome__> azaroth: I personally think, while clever, compression over the document might be a better idea
16:57:36 <bigbluehat> s/simonstey: a usecse/dlehn: a usecase/
16:57:36 <workergnome__> ...my question: is the process working?  3 issues a call
16:57:58 <gkellogg> q+
16:58:00 <workergnome__> ...people are participating, work continues, but is everyone else feeling OK with it?
16:58:02 <bigbluehat> q+
16:58:03 <azaroth> ack ajs6f
16:58:12 <ivan> q+
16:58:12 <azaroth> ack gkellogg
16:58:47 <workergnome__> gkellogg: I think that the rate that issues are added looks like a bell-shaped curve, and I don't know where we are, and we may still be rising, and I'm responsible for raising thorny things...
16:59:35 <workergnome__> ...but I think that if we're getting behind, is getting more effective use of the issue list leading to shorten some of the discussion might be a way to deal with it if we feel pressue
16:59:40 <azaroth> ack bigbluehat
17:00:02 <workergnome__> bigbluehat: I've been working on signposting between this and the community list, and I'd love help with that
17:00:20 <workergnome__> ...more people should be in this room, or watching, we're a small group, but more interest would be good
17:00:29 <workergnome__> ...help would be good.  Ping me.
17:00:54 <azaroth> ack ivan
17:00:55 <workergnome__> gkellogg: if you search for JSON-LD 1.1, and you're taken to the site, not w3c.  We should point those
17:01:45 <workergnome__> ivan: there have b been issues in the past few weeks where the impression tat there was a consensus on Github.  Perhaps an email proposal, with 4-5 days of response?  We're fine, but more will come and the pace may be too sloa
17:01:54 <gkellogg> +1 to ivan
17:01:56 <workergnome__> ...slow.  3 a day may not be a good pace
17:02:06 <bigbluehat> +1 to "obvious consensus" issues being closed without call time or with a "any objections to closing the following N issues"?
17:02:09 <azaroth> q?
17:02:12 <workergnome__> ...if we an get rid of trivial issues we already agree with, and focus on thorny ones on the call
17:02:38 <workergnome__> azaroth: thanks, everyone, and see you next week
17:02:59 <ivan> rrsagent, draft minutes
17:02:59 <RRSAgent> I have made the request to generate https://www.w3.org/2018/08/24-json-ld-minutes.html ivan
17:03:00 <ivan> zakim, bye
17:03:00 <ivan> rrsagent, bye
17:03:00 <RRSAgent> I see no action items
17:03:00 <Zakim> leaving.  As of this point the attendees have been workergnome, Gregg_Kellogg, simonstey, Rob_Sanderson, ajs6f, hsolbrig, Benjamin_Young, ivan, David_Lehn, !
17:03:00 <Zakim> Zakim has left #json-ld