Meeting minutes
Introductions & Announcements
acoburn: 2 weeks ago, we had a f2f meeting that was hugely successful
… we have a few new people can you introduce yourselves?
roberto: I am Roberto Breitman, I'm Brasilian living in Belgium
… I've been in Solid for a while
… my background is in computer science
Terminology PR #153
<acoburn> w3c/
acoburn: I updated the document on terminology
… order alphabetically the terms
… added cross links from terms to terms
… all other documents should link terminology to this document
… pchampin added a few entries
… you can use the diff view to see what changed
… I removed some empty sections
… there were no definition for some terms, they were removed
… that's what the PR does
… can we move to a vote?
jeremycaine: I did raise an issue on an entry
… we should create an entry for data resource
… maybe the current spec is ok but I'm not enough an expert but I had a concern
termontwouter: the general PR is quite good but have a question on metadata resource
… we left it out then readded it
… I'm not sure if the PR capture correctly the definition
acoburn: metadata resource needs additional work
… maybe we can leave it out for the moment
… or merge it like this and change later
<jeremycaine> I think we should go with the vote for the terminology - but per my comments in issue 155 I think we need to see more concrete examples of Data Resource lifecycle to cater for different actual implementations of the actual underlying URI object
termontwouter: either way, if you keep it like this, I can propose a refinement
<jeremycaine> apologie for not following IRC protocol
TallTed: few things
… first, I am not ready to vote because I was not aware their would be a vote
… I will be offline next two Mondays, May 18 and 25 (25, last Monday in May, is Memorial Day in US)
… second, word of caution for new members coming from Solid group
… this is *not* Solid WG
… although it deals with overlapping pieces with Solid
… this group is on Linked Web Sotrage so it is more focused
… last, regarding leaving out a term, I would not like leaving or deleting things out if this is something that must be fixed for later
acoburn: were you referring to the empty sections that were deleting or the metadata resource definition
TallTed: I was refering to metadata resource but the others are also concerned
gibsonf1: the metadata resource describes another LWS resource
… just replace "another" with "a"
… and for the definition of "resource" the definition is not quite accurate
<TallTed> grammarian note -- replace "another" with **"an"**, not "a"
gibsonf1: a URI is an interface to a resource
pchampin: the wording about URI is taken from architecture of the WWW
… the current wording does not contradict the point you make
… I would agree it is interfaced because with an information resource it's not just an identifier but an entry point to the resource
gibsonf1: ok understood
termontwouter: we could rephrase the metadata and auxiliary definitions to better accomodate gibsonf1's point
… this could be done in the future though
<Zakim> gibsonf, you wanted to ask about principal resource
gibsonf1: I noticed "principled resource", do we need that?
… can you explain why we need it?
<Zakim> pchampin, you wanted to react to gibsonf
pchampin: I added this text, I'm not strongly advocating this term
<termontwouter> in the London meeting we used 'primary'
pchampin: it was useful to have a name for the inverse relation of "auxiiliary resource"
gibsonf1: it seems it would be good enough to have the notion of auxiliary resource
pchampin: I do not say it is a necessary term but in some definitions, it is cumbersome to explain thing without it
<termontwouter> +1 for primary
gibsonf1: "primary" seems better than "principal"
acoburn: we need to have more conversation on this, let us not vote on it today
<Zakim> TallTed, you wanted to raise a meta point, and to raise a workflow issue
<pchampin> gibsonf1, I thought about "parent", but decided against it to avoid confusion with containment relationship
TallTed: regarding this definition, it is not obvious that this is an addition on this PR
totalItems PR #157
<TallTed> w3c/
TallTed: this is another PR from the conversation had in the f2f meeting
… we're not going to vote this week on it, but I'd like to highlight it
eBremer: about counting the number of items in a container
… it can be very difficult to have an acurrate count so it should not be a "MUST"
pchampin: "SHOULD" means "do it unless you have a very good reason not to"
… it is less strict than MUST but still quite strong
Test Suite PR #145
<TallTed> w3c/
<gb> Pull Request 145 test: create strawman test suite (by ericprud)
acoburn: this PR has to do with the test suite
… opened by Eric a few weeks ago
… again, we can vote on it next week
ericP: the first draft of the test suite wqs there to capture ....[breaking up a bit]
… we have to test the mechanism for ....
… I made something with the MANIFEST
… it can be merged without interacting with other documents
… please take a look at the MANIFEST,
… I try to work on it to ... but that's pretty optional
laurens: one question, do we want the test suite to live in the same LWS protocol repo
… should we make another repo for this?
pchampin: a separate repo would be ok
… both practices exist in W3C WGs
… I would be in favour of it, but it's up to the group
<laurens> +1
acoburn: I'm also in favor of this
… Samu Lang, who was at the f2f will be working on the test suite
laurens: I will reach out to Samu
Upcoming votes
acoburn: we will vote on this next week but if this goes to another directory, we may not approve the PR directly
… I'll do some work on access requests and access rights
… what else could we discuss/vote next week
laurens: I have a PR open for quite some time that we could split in 2
<laurens> w3c/
<gb> Pull Request 129 feat(notifications): Introduce the LWS notifications specification as an optional service (by laurensdeb)
acoburn: another point is the type index
eBremer: will work on it next week
acoburn: some of the terminology items have to wait for the terminology to be merged
… e.g., virtual resources
… whether it is in scope is questionable
<ryey> Sure. I'm drafting it today. Will try to get it out today, or Thursday.
acoburn: regarding auxiliary resources, wouter has some ideas?
termontwouter: I can provide something soon
acoburn: what else would you all like to be participating in?
there is a document for tracking the tasks: https://
<Zakim> acoburn, you wanted to ask about whether Access Requests should be an independent document or integrated into core
<elf-pavlik> later this week I should have access to PC and will follow up on notifications via streaming http responses
jeremycaine: I can help but I need to know better about the mechanics of the github repo usage
acoburn: the process is usually to open issues and discuss on github
… occassionally we work on Google docs and then we open PRs, and discuss, and then eventually merge
acoburn: any other business?
TallTed: decisions made next week should be provisional because I'll be away
<pchampin> FWIW, group decisions made on calls are always provisional, I believe.
acoburn: so I will
<TallTed> "decisions made on calls are always provisional" -- yes, for the following 7 days, according to typical process (I don't know whether this is codified in w3process or the Guide).