JSON-LD Working Group Telco — Minutes
– DRAFT Minutes –
Date: 2019-04-05
See also the Agenda and the IRC Log
Attendees
Present: Benjamin Young, Rob Sanderson, Simon Steyskal, Ivan Herman, Pierre-Antoine Champin, Adam Soroka, Jeff Mixter, Harold Solbrig, David I. Lehn, Tim Cole
Regrets: David Newbury, Gregg Kellogg, Ruben Taelman, Dave Longley
Guests:
Chair: Benjamin Young
Scribe(s): Rob Sanderson, Pierre-Antoine Champin, Benjamin Young
Content:
- 1. Approve minutes of last call
- 2. Announcements/Reminders
- 3. Best Practices / Primer / Cookbook
- 4. Issues
- 5. Resolutions
- 6. Action Items
1. Approve minutes of last call
Benjamin Young: https://www.w3.org/2018/json-ld-wg/Meetings/Minutes/2019/2019-03-29-json-ld
Proposed resolution: Approve minutes of last call (Rob Sanderson)
Rob Sanderson: +1
Simon Steyskal: +1
Benjamin Young: +1
Jeff Mixter: +0
Pierre-Antoine Champin: +1
Resolution #1: Approve minutes of last call
2. Announcements/Reminders
Benjamin Young: Any announcements?
… Good on F2F until TPAC. Just passed feature freeze deadline.
… Anything else, other than issues?
3. Best Practices / Primer / Cookbook
Benjamin Young: https://github.com/w3c/json-ld-wg/issues/17
Benjamin Young: We have a stub primer that Ivan has made
Benjamin Young: https://w3c.github.io/json-ld-bp/
Adam Soroka: +1
Benjamin Young: and so I think we can close the meta issue
Proposed resolution: close #17 as started with other issues/work to follow (Benjamin Young)
Pierre-Antoine Champin: It says community group?
Ivan Herman: +1
Ivan Herman: Yes, that will be changed ASAP … it’s imported from the CG
Benjamin Young: +1
Pierre-Antoine Champin: +1
Rob Sanderson: +1
Harold Solbrig: +1
Rob Sanderson: +1
Simon Steyskal: +1
Jeff Mixter: +1
Adam Soroka: +1
Resolution #2: close #17 as started with other issues/work to follow
Benjamin Young: Should I close by hand?
Ivan Herman: I usually put in comments
4. Issues
Benjamin Young: Diving into the actual issues…
4.1. Recommended base context
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/59
Simon Steyskal: bigbluehat: feature freeze was not regarding the primer document
Rob Sanderson: Issues for today about the primer document, so not subject to feature freeze
Benjamin Young: Idea is to have a default context, similar to RDFa. Discussion about the risks and concerns, mostly about backwards compatibility
… should it be a best practice / prevailing pattern. Make these available, as a lot of content is in these namespaces
… dlongley raised that keys not curies are a good pattern
… repeating common prefixes makes sense.
Ivan Herman: need to be a little bit careful with rdfa comparison. It had the extra difficulty of not having an equivalent of importing a file with prefixes
… so supposed to put everything in your document, which becomes a pain
… so default for RDFa is important. We don’t have that difficulty.
… Can import context file, so the load is not the same. Building in an automatic mechanism for these prefixes may not be a good idea;
… in the RDFa case, the consequence is that every implementation has to regularly update their defaults
… when the defaults are changed. E.g., writing my comments, I forgot to add something into my implementation, so updated it this morning. A pain on implementers and users of those implementations
… I think that having an automatic mechanism is not a good idea, but having a context in a well known place with a number of useful things, and is maintained by the community via GH, is a good idea
Rob Sanderson: +1 to Ivan
Pierre-Antoine Champin: +1 to not make it automatic
Ivan Herman: what this context should contain is a separate discussion
… not really agreeing with dlongley. The number of vocabs in RDFa is quite extensive, so flattened would become a problem, and there would be a clash
… in favor of reproducing the rdfa stuff. If people don’t like CURIEs they don’t have to use it
Pierre-Antoine Champin: totally agree with ivan. dlongley’s concern is orthogonal to this. This context is useful for more RDF-y, and don’t mind CURIEs. Also to context designers, for a base to import
… to not worry about the prefixes, in order to define the flat namespace
Rob Sanderson: +1 to pchampin!
Benjamin Young: +1 to having a handy context for common namespaces
Benjamin Young: I don’t think dlongley was suggesting we discourage curies, but that the prevailing pattern is that communities publish their own context, with imports
… at the data document level, discouraging curies is fine… but as pchampin pointed out it looks normal for some communities
… so having a context with common mappings and making it available to import would be nice
… process wise we need to decide how to maintain it
… could be in the primer, but not extractable
Ivan Herman: I think you are right — copy/paste is not the right solution. We can set up a mini repository that contains that stuff and the readme
… need to agree on a URL to be put somewhere, w3/ns could work
… would then redirect to the GH document
… for a start that would be okay, then need to see once the WG is done, then the CG could take over
… and would have the right to decide on PRs and so on
… whether it’s on json-ld or not … it doesn’t really matter
Benjamin Young: question of URL simplicity, but related to the process
Ivan Herman: No problem with it, but i don’t know who maintains json-ld.org the domain and if it will be still around
… in W3C URL space it’s not our problem
Rob Sanderson: I agree with Ivan that a W3C url is less worry about maintaining domain names.
Pierre-Antoine Champin: … There is prior art in maintaining a namespace at W3C. We can do the same.
Benjamin Young: The activity streams space is now maintained by the CG. They have additive process for getting stuff into it
… some more prior art there
… The CORS issues also highlights the need for stability
Proposed resolution: do not create a default context, but do promote the use of common prefix mappings in the Best Practices and highlight a preference toward “bare” (non-CURIE’d) terms (Benjamin Young)
Simon Steyskal: +1
Jeff Mixter: +1
Harold Solbrig: +1
David I. Lehn: with common resources need to consider caching issues so as to not overload servers
Adam Soroka: +1
Pierre-Antoine Champin: +1
Rob Sanderson: +1
Benjamin Young: +1
Ivan Herman: +1
Resolution #3: do not create a default context, but do promote the use of common prefix mappings in the Best Practices and highlight a preference toward “bare” (non-CURIE’d) terms
Ivan Herman: I would propose to create a separate repository that will have a readme and a json context file, and redirect from a /ns/
name
… as a first approximation, for something to talk about, there is already a context file that was set up some time ago that mimics the RDFa defaults
… I would take that and put it up, and we can discuss what should be in it
Benjamin Young: What if we were to make this a shared effort to build off the RDFa one, to make it more operationalized
… it exists, we could make it less brittle
Ivan Herman: do you mean we do this together with the RDFa file?
Benjamin Young: yes, create the repo and process and make that happen using the existing RDFa file. New process would then maintain it, and strengthen the one that’s there
… good to not have two that are 99% the same
Rob Sanderson: it seems like there will be things we’d like to do in a context, which won’t be possible in RDFa
… so they’d be related, but different
… like we might want “label” as a bare term in the default context
… or @id
to id
, and @none
to none
, etc
… those make no sense in RDFa
Benjamin Young: …so, like where this is headed, but the specific documents would need to be separate
Ivan Herman: Agree, to add to it, the way the RDFa doc was created I’ve described in the issue, but worth looking at the document critically and see if it’s still relevant
… Another aspect to it
… merging is risky, and may create problems
… keep them separate, and w3c’s problem to maintain the RDFa doc
Benjamin Young: Good points about different needs. Want the prefixes to match, and to stay matching.
… We use them together, so lean on the RDFa doc quite a bit
… Should be as stable and maintained as possible
Pierre-Antoine Champin: I spotted a discrepancy btw schema.org and RDFa with dublin core
Ivan Herman: Prefixes should be the same, as much as possible. Will need to check, eg that schema.org does the same thing, with a smaller set of prefixes. The schema.org context file has foaf, and there should be compatibility there. If there’s a clash, we should be in favor of schema?
… but I’ll set up the initial thing. We can come back and look at it
Proposed resolution: have ivan setup initial repository for publishing a “common” context featuring prefixes and “bare” terms for use in the Best Practices document (and beyond) (Benjamin Young)
Ivan Herman: +1
Rob Sanderson: +1
Jeff Mixter: +1
Pierre-Antoine Champin: +1
Benjamin Young: +1
Adam Soroka: +1
Simon Steyskal: +1
Harold Solbrig: +1
Resolution #4: have ivan setup initial repository for publishing a “common” context featuring prefixes and “bare” terms for use in the Best Practices document (and beyond)
Action #1: set up an initial repository for a common context (Ivan Herman)
David I. Lehn: I wasn’t sure how to vote on those proposals. will need to consider proper versioning and caching to make shared resources work. already an issue with similar things at w3id.org. but perhaps making a common context is a good experiment that will force related best practices to be developed.
Ivan Herman: in the mean time … bikeshed … but what URL for /ns
?
Benjamin Young: Let’s do that on the GH repo :)
4.2. Multilingual Values
Benjamin Young: https://github.com/w3c/json-ld-syntax/issues/105
Benjamin Young: Another easy one ;)
… this one is about how JSON-LD currently works, and our past decisions to use HTML for multi lingual values (strings with multiple languages)
… so use straight up HTML, which is not ideal
… Looking at text level semantics HTML, but that’s for the future.
… so what do we need to propose in the primer to close the issue?
… related - there’s no way to do multi-language language maps
Rob Sanderson: it seems we should split this into a primer issue
… eg how do you use language tags
… and what do you do with multiple languages
… and then have a syntax issue around gkellogg’s issue for the normative specs
Benjamin Young: …about, is it an error to have English and Japanese in a string that is stated to be only one of those
Ivan Herman: What was put there by gregg sounds like a solution, but a bit misleading. The use of language tags gives the wrong impression — should be just indexes
Ivan Herman: Language tags are defined by ISO
Rob Sanderson: “<span lang="en">Ninja in japanese: <span lang="jp">忍者</span>“@ja
Rob Sanderson: I agree ivan. to your question, the RDF would look like that:
Rob Sanderson:
"<span lang='en'>Ninja in japanese: <span lang='jp'>忍者</span>"@ja^^rdf:langString
Rob Sanderson: this has been my issue for 5+ years
… language tags must be langString
Ivan Herman: an RDF issue that is not ours to solve
… Lots of nice discussions in dbooth’s repo, but it should happen in RDF not here
… same as missing base direction
… we can only set a single language. And this is the same as base direction, shouldn’t touch it
Rob Sanderson: +1 to ivan
Benjamin Young: RDF is woefully broken in this way, but Gregg’s proposal of HTML + language map would be desirable by JSON developers
Rob Sanderson: https://iiif.io/api/presentation/3.0/#44-html-markup-in-property-values
Benjamin Young: If built to contain HTML, they’re not going to take it into RDF, so a little misuse has advantages
Ivan Herman: q=
Benjamin Young: our audience is interested in JSON, with a side plate of a graph
Rob Sanderson: I put this link in earlier https://iiif.io/api/presentation/3.0/#44-html-markup-in-property-values
… it uses exactly what gkellogg describes
… it is common and exactly what people want to be able to do
Ivan Herman: The funny thing is what you wrote is legal but ugly RDF – a microsyntax for a string, which is outside of RDF or JSON-LD
… it happens to be a subsyntax of HTML
… don’t need anything in the syntax document to do this, its a private agreement between parties
Rob Sanderson: +1 to Ivan
Ivan Herman: this is probably the only thing we can do
… so no issue in the syntax document
… it’s an ugly but best practice given the current technologies
Pierre-Antoine Champin: Going to propose a crazy idea, in the line of what Ivan said. We don’t need to change RDF, we could define a custom datatype. langString
is syntactic sugar for a standard datatype for a more ugly microsyntax of the language inside the value
… we could define a more complex but similar datatype. That’s the crazy idea :) We could instrument it in RDF, with another container type, so that what gregg proposed would generate the appropriate structure
… but it’s quite some work
Ivan Herman: technically … yes … and now I put on the W3C hat, it’s outside of our charter. This would be a RDF datatype.
Pierre-Antoine Champin: What about JSON data type?
Ivan Herman: JSON is closer to our charter. But language isn’t.
… it would be a lot of work … the flood gates would be open. Ruby, direction, etc.
Benjamin Young: https://w3c.github.io/string-meta/
Benjamin Young: worth pausing on the JSON data type. I hear the concerns … is there a way around them? This string-meta document from i18n suggests JSON-LD as a solution for multi-language use
… feel that there’s an opportunity here
… And if we miss it, there’ll be a lot of terrible looking JSON-LD
… I see that it evokes process specters, but it comes up a lot
… The genie won’t go back into the bottle. So any hope of this?
Ivan Herman: Don’t remember the issue, but got into a long discussion with the editors. The examples are mostly wrong.
Benjamin Young: https://github.com/w3c/string-meta/issues/27
Benjamin Young: also https://github.com/w3c/string-meta/issues/13
Ivan Herman: I understand the problem. Would love for the problem to be solved, but outside our influence
Benjamin Young: oh…and https://github.com/w3c/string-meta/issues/23
Ivan Herman: I don’t see any other proper way, other than having it done at the RDF level.
Benjamin Young: …and another https://github.com/w3c/string-meta/issues/11
Rob Sanderson: The bigger risk is to build on shifting sands and have RDF come up with a different syntax that’s incompatible with whatever we come up with
… should instead use it as a way to highlight the need, and potentially a micro-chartered group to solve it for RDF
Benjamin Young: Not ready to recharter, or make a new datatype. Rob proposes to kick it to another group and then an update to JSON-LD. Not a solution, but don’t want to lose the actions
… to close the issue we should state what can be done
… but need to be clear as to what /should/ be done that’s not confusing
Jeff Mixter: +1 to that
Proposed resolution: highlight the need for work is ongoing, but it should present what can be done today via language/data maps and/or using HTML (or other) micro-syntax for expressing multiple language (Benjamin Young)
Rob Sanderson: +1
Benjamin Young: +1
Jeff Mixter: +1
Ivan Herman: +1
Tim Cole: +1
Pierre-Antoine Champin: +1
Simon Steyskal: +1
Adam Soroka: +1
Resolution #5: highlight the need for work is ongoing, but it should present what can be done today via language/data maps and/or using HTML (or other) micro-syntax for expressing multiple language
Ivan Herman: procedural question - if we close the issue, then I think we will lose it for the bp doc. For the time being we don’t have an editor for the document. So don’t want it lost.
… should be raised in the BP repo
Rob Sanderson: +1
Benjamin Young: +1
Ivan Herman: should go through the issues to make sure we don’t lose them
Benjamin Young: Agreed – open editorial issues on BP?
… keep these initial discussion in the syntax doc, to not have the comments scattered
Ivan Herman: Wouldn’t close this one
Simon Steyskal: https://github.com/w3c/json-ld-bp/issues
Benjamin Young: not until there’s another issue to write it up
Ivan Herman: editor will write it up as they see best
Benjamin Young: And it’s the top of the hour
… thanks for all the input
5. Resolutions
- Resolution #1: Approve minutes of last call
- Resolution #2: close #17 as started with other issues/work to follow
- Resolution #3: do not create a default context, but do promote the use of common prefix mappings in the Best Practices and highlight a preference toward “bare” (non-CURIE’d) terms
- Resolution #4: have ivan setup initial repository for publishing a “common” context featuring prefixes and “bare” terms for use in the Best Practices document (and beyond)
- Resolution #5: highlight the need for work is ongoing, but it should present what can be done today via language/data maps and/or using HTML (or other) micro-syntax for expressing multiple language
6. Action Items
- Action #1: set up an initial repository for a common context (Ivan Herman)