GET Container potential conflict

[gibsonf1]

lws-protocol/lws10-core/Operations/read-resource.md

Line 48 in d8a4de3

Accept: application/ld+json

Will the spec be edited to have the specific Accept used to get a container representation as opposed to the generic "application/ld+json" which, if the Container is also a Data resource, server would not know what to do?

[pchampin]

I agree that having Accept: application/lws+json would probably be better in this example, but I disagree that the current example is ambiguous.

if the Container is also a Data resource, server would not know what to do?

The spec currently states: "Resources in LWS are classified as either: Container [...] Data Resource" (emphasis is mine). So the situation you describe is not supposed to happen.

[gibsonf1]

I agree that having Accept: application/lws+json would probably be better in this example, but I disagree that the current example is ambiguous.

if the Container is also a Data resource, server would not know what to do?

The spec currently states: "Resources in LWS are classified as either: Container [...] Data Resource" (emphasis is mine). So the situation you describe is not supposed to happen.

Exactly, this is a flaw in the current spec with either Data Resource or Container. If a data resource is data, in what way would a container not be a data resource? Wouldn't you want to be able to have all the same kind of data with a container as with any other data resource, such as labels, icons, comments etc? And when performing a GET on that URI, wouldn't you want to get that same data resource data in the same format with the container in addition to the container specific contents? The only reason to either/or this is if we are building a file system where we have directories and files which would radically limit the possibilities for the future of LWS.

My point is effectively that a Container is a species of Data Resource, differentated by containing other data resources.

[elf-pavlik]

I'm not sure if another issue is needed for this discussion. I think the most recent one is

• Abstract 'containers' as Link Set representations of arbitrary relational metadata #116

[TallTed]

Wouldn't you want to be able to have all the same kind of data with a container as with any other data resource, such as labels, icons, comments etc?

Uh, no?

Sometimes, I might want to see all comments, and nothing else.

But much more often, I would want to see some kind of a thread, which would involve an initial post and some number of comments thereon, each of which probably include some icons, avatars, and the like, plus some labels, perhaps some tertiary or more distant comments, etc.

I do not want to be forced to organize my data the way you like to organize your data. Nor should you be forced to wedge your data into my organization patterns.

[gibsonf1]

Wouldn't you want to be able to have all the same kind of data with a container as with any other data resource, such as labels, icons, comments etc?

Uh, no?

Sometimes, I might want to see all comments, and nothing else.

But much more often, I would want to see some kind of a thread, which would involve an initial post and some number of comments thereon, each of which probably include some icons, avatars, and the like, plus some labels, perhaps some tertiary or more distant comments, etc.

I do not want to be forced to organize my data the way you like to organize your data. Nor should you be forced to wedge your data into my organization patterns.

Ted, the point is that you can have any data you want on a container, no matter what it is, in the same manner you can have any data you want on a non container. The point being that there should be complete interop on a GET for that same kind of data whether container or not, and that a GET on a container gives the app the data associated with the container in the same format as any data resource as well as the container specific contents data - all with a single GET.

[TallTed]

I think this depends a lot on how far you/I/we want to carry the file/folder metaphor. In our living world, we can write on paper (files) we put into folders, and also on the folders themselves, whether or not we nest folders. The nesting is a thing we well understand from directory structures. But the writing on the folders is a thing that has had varying levels of support in any way — comprehension, implementation, etc.

I think the idea that you can do a single GET to retrieve a container along with all of its marginalia (the notes on the folder) as well as the container's contents is certainly desirable — but I think the user should achieve this single command by the software issuing multiple commands. This is not unlike using ftp or curl to recursively retrieve a remote directory's ls and all of its contents. Most filesystems of which I'm aware do not expose their container marginalia by default through either ftp or curl interaction — but there are flags you, the user, can use to tell these tools to do what you want, through a single command issued by you, but multiple calls made over the wire.

[gibsonf1]

@TallTed I think a better analogy here is with Linked Data rather than good old 20th century files and directories, as this whole effort is supposed to revolve around Linked Data.

With that said, I think the best and most scalable protocol is the most simple one that gets the job done. If an application can simply make a LWS json-ld GET request on a resource uri without knowing anything about what that resource is (which will be the typical case), and if that resource happens to be both data and container, it would make things very simple for the response to include both the data and container contents in their protocol prescibed format in the same payload. Otherwise, how would this work? And why would we want to complicate this, what value would be added?

[TallTed]

I think that "Linked Data" is a stepping stone between "good old 20th century files and directories" and "LWS (Protocol)". Linked Data, as you know, makes the identifiers — familiar from the file-tabs and cross-reference notations within files and directories — dereferenceable, typically by using HTTP URIs/URLs/IRIs for those identifiers.