Meeting minutes
<acoburn> previous minutes: https://
acoburn: there will be TPAC in Dublin Ireland
… we should be thinking about our presence there, what kind of meetings we would like to have
… let's start making plans, pchampin would you like to add something?
pchampin: TPAC is good because other WGs and CGs are there, we can organize joint meetings with them
… this year TPAC is the same week as ISWC, many people would like to attend both
… which will be in Italy the same week as TPAC in Ireland, not ideal, something to keep in mind
acoburn: I don't think there is urgency, let's think about potential joint meetings or specific topics that we should discuss
… today we have two votes and two other items to move into queue to vote in following weeks
… first notifications and access requests
… later Terminology, Auxiliary/Metadata, and Type Indexes
… if time allows we will take a look at tasks spreadsheet
Notifications vote #161
<pchampin> w3c/
laurens: this PR replaces previous PR which introduced the base spec
… webhooks were split from the previous PR
… there is PR #162, I want to chat with elf-pavlik about streaming http
<gb> Pull Request 162 feat(notifications): Add WebSocket and Server-Sent Event channels (by laurensdeb)
laurens: i haven't had that much feedback on those PRs
… given that couple of weeks have past, I assume that there weren't any significant issues
… I would like to move #161 to vote today
<gb> Pull Request 161 feat(notifications): LWS Notifications base specification with Webhooks (by laurensdeb)
elf-pavlik: if that's a direct import of the previous PR, I'm happy with it
… I will follow up shortly on the other part
<laurens> PROPOSAL: To merge PR #161 as proposed
<ericP> +1
<elf-pavlik> +1
<laurens> +1
<pchampin> +1
<acoburn> +1
<eBremer> +1
<gibsonf1> +1
<Rbreitman> +0
<termontwouter> +1
<jeswr> +1
RESOLUTION: To merge PR #161 as proposed
<gb> Pull Request 161 feat(notifications): LWS Notifications base specification with Webhooks (by laurensdeb)
I had conversation about streaming HTTP with Rahul in #103
<gb> Issue 103 LWS Notifications Feature (by acoburn) [work-item]
Access Requests vote #106
<pchampin> w3c/
<TallTed> +0 (regretfully, not up to speed following my holiday)
<TallTed> I request that going forward, links to issues/PRs (especially but not only those up for vote/decision) be included in the calendar agenda
<acoburn> PROPOSED: to merge the access request feature as defined in PR #106
<gb> Pull Request 106 Add editors draft for LWS Access Requests and Access Grants (by acoburn)
<pchampin> +1
<elf-pavlik> +1
<gibsonf1> +1
<termontwouter> +1
<ericP> +1
<eBremer> +1
<acoburn> +1
<jeswr> +1
<ryey> +1
<laurens> +1
<TallTed> +0 (as above)
RESOLUTION: to merge the access request feature as defined in PR #106
acoburn: I will merge it over next day or so
Terminology link discussion #164
<pchampin> w3c/
<gb> Pull Request 164 Link terminology to definitions (by acoburn)
acoburn: two weeks ago there was a vote to merge clarification of teminology, following discussions at f2f meeting
… this is not a vote today, i hope we will vote next week
… there are quite a few of changes
… where we use terms in the spec I'm linking to definitions
… we can do it in few ways in dependent specs
… the syntax with `data-cite` is bit inconvienient to use
… pchampin proposed to make proxy definitions that would make it simpler to link to terms
… i'm not changing text, mostly adding tags, few changes are related to aligning terminology as agreed
termontwouter: minor - linkset also ties to the PR on representations, it may need to be revised
acoburn: I'm happy to revise it as much as needed
Auxiliary/Metadata resources discussion #165
<pchampin> w3c/
termontwouter: PR itself only does what it says in the first section
… it rewrites few of the terminology that we have, so it is clearer that there doesn't need to be a specific resource that handles metadate etc.
… metadata representation ????, also the linkset
… we can have linkset as separate resource, but that would be defined on top of the representation aspect
<TallTed> w3c/
<gb> Pull Request 165 Define aux & meta in terms of representations (by termontwouter)
termontwouter: in conformance section i propose that we take the representation as MUST and leave the resource as MAY
… server can choose what it provides
pchampin: to make sure that i understand the consequences of this PR
… currently to get the linkset of a given LWS resource i discover it by a link in the headers of the resource
… would there be a different way to get the linkset or no specified way to get the linkset
termontwouter: the main way is to get it partially via the link headers
… when we talk about reprentation of the linkset, it would change to the content negotiation on the resource itself
… optionally with the link header that is separate from the resource itself
<Zakim> elf-pavlik, you wanted to ask about test suite
elf-pavlik: it would be interesting to discuss with Samu how this could be implemented
… it would make it harder to discuss this
… a practical way would be to write a test for it
<pchampin> one issue that I see with this approach is that a LWS resource could not have application/linkset as its "main" media type
gibsonf1: on elf-pavlik point of implementation, this is how our implementation currently works
… we can test agains it
termontwouter: can you give a pointer to that in PR?
<Zakim> acoburn, you wanted to ask about interoperability
acoburn: i want to bring up issue of the interop and that we have it foremost in mind
<pchampin> https://
acoburn: linkset RFC describes discover via the linkset header
… URI could be the same as the primary resource
… one could possibly have a media type listed
… i could see that as a path, we want to be clear about the interop story
termontwouter: i'm not sure how the linkset spec is written about use of header, i can look at it again
acoburn: i would be happy with the direction of this PR if we can ensure the client interop
termontwouter: i'll give some assurance by next week
elf-pavlik: I can think of the link header as an optimisation
… one could try conneg, and fallback to link header if it fails
termontwouter: #116 contains some examples
<gb> Issue 116 Abstract 'containers' as Link Set representations of arbitrary relational metadata (by termontwouter)
acoburn: please take a look at the PR, I would like to vote on it next week, please be prepared
TallTed: incuding links to those PRs in the agenda would be helpful
Type Index discussion #115
<pchampin> w3c/
eBremer: I made two significant changes, first - there was a request for OR operations
… it's done as conjuctive normal form
<TallTed> w3c/
<gb> Pull Request 115 add Type Index Section (by ebremer)
eBremer: implementation can use additional relations in link headers, not only 'type'
<Zakim> ericP, you wanted to ask about DNF
eBremer: gibsonf1 was asking for MAY on ???, the base line is ANDs and ORs
ericP: wondering if you have preference of CNF vs. DNF
eBremer: I could take a look at that
ericP: if the use cases tend to lean to CNF being more terse ...
gibsonf1: calling it type index is already incorrect given you can search for other things
… i woldn't call it type search
gibsonf1: type index saying that other parameters are not allowed, it doesn't make sense to me
… this is a key feature for implementation to compare on types
eBremer: I'm fine to changing it to MAY
gibsonf1: I made point of NOT being more important than OR
… there is MUST NOT that bothers me a lot
eBremer: I'm fine with changing it to MAY
eBremer: as far as the name I defer to the wisdom of the WG
TallTed: english language has problems with phrase MAY NOT, which is interpret as must not
… i'm going to be looking for it
acoburn: I would encourage people to take a look at PR, I hope we can vote on it next week
Review task spreadsheet
acoburn: we crreated this spreadsheet following the f2f meeting
… there are number of items that are currently done, some are in progress
… some were planned to finish in MAY some were pushed up
<dmitriz> can somebody paste the spreadsheet link to irc?
acoburn: if you see your name, and something hasn't been started, for example - Clarify the semantics on containers
… ryey you have issue on virtual resources
… terminology will be onging task
… pchampin were discussing publishing resources in NS namespace
<Zakim> ryey, you wanted to say about virtual resource
acoburn: ryey can you talk about virtual resources and the threat model?
ryey: for the virtual resources i already have a lot of complicated info in the github issue
<acoburn> virtual resources
<gb> Issue 150 Define Virtual Resource (by renyuneyun)
ryey: : for it i haven't had time to seriously think about that
<Zakim> elf-pavlik, you wanted to talk about threat model
elf-pavlik: I'm going to help with the Threat Model as well.
… I saw that the TM Community Group has cancelled some slots
acoburn: related to test suite and test harness
… the plan is that we will get an update once a month
jeswr: I asked Samu to ask on most stable part of the implementation
… I will get an update for next week
… i asked him to write set of manifests for the tests, similar to SPARQL manifests
… those can be used by the conformance tests harness
<Zakim> elf-pavlik, you wanted to ask about generating tests
elf-pavlik: what do you mean "generate tests"?
jeswr: tests would be described in RDF; a test harness would use these RDF definition to generate Karate Tests (code)
elf-pavlik: my understanding is that the RDF manifest describes what test is for what, but you still need some Karate DSL coded by hand
elf-pavlik: Karate DSL has to be written
acoburn: Karate DSL is where you define mechanics of the test
… the manifest will connect specific test with specific requirement