Meeting minutes
laurens: Introductions and Announcements
… Issue Triage
… Agent Identification #57 - how to proceed?
<gb> Issue 57 Agent Identification (by uvdsl)
<laurens> w3c/
<gb> Issue 57 Agent Identification (by uvdsl)
uvdsl: Stated a proposal in the issue itself, not sure how process works
laurens: added needs-discussion so can discuss later
acoburn: If this is a work-item, how does it fit in? what needs to be dropped?
laurens: w3c/
<gb> Issue 64 Controller discovery should be in the document, not Link headers (by melvincarvalho)
acoburn: Not sure I agree - maybe just add needs-discussion
laurens: w3c/
<gb> Issue 65 Container Requirements Problem (by gibsonf1)
laurens: probably need-discussion as well
… w3c/
<gb> Issue 67 Generalized notion of auxiliary resources (by damooo)
acoburn: was discussed in some degree - but maybe needs-discussion to clarify
laurens: w3c/
<gb> Issue 68 Ability to have general metadata (by damooo)
laurens: maybe needs discussion, potential duplciate?
acoburn: leave duplicate off and can clarify issue later
laurens: w3c/
<gb> Issue 24 Reasons for separate rest bindings (by jeswr)
laurens: unsure whether ready to close? Christoph?
jeswr: Was in the poll
laurens: Anyone willing to take on issue?
acoburn: Summary: there are pros and cons and basically an editorial decision - would be my take
… Couple items have proposed close - not sure additional
uvdsl: Aaron - like your approach and would like to document outcome of discussion
laurens: w3c/
<gb> Issue 18 Prior Art Collection (by jeswr) [propose-close]
<bendm> +1 for close
<gibsonf1> +1 for close
laurens: propose close
… w3c/
<gb> Issue 38 Consider draft-parecki-oauth-client-id-metadata-document for input (by jeswr) [propose-close]
laurens: propose close? ok, closed
… please look at need-discussion items for next week
<laurens> https://
laurens: next up Container discussion
Discussion: Containers
laurens: Removing resources from containers - how to approach semantics?
… what happens when resource removes from last container, do we delete? move? retain container? etc.
… Looking at Solid, this issue pops up less.
<Zakim> acoburn, you wanted to ask about removing resources and relationship to multiple containment
aaron: worried when more than one way to do things. Best to have one way. If server does not support multiple containment, it just doesnt respond?
laurens: If you can remove one, can you remove all, would that be illegal operation?
acoburn: Maybe have dedicated section on multiple containment?
<TallTed> "multiple containment" akin to "hard links" in Unix-like world? vs "aliases" or soft links?
laurens: Second convenience enables by update link relations, to move resources between containers.
<Zakim> gibsonf, you wanted to comment on multiple containment
gibsonf: What is the argument for multiple containment? Are there any implementers interested?
… I agree it should be easy to move resources between containers.
laurens: Multiple containment came from F2F meeting. Its starting to look pretty complicated to implement, but semantic complexity etc.
<Zakim> uvdsl, you wanted to comment on the "action": removing a resource or removing a containment relation
uvdsl: Maybe differentiating between location of resource in container vs deleting resource
tallted: Managing containment is left to the server in LDP and Solid and think it should stay that way. What does containment mean? Thats a challenge. Intention: Unix like storage in web-friendly way. Soft links, aliases, hard links multiple containment. Soft links can use redirects, hard-links it actually exists in multiple places. Master
resource gets the change no matter hard or soft link. Implementation left up in air - we talk about output, not how the input gets to the output - we shouldn't specify implementation.
<Zakim> acoburn, you wanted to suggest indicating multiple containment as "at risk"
laurens: I think its mainly operational but see your point
acoburn: I suspect we won't have as much agreement with multiple-containment as other areas so think maybe to mark at-risk. Lets focus on where majority agree
laurens: Maybe splitting into to PRs to cover multiple-containment. Lastly deleting containers, operational semantics, should cascading/recursive deletes be supported? The wording needs more detail.
uvdsl: We should point out that operation should be atomic. Without permission, whole operation should not be executed.
laurens: Haven't covered authorization on container delete yet
acoburn: authorization spec assumes things are atomic
<Zakim> bendm, you wanted to ask about bulk operations
bendm: Bulk operations - delete multiple in one atomic in multiple containers, moving things, etc. Is that in scope?
laurens: Has not come up yet, but if use cases cover that we could support that - but brings in some complications. Unsure we can easily support this.
<TallTed> atomicity suggests ACID, all of which is desirable, but difficult to deliver, particularly at scale
bendm: I bring it up since we are talking recursion in a single container might be same spec/complexity
<Zakim> gibsonf, you wanted to comment on bulk
<laurens> gibsonf1: It could be simple to do, if you're request is about a resource URI, you could list a bunch of resources and specify what operations to perform.
laurens: Depends on what a resource is. Don't see how that would work if resource is natively in a storage.
<TallTed> "prepare deletion" is when the services check permissions, etc. This can be parallelized.
<TallTed> "execute deletion" is when they get deleted, all at once, as an atomic action -- all succeed or none do.
laurens: Right now as the draft sits, assumption that there is a resource with a URI path within the storage. Resource URI is just a URI in the storage. I'm not sure how you would move URI outside of that storage, not sure how.
<Zakim> acoburn, you wanted to mention prior art with webdav
laurens: that makes sense if its all in the same storage
<bendm> oeh I love that idea
acoburn: We should look at prior-art with webdav - maybe we don't have to define it ourselves
laurens: agree with that suggestion
… moving on to Container Media Type
<uvdsl> w3c/
<gb> Issue 61 LWS Container Media Type (by acoburn) [needs-discussion]
acoburn: Brought this up at json-ld meeting last week (to get good advice). If we do json-ld profile, run into CORs issues, maybe say its equivalent applicion/lws or application/lws-json . CORs is a key issue. Advice to use application/lws+json (no profile) or (I'll pull up the document)
<acoburn> As with Web Annotations
<acoburn> Content-Type: application/ld+json; profile="https://
<acoburn> As with Activity Streams
<acoburn> Content-Type: application/ld+json; profile="https://
<acoburn> -OR-
<acoburn> Content-Type: application/lws+json
<acoburn> As with CID / VC
<acoburn> Content-Type: application/lws
<Zakim> uvdsl, you wanted to suggest alternatives outlined in w3c/
laurens: I'm concerned with application/lws interfering with existing JSON based clients in frameworks.
uvdsl: an additional alternative: Server defines resources - depending on what client requests, response will be what it is per spec. Content-type headers adapted to request
laurens: I don't think spec prohibits that. Do we want that required? Not strong opinion
uvdsl: Proposal not to invent the wheel again - when general solution works fine.
acoburn: I agree with uvdsl, other specs clarify in definition how to use general solution. Forgot to mention , one advantage with application/lws - allows us to define a file extension. Gives potential leeway into downloading containers etc might work.
laurens: Json-ld context and framing. Context warrants separate discussion, do we want single context for most things or do we want to split it out, versioning, etc. Need separate agenda time to discuss
<Zakim> acoburn, you wanted to talk about json-ld / vocabulary
acoburn: Would leave it as now as informative, can create canonical discussion later.
laurens: normative json-ld frame.
acoburn: I didn't define anything in the spec yet. As we clarify we can define in one go.
gibsonf1: The example JSON-LD context refers to paging here. It should be discussed separately.
<TallTed> see: scrollable cursors, in DBMS world
gibsonf1: The concept of a page is problematic here.
… Industry standard is to have a start and offset.
<TallTed> the cursor window varies (number of records, number of fields per record, etc.)
gibsonf1: The server shouldn't know about the pages.
laurens: Might make sense to go back to paging discussion. I think you want to see this go with query string?
<TallTed> where the window falls (offset) also varies
<Zakim> acoburn, you wanted to talk about requirements and scope for paging
<pchampin> +1 that the current proposal does not prevent gibsonf1's proposal
<pchampin> -1 to the claim that this is what everyone™ is doing
<TallTed> also, again, remember that HTTP paging is byte based,
acoburn: I think we should talke about this next week and work out the details
<Zakim> gibsonf, you wanted to comment on example json-ld
laurens: Yes, lets discuss paging next week
<uvdsl> Quick question, is there already some information about the next face-to-face meeting?
laurens: also look into webdav has done and can use it in this proposal
<TallTed> LWS > Solid > LDP > WebDAV > basicHTTP
laurens: there is some information on f2f, Jesse?
<uvdsl> alright, I'll stay tuned :)
jesswr: April 29th?