Meeting minutes
Introductions and announcements
acoburn: from Lauren: don't book tickets too early. But probably going to hold a face to face meeting on 8-9-10 Oct in Ghent. To confirm by 29 July.
ericP: Is remote possible?
acoburn: To confirm by Laurence. Maybe possible, but can't say for sure.
acoburn: Some take vacations on August. Don't if any chairs are around on 11-18 Aug. Either we cancel the meeting, or to have the structured meetings led by editors for specific topics.
<Zakim> bendm, you wanted to say to edit 37/9
kaefer3000: The proposed dates should be in the minutes.
acoburn: We are dancing around the proposed dates, as other things may be in the dates (e.g. DID)
<kaefer3000> Christoph (uvdsl) is also unable
jeswr: Other than Tobias, are there any other people can't join the conference if date conflict?
kaefer3000: it's often 8-10 for many conferences. Are there other possibilities?
ryey: might have conflict in Oct, will know this week
<Zakim> acoburn, you wanted to talk about date constraints
acoburn: There are lots of constraints for choosing the days... such as many other conferences. Also availability for Ghent. We'll see with Laurence to see when is possible. Realisticly there is no perfect date.
Action Items
ericP: Now to the real action items
ericP: Any weekly summary of closed issues?
acoburn: Usually Hadrian does this
Continued clarification of requirements
ericP: Ok, so no action, and next item
<Jackson> I was not here last week
ericP: anyone not here last week?
acoburn: we are at the stage of sorting out use cases. some are vague, and/or under development. our current goal: get to a stage to triage and cut the number of use cases.
<acoburn> Requirements
acoburn: trying to clarify and collect the UCs. Last week we got to #37 (from bottom up). We are skipping #36... We are starting at #35 today.
<ericP> PR to merge SPARQL reqs (36 and 19)
Requirement 35 View-Based Data Sharing
acoburn: please pay attention to: Can they be done without LWS protocol to specify this? I.e. can they be done in a different layer? Or, does LWS protocol supporting this providing much added value?
ericP: there are several issues for 35. 63 describes a lot of how they got there.
… another is for a projection or filesystem, and makes it look like a filesystem?
… another is selective access to data, to present it in a projected/derived resource
gibsonf1: it's about access control, or not? access control on the view?
<Zakim> gibsonf, you wanted to ask how is view-based different than access control?
acoburn: I won't say it's all about access control, but the problem is part about access control.
kaefer3000: I want to make an opinion, not to ask a question.
… acoburn's question is if this can be supported on a different layer? My opinion is yes.
acoburn: This is exactly what I'm interested to hear for the meeting.
… to hear about whether something is in scope or not
<jeswr> https://
jeswr: I want to second kaefer3000. I'm involved in this thing for two years ("what's in a pod")
… what we want LWS to support is a view into the hybrid KG described in that paper. Other things (views) are somewhat out of the scope of LWS
acoburn: We are not voting on this. There is a general consensus that view-based sharing is out of the scope of LWS protocol.
Requirement 34 Group-Based Access Control
acoburn: Now to next one, for group-based access control
<Zakim> gibsonf, you wanted to ask can we add hierarchies
gibsonf1: Groups may have different hierarchies. Can other hierarchies be supported? E.g. groups of groups?
acoburn: I can't think of any systems supporting groups of groups
gibsonf1: Unix does
Jackson: Is this for group-based for access control view? Does this also apply for credentials?
acoburn: We are doing requirements, and that can lead to different solutions. So, the two solutions may both be involved in the requirement. We'll decide that (solution) later.
ericP: Do you want to capture consensus on priority?
<Jackson> +1 for priority of group based access control
acoburn: Maybe not for now, unless editors find it useful
Requirement 33 Profile Management
acoburn: next item
… Profile management. I don't see this has any related issues
eBremer: Could go to github issue #29 #57
<gb> MERGED Pull Request 29 chore: add required editor approvals and timelines for PRs (by jeswr)
<eBremer> w3c/
<gb> Issue 57 [UC] Custom resource rendering when visiting URI using browser (by renyuneyun) [triage] [usecase] [uc-data-management]
acoburn: 29 is definitely about identifiers for different users and different providers, and synergy between them
Jackson: I don't see distinction between this and the default (anyone can create multiple accounts/identifiers).
jeswr: I manage multiple accounts, by multiple emails. I can come up ad hoc solutions for having different inboxes. But that's different than allowing same inbox for multiple accounts.
… Sometimes I don't want my storage root (URL) to reveal who I am.
Jackson: so you don't want to bind your storage with a specific account?
jeswr: There may be a requirement to require the same resource be assigned different URLs, for privacy (of inferring identity from URL).
Jackson: So that's for resources in general, not just profiles
jeswr: Yes. For profiles, I would like everything to be changeable (resources/info about profiles / storage)
Jackson: So that's not just about profiles, but resources in general. That can be a general issue for having identifiers.
<Zakim> gibsonf, you wanted to ask could we argue this one needs a UC written up?
kaefer3000: The views may also be an alias, to some degree.
<bengo> If the question on #33 is: should this be a priority, it seems like the answer is yes. regardless of exactly how it is implemented.
gibsonf1: This sounds quite difficult. Who creates that redirect URL? URL representing who owns something is a critical infrastructure.
… Maybe we can think about HTTPS. By having a different URI, maybe each service may have a different certificate?
jeswr: I'll write up the UC to make sense. Clarification: my comments don't mean I'm in favor of having this item preferred.
Requirement 32 Clear Error Messaging
acoburn: Next item: clear error messaging
<acoburn> Problem Details
acoburn: sounds great, but there are other specs for similar things. E.g., IETF document I sent. Question is: do we need to explicitly say this?
<Zakim> ericP, you wanted to argue that this doesn't need tracking
ericP: I think it won't help us to do our work by having a trackable error message. We can do that automatically
Requirement 31 Performance and Scalability
acoburn: Next item: performance and scalability. I don't have an idea what this implies, as a normative thing.
<Zakim> ericP, you wanted to argue that this doesn't need tracking
acoburn: Maybe we should open the individual PRs (for the previous two items) to indicate them being removed.
jeswr: As editor, we can note that right now
Requirement 30 Scalable Storage Management
acoburn: Next item: scalable storage management
… this sounds more implementation-specific, not storage-specific. Maybe it's possible to logically support merging different storages in the implementation
ericP: Maybe reword as "mergeable storage management"
<acoburn> +1 to what tobias said
kaefer3000: Maybe specify this is for backend, not for protocol
jeswr: agreed. we may also want to remove the view-based?
ryey: my rationale for supporting views is that this would need to be supported by a client that is always running or the protocol supports a mechanism for how views are handled
… the second way would need something in the specification
… the first way would need synchronization or holds a separate storage
… different caveats for each, may be better to allow the protocol to support this
<bengo> supportive of removing this ("logical unification of disparate back-ends"). it doesn't seem possible to do very well without getting into distributed transactions which is very nontrivial, and probalby easier to approach if/when there is a v1 API worked out, rather than trying to take it on at the same time as an api.
ryey: suppose the storage provides a view where data is modified from schema 1 to schema 2
… automatically built into storage (one option)
… handled by client (second option), but gets complicated when writing data back to storage
<ericP> e.g. App1 understands FOAF but doesn't recognize the subset of schema.org that corresponds to FOAF
jeswr: this is also like profile negotiation
<ericP> profile negotiation
<ericP> -> lead to this conneg WD
<AZ> Content Negotiation by Profile: https://
<ericP> ADJOURNED