Remove the Container .meta mechanism

[dmitrizagidulin]

From the discussion with @timbl yesterday, the decision was made that the current container .meta mechanism is not very useful, and may be counter-intuitive to developers, and so should be removed.

• Currently, a PATCH or a PUT with a body to a solid container puts the triples in the request body into that container's .meta resource. Disable/remove that logic.
• The contents of a container's .meta resource gets appended to the container listing no a GET to that container. Disable/remove logic.
• Update Solid spec to reflect this change.

[dmitrizagidulin]

Discussion came about as a result of PR #513.

[timbl]

One place the .meta is currently used is for people who have their profile in a URI ending in /, like http://csarven.ca/#i etc See gitter discussion https://gitter.im/solid/node-solid-server around Oct 20 12:17 ( https://gitter.im/solid/node-solid-server?at=59ea219ef7299e8f53109eb4 )

[csarven]

Just to have some documentation here: I am not currently using .meta. We were considering the possibility because serving the profile description overlapped with the container description at /. So putting the profile description in /.meta and have it included in the / response along with the container information was a trick. Okay to let that possibility go, in favour of dropping .meta on containers.

[csarven]

Not to stop this issue, but upon further thinking about this in context of versioning, /.meta can be useful, eg. to indicate what is a versioned and if so (un)locked resource, and what is not.

[csarven]

Issue #1040 should be the successor of the functionality to update containers. If that's in place, the feature to update container description via /.meta can be deprecated.

[timbl]

I think (hope) there is a misunderstanding here. These two issues This #547 and the newer #1040 are surely the same function. The .meta file is an internal way in which NSS happens to implement writing triples to a container. The .meta URL is never seen by the client. This issue removed the ability to store arbitrary triples in a Container, #1040 puts it back surely.

[csarven]

/.meta URL is "seen" by the client if they write to it, or at the very least, the HTTP headers have a describedBy relation pointing to it.

This issue proposed the removal but it wasn't removed in NSS. It was marked as revisit. The functionality ( write to /.meta, read from /) remains.

As for #1040 , it is different in that it proposes to only interact with the container URI , but yes, writing triples to a container is retained. The main difference is that #1040 ensures that .meta is never really seen (provided that rel="describedBy" for .meta URI in HTTP headers is also dropped).

[dmitrizagidulin]

@csarven - I second what @timbl said. These two issues are asking for exactly opposing functionality.

[csarven]

@dmitrizagidulin https://gitter.im/solid/node-solid-server?at=5c3d3d3a35350772cf315ca8

[dmitrizagidulin]

@csarven Copy that, thanks.

[jeff-zucker]

It seems to me that the current behavior of write to /.meta and read in / is very useful for app developers. It allows us to tag photos and music easily in a way that an app can easily retrieve it with a single GET on the container. It supports things like dumping an existing database of photos or music into container .meta files and allowing one-step retrieval of the entire container. Am I missing something about why this is bad? Is it really going to go away? Because, if not, I already have several projects in mind (e.g. dump rhythmbox's SQL to .meta files for each container, upload to pod,). Could someone summarize where this issue now stands? Can we count on the write to /.meta, read in / behavior in the future?

[csarven]

The "meta" feature remains. The read/write interface is intended to be through /. Server implementations can decide where to physically read/write "meta" from (behind the scenes) - that's out of spec.

[jeff-zucker]

Yes, I understand that the location of the .meta is implementation specific and findable only in the Link header. What I'm unclear on is whether I, as an app developer, can count on the behavior that the container shows triples found in the container's metadata applying either to the container itself or to what the container contains so that we can retrieve metadata on non-RDF resources. I am asking partially because my collaborators and I need to decide if solid-file-client will support viewing and editing .meta files - we don't want to encourage developers to go down a road that is slated to disappear.

[csarven]

No, that's not what #1040 proposes. The client does not need to know anything about .meta or discovering .meta separately from the thing it refers to. Everything happens through the resource itself. If you have "meta" about /foo/, you write to it directly. So, a server does not need to advertise URI2 for writing just so that when URI1 is read it includes stuff from URI2. That's super weird and IMHO, wrong. If URI1 is what we are talking about, interactions happen through that. We don't need weird magic APIs here. HTTP interface is straight forward.

[jeff-zucker]

What you are saying makes sense for the behavior of the container and its metadata, but I am still not understanding what you propose for resource metadata. Would it also be placed in the container's turtle and editable or would there be separate metadata files for each resource? And if the later, how would we read or write to them without having to find them?