15:07:20 <RRSAgent> RRSAgent has joined #json-ld
15:07:20 <RRSAgent> logging to https://www.w3.org/2020/05/01-json-ld-irc
15:07:22 <Zakim> RRSAgent, make logs Public
15:07:23 <Zakim> please title this meeting ("meeting: ..."), ivan
15:59:19 <azaroth> azaroth has joined #json-ld
15:59:29 <azaroth> present_
15:59:31 <azaroth> present+
16:01:10 <gkellogg> gkellogg has joined #json-ld
16:01:48 <gkellogg> present+
16:01:50 <ivan> present+
16:01:53 <bigbluehat> present+
16:05:25 <dlehn> present+
16:06:24 <hsolbrig> hsolbrig has joined #json-ld
16:06:27 <hsolbrig> present+
16:13:41 <bigbluehat> scribe+
16:13:42 <azaroth> TOPIC: Transition
16:13:45 <azaroth> scrib+
16:13:47 <azaroth> scribe+
16:14:11 <azaroth> https://github.com/w3c/transitions/issues/239#issuecomment-622366899
16:14:12 <bigbluehat> azaroth: Ralph approved the core specs after gkellogg and I responded to his questions about `@prefix`
16:14:35 <bigbluehat> ...there's the link to the approval
16:14:45 <bigbluehat> ...and in that thread there's also mention of Process 2020
16:14:57 <bigbluehat> ...there are new charters that are in draft that mention it
16:15:05 <bigbluehat> ...but we need to time ours correctly
16:15:17 <bigbluehat> ivan: yes. for the time being we don't have to change anything
16:15:28 <bigbluehat> azaroth: the important thing is that we've said we want to
16:15:32 <bigbluehat> ...but told we can't yet
16:15:38 <bigbluehat> ...but once it's ready, so are we
16:15:54 <bigbluehat> ivan: I've asked the web master and the communications team to help promote the transitions
16:16:09 <bigbluehat> ...so, May 7th, if that's good for us
16:16:19 <bigbluehat> ...I'd need to have all the documents done
16:16:28 <bigbluehat> ...meaning, the three rec track docs + the streaming note
16:16:33 <bigbluehat> ...then I would start the whole process
16:16:53 <bigbluehat> ...and then send out the publication request
16:17:18 <bigbluehat> gkellogg: isn't there some wording changes to the specs about our future group?
16:17:27 <bigbluehat> ivan: no, there's nothing in the specs
16:17:39 <bigbluehat> ...just have the specs marked as finalized on May 7th
16:17:47 <bigbluehat> gkellogg: right. frozen snap shots in the right directories
16:18:03 <bigbluehat> ...there was some confusion in respec about what the appropriate status is for the note
16:18:14 <bigbluehat> ...fpwd or fpwg
16:18:22 <bigbluehat> ...it's currently fpwd
16:18:34 <bigbluehat> ...and there's some other error showing in the checker about some missing section which is visibly there
16:18:41 <bigbluehat> ...I noted it in the issue
16:18:45 <bigbluehat> ivan: yeah. that one's a minor thing
16:18:50 <bigbluehat> ...I can connect with them about it
16:19:11 <bigbluehat> ...so if everything else goes to plan, then next Thursday these go up
16:19:23 <bigbluehat> ...not sure about the formal charter proposal going out
16:19:27 <bigbluehat> ...probably a week later--which is fine
16:19:33 <bigbluehat> ...and that should be all we have to do now
16:19:38 <gkellogg> action: gkellogg to create publication snapshots for 3 specs and streaming note.
16:19:46 <bigbluehat> ...gkellogg knows this, but from that point on the document is frozen
16:19:53 <bigbluehat> ...other than obvious spelling mistakes and such
16:20:03 <bigbluehat> ...the reports and tests can be living things--it's ok to touch them
16:20:08 <bigbluehat> ...but not the documents themselves
16:20:18 <bigbluehat> ...maybe we also talk about errata today?
16:20:31 <bigbluehat> azaroth: gkellogg for the streaming note, did you want to talk about the respec stuff?
16:20:40 <bigbluehat> gkellogg: yeah, that's the fpwd thing...which is probably causing the other issue
16:20:47 <bigbluehat> azaroth: ah. that's the streaming note?
16:20:48 <bigbluehat> gkellogg: yep
16:20:49 <azaroth> PROPOSAL: Publish 3 rec track documents to PR and streaming note to TR on May 7th
16:20:51 <azaroth> +1
16:20:54 <gkellogg> +1
16:20:54 <hsolbrig> +1
16:20:57 <bigbluehat> azaroth: do we need to confirm the date with a vote?
16:20:57 <ivan> +1
16:20:57 <bigbluehat> +1
16:21:01 <dlehn> +1
16:21:03 <azaroth> RESOLVED: Publish 3 rec track documents to PR and streaming note to TR on May 7th
16:21:49 <bigbluehat> gkellogg: it would be nice to see if we could aggregate all the actions together across all the minutes
16:22:30 <bigbluehat> bigbluehat: we could express the actions there, and then scrap them
16:22:36 <bigbluehat> gkellogg: manu's got a script that does that
16:22:49 <bigbluehat> ivan: we're also talking about getting rid of IRC
16:23:14 <bigbluehat> gkellogg: that would be ashame
16:23:21 <bigbluehat> s/ashame/a shame
16:23:36 <bigbluehat> ivan: yeah, but some companies are blocking ports to they're using the web client
16:23:39 <bigbluehat> ...and that's pretty antique
16:23:48 <azaroth> TOPIC: Errata Management
16:23:54 <bigbluehat> azaroth: so...onward :)
16:24:10 <bigbluehat> ...thanks to dlehn for bringing up the CSS issue
16:24:18 <bigbluehat> ivan: which I've fixed while everyone was sleeping
16:24:28 <bigbluehat> azaroth: anything else left for the errata management stuff?
16:24:35 <azaroth> https://github.com/w3c/json-ld-api/pull/483
16:25:07 <bigbluehat> ivan: whenever I made a PR to the API repo, I get all kinds of funny warnings from my git client here
16:25:17 <bigbluehat> ...the commit went through, but I've no idea what those are about
16:25:21 <bigbluehat> ...so gkellogg I may need your help
16:25:25 <bigbluehat> ...or that gkellogg at least do the merger
16:25:31 <bigbluehat> s/merger/merg
16:25:40 <bigbluehat> s/merger/merge
16:25:58 <bigbluehat> ...so, please push the button gkellogg and I'll follow it up if necessary
16:26:10 <bigbluehat> ...do we also want errata for the notes?
16:26:14 <bigbluehat> gkellogg: do they get frozen
16:26:19 <bigbluehat> ivan: no
16:26:23 <bigbluehat> gkellogg: then let's not
16:26:55 <bigbluehat> ...because errata are pretty much out-of-band, and folks have to go read them and know they're there
16:27:00 <bigbluehat> ...are they linked from the spec?
16:27:10 <bigbluehat> ivan: not yet, but when we go to Rec they should
16:27:20 <bigbluehat> ...we can go ahead and put a link in via Respec
16:27:30 <bigbluehat> gkellogg: so it should do it automatically
16:27:55 <bigbluehat> ...and nothing to do but add the header entry
16:29:22 <bigbluehat> ivan: to put people's minds at ease we are considering Matrix
16:29:34 <azaroth> q?
16:30:07 <azaroth> TOPIC: Base Context Discussion
16:30:11 <bigbluehat> azaroth: should we talk about the base context if there's no other items?
16:30:23 <gkellogg> q+
16:30:43 <bigbluehat> https://github.com/w3c/json-ld-rc/pull/8
16:31:26 <bigbluehat> ivan: can we try to focus on the 4 categories?
16:31:36 <bigbluehat> ...so we can talk through what we should or should not do around those?
16:31:39 <azaroth> https://github.com/w3c/json-ld-rc/pull/8#issuecomment-618297517
16:31:49 <bigbluehat> ...can we take those one by one?
16:32:20 <azaroth> PROPOSAL: the set of prefixes are dc11, dcterms, dctype, rdf, rdfs, schema, and xsd, with schema mapping on http.
16:32:22 <azaroth> +1
16:32:32 <gkellogg> +1
16:32:33 <ivan> +1
16:32:54 <bigbluehat> hsolbrig: what does "schema mapping on http" mean?
16:33:03 <bigbluehat> azaroth: it means not "https://"
16:33:14 <bigbluehat> ...but the schema.org community uses http:// so we should to
16:33:26 <bigbluehat> ...otherwise we differ from them...though they do say others can
16:33:45 <bigbluehat> gkellogg: yeah. they essentially have their own processing that differs from RDF's
16:34:19 <hsolbrig> q+
16:34:24 <bigbluehat> ack gkellogg
16:34:27 <azaroth> ack hsolbrig
16:34:39 <bigbluehat> hsolbrig: are the aliases and prefixes in the same context?
16:35:05 <bigbluehat> ...was SKOS discussed?
16:35:16 <hsolbrig> +1
16:35:35 <azaroth> RESOLVED: the set of prefixes are dc11, dcterms, dctype, rdf, rdfs, schema, and xsd, with schema mapping on http
16:35:37 <bigbluehat> ivan: it's not that widely used, so we limited the list
16:35:45 <bigbluehat> hsolbrig: SKOS is widely used
16:35:49 <bigbluehat> azaroth: we use it
16:35:53 <bigbluehat> bigbluehat: so does Wiley
16:35:57 <azaroth> PROPOSAL: the set of aliases are direction, graph, id, included, json, language, none, and type.
16:35:59 <azaroth> +1
16:35:59 <bigbluehat> azaroth: but, whatever, we took it out
16:36:07 <bigbluehat> -1
16:36:16 <bigbluehat> q+
16:36:25 <bigbluehat> q+ gkellog
16:36:30 <bigbluehat> ack bigbluehat
16:36:31 <bigbluehat> q+ bigbluehat
16:36:35 <bigbluehat> ack gkellogg
16:36:37 <bigbluehat> ack gkellog
16:36:54 <bigbluehat> azaroth: I'm sympathetic with bigbluehat's concerns about the aliases
16:37:00 <bigbluehat> s/azaroth/gkellogg
16:37:09 <bigbluehat> gkellogg: we did use `@` on purpose
16:37:16 <bigbluehat> ...and not using it does conflict with existing JSON
16:37:30 <bigbluehat> ...and it doesn't make JSON-LD obvious along side other JSON
16:37:42 <bigbluehat> ...I'm not a +1 or -1...probably a +/-0
16:37:51 <bigbluehat> azaroth: we agree about the prefixes
16:38:09 <bigbluehat> ...the prefixes, terms, and datatypes we're all ok with, correct?
16:38:29 <bigbluehat> gkellogg: I don't think there's any place we use "json" as a data type in JSON-LD
16:38:43 <bigbluehat> ...so we're just left with "html"
16:38:52 <bigbluehat> ...and is it really worth creating a separate data type for that?
16:38:58 <bigbluehat> ...and if so, why not add XML?
16:39:06 <bigbluehat> azaroth: so, I think we're all OK removing data types
16:39:14 <azaroth> PROPOSAL: Remove the datatypes HTML and JSON from the context
16:39:17 <azaroth> +1
16:39:18 <ivan> +1
16:39:20 <gkellogg> +1
16:39:25 <hsolbrig> +1
16:39:25 <bigbluehat> hsolbrig: can I pick and choose these? or is this a single file?
16:39:28 <bigbluehat> +1
16:39:32 <azaroth> RESOLVED: Remove the datatypes HTML and JSON from the context
16:40:11 <bigbluehat> azaroth: we agree about 1 and 3, but disagree on 2 and 4
16:40:19 <hsolbrig> q+
16:40:20 <bigbluehat> ...one suggestion was to pull aliases into a separate context file
16:40:38 <bigbluehat> ...so, aliases.context and prefix.context and aggregate.context which covers both
16:40:38 <azaroth> top-context includes prefix-context, alias-context
16:41:08 <bigbluehat> gkellogg: but then just define your own context
16:41:24 <bigbluehat> hsolbrig: except when it comes to prefixes, if we don't come up with a handy collect--even paired down as much as this one is
16:41:32 <bigbluehat> ...then each community is going to come up with their own
16:42:05 <bigbluehat> ...and I think as far as best practices go, pulling the prefixes out more clearly in the JSON-LD context file definitions themselves would be helpful
16:42:23 <bigbluehat> ...and most of these aliases conflict with existing terms, so we wouldn't use this as is
16:42:32 <bigbluehat> ivan: I'm fine if we do a context file for prefixes
16:42:48 <bigbluehat> ...and another for aliases--some people like them; I don't, but whatever
16:42:53 <bigbluehat> ...I would not do a third one, though
16:43:14 <bigbluehat> ...we haven't yet talked about comment, label, etc.
16:43:23 <bigbluehat> ...but separate the aliases
16:43:46 <azaroth> q?
16:43:48 <azaroth> ack bigbluehat
16:43:51 <bigbluehat> ...having the common terms--maybe less than what's there--and the prefixes should be fine
16:43:51 <hsolbrig> q-
16:44:26 <azaroth> bigbluehat: Where we're headed now is good to take out the top level context.  Most of my concerns is taking the top level, and will run afoul of communities
16:44:49 <azaroth> ... that they should pick these, and there's conflicts with other widely used ones, such as language in schema.org
16:45:15 <azaroth> ... in dedicated communities, make all the aliases you want, and if there are shared patterns, then share them in the community
16:45:29 <azaroth> ... but if we do it, then we're defining them for /everyone/
16:46:01 <azaroth> ... thus a few prefixes, and maybe a few terms
16:46:23 <azaroth> ... would prefer a longer list of prefixes -- the w3c specs and surrounding communities
16:46:25 <azaroth> 1+
16:46:26 <azaroth> q+
16:46:31 <azaroth> ack azaroth
16:46:33 <bigbluehat> ack azaroth
16:46:48 <bigbluehat> azaroth: to answer ivan about pre-defined terms
16:47:06 <bigbluehat> ...there's an issue, not about the mapping, but around the value space of the JSON
16:47:24 <bigbluehat> ...so there's a question about `label` and how we map it to a string or a language map
16:47:39 <bigbluehat> ...so when we put label into the predefined terms we've made a decision
16:47:55 <bigbluehat> ...and in IIIF we've moved from a string from a language map
16:48:20 <bigbluehat> ...but conversely in Linked Art, we've used rdfs:label as a string for developers for non-I18N labels
16:48:26 <bigbluehat> ...and use something else for lang string stuff
16:48:45 <bigbluehat> ...so that's the danger for the terms because they make determinations about the value space
16:49:01 <bigbluehat> ivan: I get that, so simply taking out the value space would fix that, no?
16:49:07 <bigbluehat> azaroth: sadly not, you'd still have to redefine it
16:49:17 <bigbluehat> ...it would default to being a literal, I guess
16:49:29 <azaroth> > "label": "rdfs:label"
16:49:30 <bigbluehat> ...but you'd have to still define it if you wanted it to be a language map
16:49:58 <bigbluehat> ..."label": "rdfs:label" would be an xsd:string
16:49:58 <azaroth> "label": {"en": "english label"}
16:50:03 <bigbluehat> ivan: no, it defaults to nothing
16:50:16 <bigbluehat> azaroth: well, if you put a language map in there, it wouldn't be treated as a language map
16:50:29 <bigbluehat> gkellogg: if we did make it a language map, you can still use string values
16:50:41 <bigbluehat> ...if you used a string, then it'd be xsd:string
16:50:44 <azaroth> > "label": {"@language": "en", "@value": "english label"}
16:50:51 <bigbluehat> ...and if you used an object, it would be a language object
16:51:06 <bigbluehat> azaroth: well, you could also use a value object
16:51:34 <bigbluehat> ...I've no problem putting the predefined terms in a separate file
16:52:20 <bigbluehat> bigbluehat: yeah...it all runs into conflict with somebody somewhere
16:52:24 <bigbluehat> ...and seems best avoided
16:52:26 <bigbluehat> ...other than the prefixes
16:52:30 <bigbluehat> azaroth: so, how about 3 files
16:52:33 <bigbluehat> ...prefixes
16:52:41 <bigbluehat> ...aliases & terms
16:52:45 <bigbluehat> s/3 files/2 files
16:53:02 <bigbluehat> ...you can then import them into your context
16:53:14 <bigbluehat> ...you'd still get the benefit of context caching
16:53:51 <azaroth> bigbluehat: This is for context authors as a starter kit
16:54:07 <azaroth> ... as newbies will just mess things up, and they need to define their own terms in a context anyway
16:54:19 <azaroth> ... can already just pull in schema.org.
16:54:37 <bigbluehat> hsolbrig: yeah, I wonder when you were talking about heavily cached
16:54:39 <ivan> q+
16:54:52 <bigbluehat> ...many of these are already added into libraries anyhow
16:55:30 <azaroth> ack ivan
16:55:34 <bigbluehat> ...and so these URLs would just be ignored and ultimately just mapped to what's hard coded--assuming the mappings are the same
16:55:40 <bigbluehat> bigbluehat: exactly. that's "heavy" caching :)
16:55:50 <bigbluehat> ivan: the reason I'm a bit hesitant
16:56:03 <bigbluehat> ...is that if I'm going to use JSON-LD in a heavy way, then I'd avoid the aliases
16:56:21 <bigbluehat> ...but things like describedby or label, I'd use those
16:56:30 <bigbluehat> ...but if they're mixed into the aliases, I wouldn't use them
16:56:47 <bigbluehat> ...and if we make 3 files...we'd look ridiculous...
16:56:57 <bigbluehat> ...but the prefixes stuff I'd use often
16:57:11 <azaroth> q+ re schema as prefix vs term
16:57:15 <bigbluehat> ...and for me, I'd expect that it's there and I could use that more easily
16:57:19 <azaroth> ack azaroth
16:57:19 <Zakim> azaroth, you wanted to discuss schema as prefix vs term
16:57:22 <bigbluehat> ...but then...I am not the target here
16:57:44 <bigbluehat> azaroth: one of the benefit of the existing prefixes in the list is that most of them are not terms
16:57:51 <bigbluehat> ...but `schema` is another potential conflict
16:58:06 <bigbluehat> ...which is why some communities have used `sdo`
16:58:22 <bigbluehat> ...so we could deffer the terms and aliases discussion--pulling them out from the prefixes
16:58:35 <bigbluehat> ...and then we can focus on the prefix names and list
16:58:58 <bigbluehat> gkellogg: ivan will remember how familiar this all sounds
16:59:09 <bigbluehat> ivan: yes. and at some point we'll conflict with someone
16:59:13 <bigbluehat> ...so it starts to feel fruitless
16:59:42 <bigbluehat> ...so my feeling is, we tried...let's move on
16:59:56 <bigbluehat> hsolbrig: the question on why bother
17:00:12 <bigbluehat> ...many of these are so common, that if we don't bother, it's going to get done anyway...and be done multiple different ways
17:00:13 <bigbluehat> q+
17:00:18 <bigbluehat> ivan: but maybe that's a good thing
17:00:28 <bigbluehat> ...your community will make a bunch of prefixes for the medical domain
17:00:34 <bigbluehat> ...that the publishing community won't care about
17:00:38 <bigbluehat> ...and vice versa
17:00:48 <bigbluehat> hsolbrig: but then there's the common set of prefixes that we all care about
17:00:53 <bigbluehat> ivan: but that's like 5 things
17:00:55 <azaroth> ack bigbluehat
17:01:01 <bigbluehat> ...xsd, rdfs, and that's about it
17:01:17 <bigbluehat> gkellogg: and JSON people won't use any of those
17:01:32 <bigbluehat> ivan: right...so I propose to stop the excercise
17:01:55 <azaroth> bigbluehat: There is a context file which is the rdfa initial context. We reference in Wiley
17:02:10 <azaroth> ... the prefix list already exists and already a context in use
17:02:23 <azaroth> ... perhaps we just need to take that list
17:02:29 <azaroth> ivan: a practical problem
17:02:32 <azaroth> bigbluehat: Oh?
17:02:41 <azaroth> ivan: If I'm not around, no one will maintain it
17:02:44 <azaroth> bigbluehat: We should fix that
17:02:58 <azaroth> ivan: We can pull into GH and make a redirect from the old URL, then people can maintain it in the future
17:03:09 <azaroth> hsolbrig: prefix.cc ?
17:03:26 <azaroth> bigbluehat: No that's community, and more about the right hand side because communities move things around
17:03:29 <azaroth> hsolbrig: The list?
17:03:32 <bigbluehat> https://www.w3.org/2011/rdfa-context/rdfa-1.1
17:03:53 <bigbluehat> http://www.w3.org/2013/json-ld-context/rdfa11
17:04:34 <azaroth> bigbluehat: A lot of graph related tools just use this
17:04:51 <azaroth> ivan: Some unnecessary things
17:05:07 <azaroth> bigbluehat: Yes but heavily cached so no cost
17:05:54 <azaroth> ... maintenance group would take over the maintenance of the rdfa core initial context
17:06:10 <azaroth> ivan: So it goes into a repo, with a redirection in w3c space into this one
17:07:24 <bigbluehat> PROPOSAL: JSON-LD Maintenance Group to take over the RDFa Initial Context work and maintain it and it's context file via GitHub
17:07:44 <ivan> +1
17:07:45 <gkellogg> +1
17:07:45 <bigbluehat> +1
17:07:46 <azaroth> s/it's/its/
17:07:49 <azaroth> +1
17:07:59 <hsolbrig> +1
17:10:44 <bigbluehat> gkellogg: if we take over this work, and point it to the github repo, then we should be in a better place
17:10:51 <bigbluehat> ...something we can maintain without a staff contact
17:11:10 <bigbluehat> ...and potentially use some automation to automate the maintenance of this
17:11:37 <bigbluehat> ivan: true for the JSON-LD context, but maybe not for the RDFa stuff
17:11:45 <bigbluehat> bigbluehat: I'd like to talk about the RDFa stuff separately
17:11:51 <bigbluehat> RESOLVED: JSON-LD Maintenance Group to take over the RDFa Initial Context work and maintain it and it's context file via GitHub
17:12:17 <bigbluehat> ivan: maybe what we can do is also bring into this repo the RDFa stuff, and it's maintained in the same place
17:12:28 <bigbluehat> ...ok?
17:12:43 <azaroth> action: ivan to move rdfa initial context
17:13:20 <ivan> zakim, end meeting
17:13:20 <Zakim> As of this point the attendees have been azaroth, gkellogg, ivan, bigbluehat, dlehn, hsolbrig
17:13:22 <Zakim> RRSAgent, please draft minutes
17:13:22 <RRSAgent> I have made the request to generate https://www.w3.org/2020/05/01-json-ld-minutes.html Zakim
17:13:25 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
17:13:29 <Zakim> Zakim has left #json-ld
17:28:01 <ivan> rrsagent, bye
17:28:01 <RRSAgent> I see 2 open action items saved in https://www.w3.org/2020/05/01-json-ld-actions.rdf :
17:28:01 <RRSAgent> ACTION: gkellogg to create publication snapshots for 3 specs and streaming note. [1]
17:28:01 <RRSAgent>   recorded in https://www.w3.org/2020/05/01-json-ld-irc#T16-19-38
17:28:01 <RRSAgent> ACTION: ivan to move rdfa initial context [2]
17:28:01 <RRSAgent>   recorded in https://www.w3.org/2020/05/01-json-ld-irc#T17-12-43