Meeting minutes
Announcements and Introductions
<gkellogg> presentT+
<pchampin> https://
pchampin: I've created a playground
… I've added poor man's support for JSON-LD and YAML-LD
… it doesn't support the full capabilities...but it's better than nothing
gkellogg: I think we eliminated a lot of the special processing in YAML-LD
pchampin: I honestly didn't check the spec
anatoly-scherbakov: we removed most...or maybe all of the YAML specific features and made it very bare bones
… pchampin is it correct that you build Sophia RS?
pchampin: correct
anatoly-scherbakov: and that's on crates.io?
… and supports JSON-LD?
pchampin: the latest version does not support YAML-LD out of the box
… the SoWasm playground is a hack around YAML-LD
… it's a simple conversion to JSON and then uses the JSON-LD parser in Sophia
… ultimately, I'd like to create a full implementation that goes straight from YAML to the internal representation
gkellogg: there is work around the document loader with logic for contexts and things
… but it should be an "onion skin" type of implementation, though.
CBOR-LD
bigbluehat: any thoughts on last time's call?
gkellogg: I've stayed out of it for some time
… the binary format has kept me away
… I do like where they're going where every context does not need be well known
… some things are still fuzzy, though.
bigbluehat: such as?
gkellogg: things like the token space
… you don't just put a vanilla CBOR to JSON parser
… you have to understand the JSON-LD first
bigbluehat: It's progressive layers of compression; you can layer on more context understanding to get better compression.
… The biggest shock is that it isn't really Linked Data; it's about round-tripping to/from JSON-LD.
gkellogg: I think we laid out some requirements we wanted there
… such as similar interfaces like we have with YAML-LD
… and the compression becomes an option for the generic JSON-LD API
… at least that's how I thought about it
… it at least needs to be closer to YAML-LD
bigbluehat: agreed. At least if it keeps the `-LD` moniker
gkellogg: agreed. For now it's not really a Linked Data format...per se
… anatoly-scherbakov any thoughts on CBOR-LD?
anatoly-scherbakov: I've not tried it out. Just stuff we've discussed on the calls.
… my general thought would be that it would be probably logical to create Linked Data mappings for many other things
… Parquet, etc.
… so Linked Data could be used regardless of sub-straight format
pchampin: I agree with anatoly-scherbakov
… with one caveat maybe
… JSON-LD might be the most appropriate mapping language
… CSV on the Web might be closer
… but I do like that idea
… being able to map anything to Linked Data would be great
… I know there are CBOR competitors... Would it make sense to define the compression mechanism separately from the CBOR encoding?
… we could, for example, consider mapping that compression process onto BSON or other binary formats
gkellogg: some of it is tied directly to the CBOR registry...but some things are not
… and those things are not necessarily tied to CBOR
… we could even consider a compact JSON form
… I guess you'd use a context to map the long names to highly compressed names, perhaps
… it's a little similar to the internal representation we did between 1.0 and 1.1
… My main concern is the work is happening outside of the CG or the WG...and it's just stuff being worked on
… and it's just something we're being expected to adopt
… and that's not how working groups are supposed to work
… That said, I'm not sure where we are as a working group
… we're under the maintenance charter
pchampin: that expires at the end of July
bigbluehat: oh heavens
gkellogg: yeah, that should likely be a priority
bigbluehat: I agree about the concern on CBOR-LD being developed almost exclusively outside of the WG/CG and the expectation that it is on our work list.
… Of course, the CG doesn't have a good track record of completing work (other than YAML-LD).
… But, I agree that it can't be a WG spec until enough of the WG members are more directly involved in the work.
… A WG consideration could be to abstract the work beyond CBOR, as the compression could be useful elsewhere.
… there are other formats which are also interesting for -LD.
https://
bigbluehat: It's not LD per-se, but the compressibility is tied to how you compress the data.
… Jelly is based on protocol buffers; it would be nice to get some of these communities involved in the group.
… CBOR-LD is a way to do that that needs review and shaping.
… If the algorithms are more generic, they could then be applied to CBOR or something else.
JSON-LD Issue Discussion
gkellogg: anything else for this intro topic?
https://
gkellogg: are there any issues in the project system that anyone would like to discuss?
… anatoly-scherbakov I think there's a PR or two?
anatoly-scherbakov: yes, a couple have been merged
… they add a few small things to the spec
… metadata and examples
… I'll repeat my question from earlier. Does anyone have ORCID or other public Linked Data data available that we could use as examples?
TallTed: I don't have ORCID, but I do have other stuff out there
gkellogg: we typically use FoaF
… dlehn do you have anything like that?
dlehn: for myself...I don't think so
gkellogg: constructing a basic profile isn't very hard
… there's nominally a URI
… but blank nodes happen
anatoly-scherbakov: ok. It's just that as I visualize this information, I have human readable names for gkellogg, he, and pchampin
… but things like GitHub URLs don't resolve because they don't distribute linked data
gkellogg: yeah...if that information isn't publicly exposed, then we'll have to fabricate
bigbluehat: Is there a YAML-LD section you'd like contributions to?
… I might be able to add something to my site which would help.
<anatoly-scherbakov> https://
bigbluehat: Is this data visualized in the spec?
https://
bigbluehat: There's also an underutilized discussions space.
gkellogg: any issues we'd like to discuss?
anatoly-scherbakov: there's an issue about use native flags
… but my earlier contribution was apparently incorrect...
w3c/json-ld-api#648
<gb> Issue 648 Error in fromRdf/0027-out.jsonld (by marcelotto)
anatoly-scherbakov: when I was converting literals into JSON-LD
… when they used native types, I was converting them to Value Objects
… but that's not what the spec is going for
… the spec says to use native JSON types
… and I made a PR to address that
<gb> Pull Request 650 #648 `0027-out.jsonld`: `@graph` and value objects (by anatoly-scherbakov)
gkellogg: the first sentence was about `@graph`
… it was always used in 1.0
… but generally eliminated in 1.1
… except for certain use cases
… if JSON-LD is a single object, then you would not expect to see an `@graph` containing it
… so I think there are two things in here
… the specifics of `@graph` and what types of JSON values are emitted vs. expanded values
… you basically want more review, correct?
anatoly-scherbakov: yes. exactly
… some re-review would also be appreciated
gkellogg: so the linked issue is 648
anatoly-scherbakov: and the PR is 650
gkellogg: thanks
… we do also have some things marked as propose close
w3c/json-ld-syntax#443
<gb> Issue 443 `@protected` creates unresolvable conflicts when the same term is defined in two contexts top-level (by trwnh) [spec:editorial] [propose closing] [wr:commenter-agreed-partial] [class-2]
gkellogg: this came in through some confusion and discussion
… and any remaining concerns have been moved to another issue
… anyone object to closing this one?
We'll close the issue pending further input.
w3c/json-ld-syntax#447
<gb> Issue 447 Should `@id` of parent objects be used as a base IRI for relative IRI references? (by trwnh) [propose closing]
gkellogg: it's pretty clear this is not how the system was intended to work
… I suggest we close this without further action
<niklasl> +1 to close
We'll close without further action.
<anatoly-scherbakov> +1
w3c/json-ld-api#641
<gb> Issue 641 Expansion Section 5.2.1, step 7: need clarification (by daenney) [propose closing]
bigbluehat: mostly, I'm just happy with the engagement. But it does highlight "tree-based" thinking leaking into interpreting JSON-LD
gkellogg: thoughts on this one?
bigbluehat: Related to the Jelly folk contributions, we should also try to get ActivityPub folks involed.
… Many commenters have done their homework, which is great.
… It's good to have an engaged audience.
<anatoly-scherbakov> Discussion about visualizing stuff: https://
<gb> Issue 857 not found
gkellogg: any closing issues? or shall we close?
… k. we'll adjourn for the next couple weeks
… please send in topics!
Next meeting in two weeks.
please engage on https://
<niklasl> Just a mention, I'm closer to make a PR on w3c/
<gb> Issue 558 Compaction cannot round-trip terms using `@container: @list` and `@type: @vocab` (by niklasl) [spec:enhancement] [spec:substantive] [ErratumRaised] [class-3]
gkellogg: k. let's adjourn then