JSON-LD WG Telco — Minutes

Date: 2020-05-01

See also the Agenda and the IRC Log

Attendees

Present: Rob Sanderson, Gregg Kellogg, Ivan Herman, Benjamin Young, David I. Lehn, Harold Solbrig

Regrets:

Guests:

Chair:

Scribe(s): Benjamin Young, Rob Sanderson

Content:

1. Transition

Rob Sanderson: https://github.com/w3c/transitions/issues/239#issuecomment-622366899

Rob Sanderson: Ralph approved the core specs after gkellogg and I responded to his questions about @prefix
… there’s the link to the approval
… and in that thread there’s also mention of Process 2020
… there are new charters that are in draft that mention it
… but we need to time ours correctly

Ivan Herman: yes. for the time being we don’t have to change anything

Rob Sanderson: the important thing is that we’ve said we want to
… but told we can’t yet
… but once it’s ready, so are we

Ivan Herman: I’ve asked the web master and the communications team to help promote the transitions
… so, May 7th, if that’s good for us
… I’d need to have all the documents done
… meaning, the three rec track docs + the streaming note
… then I would start the whole process
… and then send out the publication request

Gregg Kellogg: isn’t there some wording changes to the specs about our future group?

Ivan Herman: no, there’s nothing in the specs
… just have the specs marked as finalized on May 7th

Gregg Kellogg: right. frozen snap shots in the right directories
… there was some confusion in respec about what the appropriate status is for the note
… fpwd or fpwg
… it’s currently fpwd
… and there’s some other error showing in the checker about some missing section which is visibly there
… I noted it in the issue

Ivan Herman: yeah. that one’s a minor thing
… I can connect with them about it
… so if everything else goes to plan, then next Thursday these go up
… not sure about the formal charter proposal going out
… probably a week later–which is fine
… and that should be all we have to do now

Action #1: create publication snapshots for 3 specs and streaming note. (Gregg Kellogg)

Ivan Herman: gkellogg knows this, but from that point on the document is frozen
… other than obvious spelling mistakes and such
… the reports and tests can be living things–it’s ok to touch them
… but not the documents themselves
… maybe we also talk about errata today?

Rob Sanderson: gkellogg for the streaming note, did you want to talk about the respec stuff?

Gregg Kellogg: yeah, that’s the fpwd thing…which is probably causing the other issue

Rob Sanderson: ah. that’s the streaming note?

Gregg Kellogg: yep

Proposed resolution: Publish 3 rec track documents to PR and streaming note to TR on May 7th (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Harold Solbrig: +1

Rob Sanderson: do we need to confirm the date with a vote?

Ivan Herman: +1

Benjamin Young: +1

David I. Lehn: +1

Resolution #1: Publish 3 rec track documents to PR and streaming note to TR on May 7th

Gregg Kellogg: it would be nice to see if we could aggregate all the actions together across all the minutes

Benjamin Young: we could express the actions there, and then scrap them

Gregg Kellogg: manu’s got a script that does that

Ivan Herman: we’re also talking about getting rid of IRC

Gregg Kellogg: that would be a shame

Ivan Herman: yeah, but some companies are blocking ports to they’re using the web client
… and that’s pretty antique

2. Errata Management

Rob Sanderson: so…onward :)
… thanks to dlehn for bringing up the CSS issue

Ivan Herman: which I’ve fixed while everyone was sleeping

Rob Sanderson: anything else left for the errata management stuff?

Rob Sanderson: https://github.com/w3c/json-ld-api/pull/483

Ivan Herman: whenever I made a PR to the API repo, I get all kinds of funny warnings from my git client here
… the commit went through, but I’ve no idea what those are about
… so gkellogg I may need your help
… or that gkellogg at least do the merge
… so, please push the button gkellogg and I’ll follow it up if necessary
… do we also want errata for the notes?

Gregg Kellogg: do they get frozen

Ivan Herman: no

Gregg Kellogg: then let’s not
… because errata are pretty much out-of-band, and folks have to go read them and know they’re there
… are they linked from the spec?

Ivan Herman: not yet, but when we go to Rec they should
… we can go ahead and put a link in via Respec

Gregg Kellogg: so it should do it automatically
… and nothing to do but add the header entry

Ivan Herman: to put people’s minds at ease we are considering Matrix

3. Base Context Discussion

Rob Sanderson: should we talk about the base context if there’s no other items?

Benjamin Young: https://github.com/w3c/json-ld-rc/pull/8

Ivan Herman: can we try to focus on the 4 categories?
… so we can talk through what we should or should not do around those?

Rob Sanderson: https://github.com/w3c/json-ld-rc/pull/8#issuecomment-618297517

Ivan Herman: can we take those one by one?

Proposed resolution: the set of prefixes are dc11, dcterms, dctype, rdf, rdfs, schema, and xsd, with schema mapping on http. (Rob Sanderson)

Rob Sanderson: +1

Gregg Kellogg: +1

Ivan Herman: +1

Harold Solbrig: what does “schema mapping on http” mean?

Rob Sanderson: it means not “https://”
… but the schema.org community uses http:// so we should to
… otherwise we differ from them…though they do say others can

Gregg Kellogg: yeah. they essentially have their own processing that differs from RDF’s

Harold Solbrig: are the aliases and prefixes in the same context?
… was SKOS discussed?

Harold Solbrig: +1

Resolution #2: the set of prefixes are dc11, dcterms, dctype, rdf, rdfs, schema, and xsd, with schema mapping on http

Ivan Herman: it’s not that widely used, so we limited the list

Harold Solbrig: SKOS is widely used

Rob Sanderson: we use it

Benjamin Young: so does Wiley

Proposed resolution: the set of aliases are direction, graph, id, included, json, language, none, and type. (Rob Sanderson)

Rob Sanderson: +1

Rob Sanderson: but, whatever, we took it out

Benjamin Young: -1

Gregg Kellogg: I’m sympathetic with bigbluehat’s concerns about the aliases
… we did use @ on purpose
… and not using it does conflict with existing JSON
… and it doesn’t make JSON-LD obvious along side other JSON
… I’m not a +1 or -1…probably a +/-0

Rob Sanderson: we agree about the prefixes
… the prefixes, terms, and datatypes we’re all ok with, correct?

Gregg Kellogg: I don’t think there’s any place we use “json” as a data type in JSON-LD
… so we’re just left with “html”
… and is it really worth creating a separate data type for that?
… and if so, why not add XML?

Rob Sanderson: so, I think we’re all OK removing data types

Proposed resolution: Remove the datatypes HTML and JSON from the context (Rob Sanderson)

Rob Sanderson: +1

Ivan Herman: +1

Gregg Kellogg: +1

Harold Solbrig: +1

Harold Solbrig: can I pick and choose these? or is this a single file?

Benjamin Young: +1

Resolution #3: Remove the datatypes HTML and JSON from the context

Rob Sanderson: we agree about 1 and 3, but disagree on 2 and 4
… one suggestion was to pull aliases into a separate context file
… so, aliases.context and prefix.context and aggregate.context which covers both

Rob Sanderson: top-context includes prefix-context, alias-context

Gregg Kellogg: but then just define your own context

Harold Solbrig: 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
… then each community is going to come up with their own
… 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
… and most of these aliases conflict with existing terms, so we wouldn’t use this as is

Ivan Herman: I’m fine if we do a context file for prefixes
… and another for aliases–some people like them; I don’t, but whatever
… I would not do a third one, though
… we haven’t yet talked about comment, label, etc.
… but separate the aliases
… having the common terms–maybe less than what’s there–and the prefixes should be fine

Benjamin Young: 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
… that they should pick these, and there’s conflicts with other widely used ones, such as language in schema.org
… in dedicated communities, make all the aliases you want, and if there are shared patterns, then share them in the community
… but if we do it, then we’re defining them for /everyone/
… thus a few prefixes, and maybe a few terms
… would prefer a longer list of prefixes – the w3c specs and surrounding communities

Rob Sanderson: 1+

Rob Sanderson: to answer ivan about pre-defined terms
… there’s an issue, not about the mapping, but around the value space of the JSON
… so there’s a question about label and how we map it to a string or a language map
… so when we put label into the predefined terms we’ve made a decision
… and in IIIF we’ve moved from a string from a language map
… but conversely in Linked Art, we’ve used rdfs:label as a string for developers for non-I18N labels
… and use something else for lang string stuff
… so that’s the danger for the terms because they make determinations about the value space

Ivan Herman: I get that, so simply taking out the value space would fix that, no?

Rob Sanderson: sadly not, you’d still have to redefine it
… it would default to being a literal, I guess

Rob Sanderson: > “label”: “rdfs:label”

Rob Sanderson: but you’d have to still define it if you wanted it to be a language map
… “label”: “rdfs:label” would be an xsd:string

Rob Sanderson: “label”: {“en”: “english label”}

Ivan Herman: no, it defaults to nothing

Rob Sanderson: well, if you put a language map in there, it wouldn’t be treated as a language map

Gregg Kellogg: if we did make it a language map, you can still use string values
… if you used a string, then it’d be xsd:string

Rob Sanderson: > “label”: {“@language”: “en”, “@value”: “english label”}

Gregg Kellogg: and if you used an object, it would be a language object

Rob Sanderson: well, you could also use a value object
… I’ve no problem putting the predefined terms in a separate file

Benjamin Young: yeah…it all runs into conflict with somebody somewhere
… and seems best avoided
… other than the prefixes

Rob Sanderson: so, how about 2 files
… prefixes
… aliases & terms
… you can then import them into your context
… you’d still get the benefit of context caching

Benjamin Young: This is for context authors as a starter kit
… as newbies will just mess things up, and they need to define their own terms in a context anyway
… can already just pull in schema.org.

Harold Solbrig: yeah, I wonder when you were talking about heavily cached
… many of these are already added into libraries anyhow
… and so these URLs would just be ignored and ultimately just mapped to what’s hard coded–assuming the mappings are the same

Benjamin Young: exactly. that’s “heavy” caching :)

Ivan Herman: the reason I’m a bit hesitant
… is that if I’m going to use JSON-LD in a heavy way, then I’d avoid the aliases
… but things like describedby or label, I’d use those
… but if they’re mixed into the aliases, I wouldn’t use them
… and if we make 3 files…we’d look ridiculous…
… but the prefixes stuff I’d use often
… and for me, I’d expect that it’s there and I could use that more easily
… but then…I am not the target here

Rob Sanderson: one of the benefit of the existing prefixes in the list is that most of them are not terms
… but schema is another potential conflict
… which is why some communities have used sdo
… so we could defer the terms and aliases discussion–pulling them out from the prefixes
… and then we can focus on the prefix names and list

Gregg Kellogg: ivan will remember how familiar this all sounds

Ivan Herman: yes. and at some point we’ll conflict with someone
… so it starts to feel fruitless
… so my feeling is, we tried…let’s move on

Harold Solbrig: the question on why bother
… 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

Ivan Herman: but maybe that’s a good thing
… your community will make a bunch of prefixes for the medical domain
… that the publishing community won’t care about
… and vice versa

Harold Solbrig: but then there’s the common set of prefixes that we all care about

Ivan Herman: but that’s like 5 things
… xsd, rdfs, and that’s about it

Gregg Kellogg: and JSON people won’t use any of those

Ivan Herman: right…so I propose to stop the exercise

Benjamin Young: There is a context file which is the rdfa initial context. We reference in Wiley
… the prefix list already exists and already a context in use
… perhaps we just need to take that list

Ivan Herman: a practical problem

Benjamin Young: Oh?

Ivan Herman: If I’m not around, no one will maintain it

Benjamin Young: We should fix that

Ivan Herman: We can pull into GH and make a redirect from the old URL, then people can maintain it in the future

Harold Solbrig: prefix.cc ?

Benjamin Young: No that’s community, and more about the right hand side because communities move things around

Harold Solbrig: The list?

Benjamin Young: https://www.w3.org/2011/rdfa-context/rdfa-1.1

Benjamin Young: http://www.w3.org/2013/json-ld-context/rdfa11

Benjamin Young: A lot of graph related tools just use this

Ivan Herman: Some unnecessary things

Benjamin Young: Yes but heavily cached so no cost
… maintenance group would take over the maintenance of the rdfa core initial context

Ivan Herman: So it goes into a repo, with a redirection in w3c space into this one

Proposed resolution: JSON-LD Maintenance Group to take over the RDFa Initial Context work and maintain it and its context file via GitHub (Benjamin Young)

Ivan Herman: +1

Gregg Kellogg: +1

Benjamin Young: +1

Rob Sanderson: +1

Harold Solbrig: +1

Gregg Kellogg: if we take over this work, and point it to the github repo, then we should be in a better place
… something we can maintain without a staff contact
… and potentially use some automation to automate the maintenance of this

Ivan Herman: true for the JSON-LD context, but maybe not for the RDFa stuff

Benjamin Young: I’d like to talk about the RDFa stuff separately

Resolution #4: JSON-LD Maintenance Group to take over the RDFa Initial Context work and maintain it and it’s context file via GitHub

Ivan Herman: maybe what we can do is also bring into this repo the RDFa stuff, and it’s maintained in the same place
… ok?

Action #2: move rdfa initial context (Ivan Herman)

4. Resolutions

5. Action Items