Meeting minutes
Introductions and announcements
[no announcements]
Issue triage
laurens: one new opened issue #97
<gb> Issue 97 Right approach to mark some likely editorial issues of the docs? (by renyuneyun)
acoburn: we don't need to do much on this, let's propose-closed
laurens: yes, good
Former Editors section
laurens: currently, we mention several former editors of the Solid protocol in the LWS core spec
… but we have more input documents, e.g. Fedora protocol
… so that's currently strange, also inconsistent with, e.g. VC data model v2.0
… I suggest to restructure that part to only include the editors and authors to the current protocol text
… and move former editors in acknowledgements section
… that's consistent with most other W3C docs
<TallTed> +1 acks section for contributors via input documents
laurens: so we can also acknowledge the solid CG and Fedora CG
… I would like someone to do this restructuring, any thoughts?
<dmitriz> +1 to restructuring
TallTed: yes, contributors to input docs don't belong in the former editors structure
<acoburn> +1 to restructuring
<eBremer> +1 to restructuring
TallTed: we could also leave it to referring to the input documents themselves
<eBremer> I'll do it
<pchampin> +1 to restructing
<Wonsuk> +1 to restructuring
acoburn: this is a pretty easy pull request, so if you'd like to contribute, this is a pretty simple way to do that
<dmitriz> I'm happy to volunteer
<dmitriz> to make a PR
laurens: dmitriz, you're very welcome to make a PR
Access Requests status and open questions
acoburn: we have an early draft right now
… hopefully, next week we can open this up to everyone
… we're going to do some work on it first, e.g. looking at other data models such as ODRL
… once it's more stable, it'll be opened up
… so it's currently a couple of pages
<dmitriz> +1 to separate doc
acoburn: question is: should it be a separate doc, or integrated?
… there are advantages either way
… a decision right now doesn't commit it
… for the long term
… so, any comments on that?
gibsonf1: currently it's 10 pages, does that mean it's a very complicated thing to implement?
acoburn: goal is that it's not complicated
… section 1: use service metadata + example
… section 2: protocol: these are LWS containers, process them as such + extra features
… you should be able to implement this using vanilla LWS containers, but you might want to add more features
… section 3: how this ties to Notifications spec (although the Notifiations spec part isn't ready yet)
… section 4: the data model, most volatile, takes a lot of text
bendm: +1 on separate doc
<Zakim> bendm, you wanted to say +1 on separate doc
<eBremer> +1 on separate doc
acoburn: there are going to be some terms defined in the jsonld context
… should we have a separate context, or a combined context?
… it's a different decision
<bendm> +1 on integrated context
acoburn: integrated context is easier for clients, marginally easier for servers
<eBremer> +1 on integrated context
<pchampin> +1 on separate specs, and +1 on an integrated context
laurens: also in favor of integrated context, possibly type scoping
TallTed: when considering a separate doc is warranted: let's ignore examples in that decision
… the english prose is fine, that increases the functional length, but jsonld does not add to the functional length
acoburn: examples indeed take a huge amount of space
<Zakim> bendm, you wanted to ask whether that matters for testing
bendm: separate doc or integrated: is that editorial or does that matter for eg conformance testing?
TallTed: doesn't matter: Optional is optional
acoburn: back to context: should we define in the same LWS namespace?
<bendm> +1 to one namespace
<pchampin> +1 to one namespace
<Zakim> bendm, you wanted to clarify versioning
<eBremer> +1 to one namespace
<Luke> +1 to namespace
<Wonsuk> +1 to one namespace
<pchampin> +1 to version context documents, -1 to version vocabulary namespaces
bendm: we want to version the context document, so as not to make things harder in the future?
acoburn: yes, we version context document, we do not version the vocabulary
<bendm> +1
Luke: open discussion is balance between the more enterprise-type features and less enterprise-type features
… we can discuss that more once more people had a look at it
acoburn: goal is to make it possible to create enterprise features, without requiring everyone to do such things
bendm: to ask about external services vs internal services
acoburn: there's no limitation/constraints on the url of the service: could be internal or external
<bendm> +1
Status of other core work items: test suite, notifications, type index, vocabularies
<laurens> https://
laurens: the other core work items
… for the test suite, there is an NLNet grant
… to improve the existing Solid test suite
… to validate LWS compliance
… in terms of timeline, we need to see whether this matches the LWS WG timeline
… this test suite is quite critical
<Zakim> acoburn, you wanted to mention timeframe of grant
acoburn: the link says that that NLNet grant will start this month
… so that sounds good
laurens: on notifications
… I don't think we have anyone to volunteer leading this initiative
… so anyone volunteering, that would be great
acoburn: I'll set an action for me to open github issues
ACTION: acoburn to open GitHub issues for each of the work items: test suite, notifications, type index
<gb> Created action #100
<Zakim> bendm, you wanted to ask about external services vs internal services and to ask about solid notification vs ldn
bendm: what notifications are we talking about? solid notifications or LDN?
acoburn: there are multiple notifications
… real-time notification, e.g. websockets on updates of resources
… offline notifications, i.e. you wanna be informed when something got changed
… Linked Data Notifications is very relevant, but lacks the authentication portion of it
… my opinion: LWS could contribute as to how authentication works
… we wanna reuse the data models and inboxes, but it does not describe how it handles authenticated requests
laurens: on type indexes
… gifsonf1 you will volunteer to propose something there?
gibsonf1: yes, will have something by next week
laurens: finally, vocabularies and jsonld contexts
… we draft quite some terms
… and uris
… so it makes sense to gather this in a voc
… and a normative jsonld context
… maybe it's a bit early now, but it's something we will have to address
<Zakim> acoburn, you wanted to ask about timing of vocab resources
acoburn: pchampin, what's a good strategy here?
pchampin: DID did do a publish soon and often with a beta marker. The only normative thing is publish on /TR, but publishing on /ns also gives some weight to some people, so we should publish something reasonable there
… we could already publish with a clear marker
acoburn: so, timewise, somewhere around CR is a good moment
pchampin: yes, but if you want to already draft something for testing, have a clear marker
acoburn: and could we already build something on Github without publishing?
pchampin: publishing on github is a good thing, and things changing on github is more in line with the expectation of users
… Ivan Herman developed a tool where the vocabulary is mostly described in a YAML file, and generates the context, turtle, html artefacts
<pchampin> https://
<acoburn> +1 on a single source of truth
pchampin: single source of truth + close contact with the developer
laurens: I'll try it out
ACTION: laurens to set up yml2vocab for the as-is terms in the specification
<gb> Created action #101
Status of ancillary work items: solid migration, use cases & requirements
laurens: idea was to have a note drafted to migrate from Solid to LWS
… we cannot really lead that work item, but we can help the Solid CG
… pavlik is also following the chat
… I think it makes sense that someone from the Solid CG leads that
laurens: about use cases & requirements
… we did a lot last year
… we haven't done prioritization yet
… we should do that and update the UCR
<Zakim> acoburn, you wanted to talk about prioritization
acoburn: the listing of the requirements was prioritized, but we did not clarify what was in and what was out
… we started working on the themes, but a lot of work still needs to be done
… I'll reach out to Hadrian
laurens: we should reach out, but also finalize that doc
… so we can move along with the specification work
… if anyone else would be volunteering to lead on the UCR doc, that would be encouraged
WebID-CID document proposal
laurens: quite some discussion on #96
<gb> Pull Request 96 Propose Web-CID Profile for Agent Identification (by uvdsl)
laurens: some issues: there are things that go beyond the scope of https
… I propose people to chime in on the discussion on #96
<Zakim> acoburn, you wanted to talk about scope and timeframe
laurens: my last comment tries to summarize up to now
acoburn: there are a lot of interesting things in that proposal
… but I'm also concerned about how much time it would take up to approach all of the PR's ambitions
… I wonder whether we can create a new authentication suite that limits URIs to CID-URIs
… I think that's all we have time for
pchampin: +1 to acoburn and laurens
… reducing the scope does not mean the rest is not interesting
… uvdsl acknowledged that the scope went beyond the WG scope
… so it's more about splitting the efforts in 2 different venues, than limiting the scope
laurens: we could create a new authn suite to limit the CID-URIs to HTTP-URIs
… if you create a authn suite that identifies using HTTP-URIs, that fits within the scope of the charter
acoburn: I think that solves the concerns of Christoph
laurens: it would also solve how other contributors could restrict a set of resolution mechanisms
<Zakim> acoburn, you wanted to mention FPWD
acoburn: we are moving along with FPWD publication
… target date is 24 or 26/3