– DRAFT –
Linked Web Storage WG

<acoburn> Scribe list https://github.com/w3c/lws-protocol/wiki/Scribe-list

Introductions & announcements

acoburn: today will be part II of the metadata conversation
… goal: establish consensus so we can start drafting text (which will neccessitate more consensus)

Server-managed vs user-managed metadata

acoburn: we're continuing from last week's metadata conversation
… we have user-managed stuff we wlll need to accomodate in specs
… the "extensions" section is stuff we won't intend to specify

bengo: why is "data integrity" out of scope?

acoburn: the stuff we're specifying supports data integrity but we're not specifying it directly

acoburn: we have these user-managed and server-managed types...
… we can partition this list into those groups
… or we can let impls decide

TallTed: i see mod time in server-managed
… also think the "user-manmaged types" should go away

<bengo> if the user signs over a timestamp (and they should), the server can't change it

TallTed: user has no control over e.g. created time. managed by the server

<bengo> We should perhaps distinguish between wall 'clock time' and causal/relative 'tick time'

TallTed: for the most part, the server is managing while the user is requesting

acoburn: how about "Last-modified" is server-managed?

<Zakim> ryey, you wanted to comment on relation between customized metadata and server-managed metadata

ryey: i agree
… re relation between user- and server-managed metadata, is it allowed for the user-managed to include some same predicates?
… if so, overrides? extends?

<bengo> In POSIX the modified time is managed by the user, not the kernel (iiuc) so this would be pretty different.

acoburn: i was imagin we have two link rels, one each for server- and user-managed metadata
… if the user want's to e.g. define a container as something else, it will be clear which came from the server

bengo: this implies that the "one" server (potentially zillions of machines) agree on time

acoburn: one option for mod-time is to simply leave it up to HTTP

<bengo> +1

[acoburn strikes out ModificationTime item]

TallTed: just as HTTP handles mod-time, it also handles media-type

acoburn: i think these are different types. there's a Content-type header with a media type value, and there's a Link with rel="type"

<bengo> 'managed' is often ambiguous. is there a better word?

TallTed: the user sets the media-type but the server manages it

<Zakim> bengo, you wanted to ask what it means for content-type to be 'server managed' if the client sets it in requests

eBremer: [example of zip called a jpeg]

bengo: why would we call this server managed if the user is the locus of authority

<dmitriz> +1, agree with @bengo

<gb> @bengo

ericP: if our litmus for user-managed is what can the server change, we would have no user-managed because the server can always changes stuff

bengo: if the media type includes the media type, the server changing it would break the media type

dmitriz: this argument seems odd, if we s/server/filesystem/, we'd not ask whether the filesystem would change content type

<Zakim> acoburn, you wanted to describe meaning of server managed

<bengo> server provides the property of durability etc, but it is confusing to say it 'manages' it without more precise language

acoburn: "server-managed" is probably the wrong term. i think it came from Fedora. I was tying to get at the notion of "server-managed" the idea of data that the server should reproduce without changing

<dmitriz> @acoburn - yes, I believe so. there's some metadata that is specifically set by the storage server, that user cannot directly alter

<gb> @acoburn

acoburn: a client can PUT with a new media type
… if you replace a five-byte file with a ten-byte file, that was managed by the client
… if i have an ACL at /1 and a client wants to move it to /2, should it be allowed?

<dmitriz> in terms of server-managed, the server records (and the client cannot change _directly_):

<dmitriz> in terms of server-managed, the server records (and the client cannot change _directly_):

TallTed: we're rehashing an argument that's been going on since the dawn of time
… LDP forbids the client from overwriting metadata

<bengo> are we obliged to obey LDP? no right?

<bengo> esp wrt 'the server is in charge'

TallTed: even with a PUT, the server is in control. at least in theory it can't change the content, but that's debatable

<dmitriz> @TallTed - I think there's a difference between 'persits' and 'manages'

<gb> @TallTed

<acoburn> bengo: no we are not depending on LDP (at least Solid does not require it today)

TallTed: if the resource is RDFa, the server must understand the RDFA stuck in any version of HTML

<bengo> the server never has to edit a file, it only has to maintain an operational history of changes

TallTed: so if you're trying to change the relations in RDFA, the server has to understand it

<dmitriz> no, we are not inheriting LDP

TallTed: if we're going to rehash these arguements, the WG won't finish

acoburn: let's skip over this user-/server-managed metadata issue by simply saying there's a set of data that a server is responsible for persisting [for the user]

acoburn: Solid curerntly has a described-by link header (used in but not specific to LDP)
… there's not specification of what the described-by data is, what format it's in, what authority it has...

<bengo> with wallet.storage we have also been using application/linkset (RFC 6924)

acoburn: eBremer has been working on linksets
… once you have a linkset resource, you can update it without changing the file it describes

<eBremer> @bengo isnt linkset rfc9264?

<gb> @bengo

<bengo> eBremer oy yes, sry typo. thanks

eBremer: HTTP link headers are nice but can result in header bloat
… linksets avoid this bloat

<bengo> +1 to all this. it has worked really well. using linkset+json

eBremer: you can also consider it JSON-LD

acoburn: specifically, the link header turns into link headers

bengo: i've been using this for a few months and it's been working well
… some folks get upset when you stick "@context" in JSON

<gb> @context

bengo: one link header use case is adding contexts without shoving it in peoples' faces

acoburn: it's a lot easier to write a client to parse/update this JSON rather than any type of serialization

<bengo> Also wroth noting that ActivityStreams2 defines RDF for 'Link' and 'Collection' which is kinda like a LinkSet

acoburn: we have options for how to divy user and server data can be managed by saying that all data has to be in Link headers, which is very constraining

<Zakim> bengo, you wanted to share about how dmitri and i got to this

acoburn: do we want to say that that there are explicit user-managed metadata resources?

dmitriz: we can start with just the linkset?

bengo: we might want more types of metadata resources

<bengo> if you have linksets, you dont necessarily need 'metadata resources' because any resourced linked to can be thought of as 'metadata resource'. it's just a linked resource.

bengo: so we'd want to use linksets to give us that flexibility

<bengo> https://www.rfc-editor.org/rfc/rfc9264.html

<acoburn> PROPOSAL: LWS will make use of linksets [RFC 9264] to describe metadata resources

<ericP> +1

<dmitriz> +1

<bengo> +1

<acoburn> +1

TallTed: does this mean everyone has to use linksets?

<TallTed> -0.5

acoburn: that would be a minimal requirement

<eBremer> +1

<RazaN> +1

acoburn: is there some change to this proposal that would change your -.5?

<ryey> +0

TallTed: i don't think we've implemented it. will need to see how difficult it is to implement

acoburn: i see general support, we'll revisit this later

<ryey> +0.5

acoburn: next week, i want to move on the storage metadata, and contrast that against the metadata for a specific data resource