Meeting minutes
<TallTed> pchampin -- you need to `/invite` with the `/`
Announcements and Introductions
bigbluehat: Welcome to the JSON-LD WG. Any introductions or announcements?
<ajs6f> Hi all!
ajs6f: My name is Adam Soroka, here representing the Apache foundation. I also work at the Smithsonian institution, which is interested in JSON-LD for publishing metadata out of our collections. I have a cultural heritage/museums/libraries background.
YAML-LD Issue curation (20 minutes)
bigbluehat: For the next while I want to split the call as much as necessary into YAML-LD and CBOR-LD pieces.
… My expectation is that gradually the YAML-LD side will decrease and CBOR-LD will increase as YAML-LD is mostly down to editorial issues.
… There was some discussion on the mailing list of a complete reboot of YAML-LD.
… My recommendations on the mailing list were that the group needs to stay the course to get YAML-LD published, and if such a thing should exist it should be a separate effort.
<niklasl> +1
bigbluehat: PR 170 is ready to be merged, it is just setting code owners.
Issue 83 use regular expressions to resolve literals; URIs, CURIEs (by VladimirAlexiev) [UCR] [needs discussion]
pchampin: I think I raised a similar issue some time ago. What we might want to point out is that a lightweight form of what he is asking for is already possible with @vocab
… I also want to point out that this is not YAML-LD specific in my opinion.
bigbluehat: I will propose closing issue 143.
… I want to hear from folks about streaming, if it is something we should dig into.
Issue 63 YAML Streams and JSON Sequences (by ioggstream) [spec]
niklasl: We've been using NDJSON as big dataset dumps for some time and would like to do something to help out with that.
… We would appreciate if we were able to contribute to doing something with that, but we would need a general discussion on what the streaming use cases are. We like that you can parse each chunk and inspect it in-memory.
… Our consumers are more accustomed to the JSON form that we have published.
… You don't need a specific parser, just stream each line and then parse each line with off-the-shelf tooling.
… Other approaches to streaming might not adhere to JSON-LD's design principle where off-the-shelf tooling works if advanced features are not needed.
bigbluehat: One route is for us to bring the community group back to explore progressing things like that. There is RDF streaming work ongoing with lots of discussion of topics like NDJSON. Has YAML stream stuff been reviewed by the group?
niklasl: I don't expect our users to want that, I have seen pushback on YAML-LD. YAML parsers aren't in browsers, standard python libraries, etc.
… YAML parsers are more complex than JSON.
bigbluehat: I know a former coworker of mine is using YAML-LD heavily, mostly via AI, to generate what would have been JSON-LD, but they want comments and other features that YAML-LD supports.
… I do think that before we switch lanes to CBOR-LD we should discuss if anyone has thoughts on the streaming section specifically.
… We might revisit this. I think we can close this issue.
<niklasl> +1 to use Turtle
bigbluehat: To recap, I encourage that the group should not entertain the discussion of reworking YAML-LD here, but instead move to finish YAML-LD and say that the lightweight alternative should be a separate technology.
niklasl: There are tradeoffs inherent in the designs of these things, but agreed that the tradeoffs proposed in the mailing list don't make sense for the group to focus on currently.
bigbluehat: We should ship YAML-LD 1.0 as a cross compatible JSON-LD 1.1 expression. This gets to the last thing I wanted to say on this topic - one of the things that YAML-LD provides is that folks want to use YAML-LD to write contexts for use with JSON-LD. This means we will end up with a linked data parser that needs to be able to take a JSON-LD
document with a schema.org context and understand a YAML-LD expression of this.
… I know of people saying that writing contexts in YAML-LD is easier, and it would be good to feed that to a JSON-LD processor without conversion. This falls under the space of context publication and content negotiation.
… The question is "when in the ecosystem do we expect the yaml to turn into json"
anatoly-scherbakov: Regarding a YAML-LD context, I suppose that a parser that is capable of YAML-LD should be capable of understanding a YAML-LD context.
… I argue CBOR-LD and YAML-LD should not directly integrate into JSON-LD to avoid combinatorial spec explosion.
<niklasl> +1 keep the core simple
anatoly-scherbakov: Regarding the mailing list discussion, I proposed we could reuse the profiles functionality of JSON-LD to define custom simplified profiles.
… A certain profile could be defined as a subset of JSON-LD keywords.
niklasl: I am cautiously positive to that, we discussed it previously but there is something to say for a compact but not idiomatic form that uses @id and @type.
<niklasl> (well, and @context, for the compact form ;D )
bigbluehat: Agreed, that gets close to the requested functionality as far as I can tell. One of the things that drove 1.1's feature expansion was the idea that you can and should be able to apply an @context to "found json".
… before the pressure has been on JSON-LD to accommodate all JSON shapes, but we need to come to some agreement on that core question.
<niklasl> Agree on the thoughts. :)
anatoly-scherbakov: There is one issue that we might have missed on YAML-LD. I have prepared a draft PR that contains an example where the id of a node is equal to an expression which is resolved to a date.
… That is a problem because a date cannot be concatenated to a string.
… This might not be an editorial PR but instead a new piece of logic in the specification.
… I will complete the PR and we can review on a future call.
bigbluehat: Consequently we will table YAML-LD as a time blocked topic but will do brief updates at the beginning of each call.
… We will revisit YAML-LD mid-to-late march and focus on CBOR-LD for the next few weeks.
CBOR-LD Issue curation (20 minutes)
bigbluehat: any top of mind CBOR-LD issues?
wes-smith: Number 47
Issue 47 Add discussion of processing modes and their uses. (by wes-smith)
wes-smith: we've got an underspecified processing mode mechanism in the spec
wes-smith: it allows to choose the subset/superset of compression technologies to use
wes-smith: this relates to CBOR-LD codices
wes-smith: current codecs evolved organically
wes-smith: we want them to be more modular and extensible via processing modes
wes-smith: we want people to be able to create their own codecs
wes-smith: we currently do not specify the details of these mechanisms, going to focus on this topic
wes-smith: contributions welcome
bigbluehat: which section is important in this context?
wes-smith: section 4.5
<bigbluehat> https://
wes-smith: we expect to add codecs to, say, efficiently compress datetimes
(yes I heard 'codecs' as 'codex'...)
* No, I think codec -> codecs
adam: any examples?
<bigbluehat> looking at digitalbazaar/
wes-smith: implemented codecs include datetimes, HTTP URLs, etc, where we squeeze a few bytes efficiently compressing values
wes-smith: registry describes a piece of logic associated with a specific type
anatoly-scherbakov: from what I understand this ties a bit of logic to a type to do the compression
… how is this described in the registry? JavaScript? Any language?
wes-smith: we don't know yet
… it's up for discussion
… it's probably not binding to a specific language
… but we know that one does work
anatoly-scherbakov: Web Assembly?
wes-smith: worth considering
anatoly-scherbakov: do you do the registry handling via any RDF related specifications?
… or will it be an HTTP endpoint or REST API?
wes-smith: what's the machine readable form of the registry?
anatoly-scherbakov: yes. Is it an RDF document defining what to do?
… it could be. This format `compressedWith` this logic.
… and do inference, etc.
… do you want to do that?
wes-smith: I hadn't yet thought about the machine readability of the registry
… I need to think about this one more
ajs6f: motivation is basically efficiency
ajs6f: is it formalized?
wes-smith: compression is primary motivation of CBOR-LD
wes-smith: CBOR-LD is doing an arbitrary transormation of JSON-LD which just happens to be compression
wes-smith: maybe it can be information hiding
wes-smith: I see other uses for various transformations of JSON-LD
<ajs6f> Bye all!
<ajs6f> Wow, that YAML-from-hell doc is amazing. I am now terrified to use YAML in anything. :)