Meeting minutes
Announcements and Introductions
bigbluehat: no announcements
Tooling Resolutions
bigbluehat: we need a resolution on ECHIDNA for publication
<bigbluehat> PROPOSAL: use Echidna for publishing our publications
<ivan> +1
<anatoly-scherbakov> +1
<bigbluehat> +1
<niklasl> +1
RESOLUTION: use Echidna for publishing our publications
YAML-LD check-in
anatoly-scherbakov: ivan posted an issue about editorial stuff
… and there's a PR about `@json` value objects
… with a re-review requested by Pierre-Antoine
<gb> Pull Request 184 [#36]: Add informative JSON literals section with YAML examples after Scalar Value Types (by anatoly-scherbakov) [needs discussion]
bigbluehat: we just discussed this one a couple weeks ago
anatoly-scherbakov: there is some discussion that might branch off to JSON-LD also
bigbluehat: can continue discussion on GitHub
CBOR-LD PRs & Issues
<gb> Pull Request 63 Add discussion of processing model and semantic compression. (by wes-smith)
wes-smith: semantic compression on a JSON-LD document is based on all contexts it uses
ivan: worth spelling out that registry will have a specific entry for a combination of contexts
ivan: cannot combine registry entries of two contexts
wes-smith: semantic compression in a vacuum can work without a registry entry
ivan: a registry entry for VCDM is used with another, business vocabulary. They have two contexts
ivan: we will need a separate registry entry for the combination of VCDM + business context
wes-smith: registry entries are not per-context
wes-smith: registry entry just says 'use semantic compression'
wes-smith: no need to create a registry entry per context
wes-smith: semantic compression is done dynamically on the set of all used contexts
ivan: it might be expressed more clearly in the spec
wes-smith: that's the main outstanding point from the PR
wes-smith: would like to get this merged by EOW
ivan: happy with having this PR merged as is, and creating more PRs for further issues
* +100500 about small PRs better than big ones
wes-smith: not planning adding to the PR, just having some time for people to review
bigbluehat: this is much to the editor's discretion
wes-smith: will merge on Thu or Fri
<gb> Issue 12 Plain JSON is considered as compressed CBOR-LD (by filip26) [propose closing]
wes-smith: just raised another issue to the same end, I think we can close this
<gb> Issue 55 Add links to JSON-LD spec(s). (by BigBlueHat) [good first issue] [editorial]
bigbluehat: can take this on
<gb> Issue 56 Update IANA CBOR Tag registration links. (by davidlehn) [good first issue] [editorial]
bigbluehat: taking this too
<gb> Issue 59 CBOR-LD Registry as RDF? (by anatoly-scherbakov) [needs discussion]
wes-smith: making registry machine readable is probably out of scope
wes-smith: individual implementations do not necessary need that
wes-smith: the effort might not be worth the result
wes-smith: we can keep it open for maybe a later version of the spec
bigbluehat: agreed; if there's an interest in exploring this though from someone it would be interesting but not from the spec side
… which might be limiting
wes-smith: not sure if this would be in scope of the spec anyway
wes-smith: core CBOR-LD spec does not need to specify it
bigbluehat: agreed, more of a side project
wes-smith: it has conceptual value but a lot of work needed
bigbluehat: anatoly-scherbakov are you OK if we close this and see if it resurfaces?
anatoly-scherbakov: certainly. I'm not very closely familiar with the use cases for CBOR-LD, so not sure how useful this would actually be
… it was more of a curiosity
ivan: how do we set up, manage, develop the registry?
ivan: this question will arise when we put up a working draft
bigbluehat: there is DID method registry
ivan: that's more complicated and not as essential
ivan: CBOR-LD Registry is simpler, no review board or IPR
wes-smith: CBOR Tag registry is a great example
wes-smith: smaller numbers are most desirable as they're more compact
wes-smith: CBOR Tag registration process depends on tag range
wes-smith: for a smaller tag, you need to come up with a great spec for a mature technology
wes-smith: larger tag numbers are first-come-first-serve
ivan: who do I contact to provision a new entry?
ivan: the first questions are 'where' and 'how'
ivan: how does CBOR community do it?
bigbluehat: they use IANA
ivan: can't get IANA to get to care on this one
wes-smith: can we follow w3id registry model?
bigbluehat: it is a delegation space not a governance space
bigbluehat: creation of a new identifier is first-come-first-serve
ivan: w3id has a very clear goal
ivan: do not think we should mix it up with CBOR-LD Registry
wes-smith: majority of CBOR-LD registry would be ok to behave on first-come-first-serve basis
wes-smith: for one byte IDs (or some other precious range) we can do something similar to an expert review process for CBOR
wes-smith: we can setup an email address to submit such a proposal
wes-smith: for everything else, raise a PR
dlehn: why not using GitHub for this?
bigbluehat: we are
dlehn: would be fine to open a PR instead of writing an email
ivan: GitHub repo under W3C is possible but we are uncertain if we want to bind it to a GitHub URL
ivan: we could expose W3C URLs to the registry entries, currently bound to GitHub but that could be changed if need be
ivan: people working with the registry are developers who consider GitHub a natural tool
ivan: we do not want to etch the github URL into someone's code
ivan: we might move the registry on W3C and make a redirect to it
bigbluehat: how important is URL permanence?
wes-smith: the URL permanence is not very important
wes-smith: entries themselves must be immutable or close to that
wes-smith: location can change
ivan: at some point we'll have to specify that in a specification
bigbluehat: W3C URL is less about findability but more about authority
bigbluehat: even github.com/w3c should not be considered equivalent to w3.org
bigbluehat: can we change YAML format if meaning stays the same?
bigbluehat: maybe I will file an issue about this
<gb> Issue 47 Add discussion of processing modes and their uses. (by wes-smith) [needs discussion]
wes-smith: a PR needed here but a small one
wes-smith: should say that the processing mode mechanism is an extension point
wes-smith: you can define your own processing mode in a registry entry
wes-smith: we will be explicit about the default mode and you can make your own in the registry entry
wes-smith: there's an existing PR there but it does not explain what to do if user wants a different processing model
wes-smith: commented there
wes-smith: this becomes editorial
bigbluehat: remaining issues are too much for the remaining time, bye all!