How should we handle metadata of non-RDF sources (was Treatment of .meta files)

[jeff-zucker]

As far as I can tell from testing, .meta files work for containers but not resources. It would seem that a .meta should function as a sidecar file for non-RDF resources e.g. for tagging photos or categorizing music. For that use case, they should be tightly bound to the file they reference - should be copied, deleted, etc. when the resource is copied/deleted. I also believe they should be (or have the option to be) listed with GET and editable. We'll be doing those things as much as we can from the client side in solid-file-client but it seems like it should be a server side thing and that the the spec should address it.

[michielbdejong]

I must admit I've never really understood .meta files, and I didn't (yet) implement then in IPS. I think they are used to support setting titles on containers. Maybe we don't need .meta files in the same way we need ACL docs? Do you know if they're documented somewhere?

[jeff-zucker]

Here is the most I've been able to find : https://github.com/solid/solid-spec/blob/master/content-representation.md#metadata

It seems to indicate something similar to what I described as a "sidecar file" for non-RDF resources. If I want to tag a photo, or categorize an mp3, I'd like to do that in a way that is strongly associated with the resource itself. Metadata files seem ideal for this. So let's say I have a container /photos including foo.png. In foo.png.meta I describe the photo in RDF. When I do a GET on /photos it lists foo.png along with its metadata as taken from its metadata file. Container .meta files work like this in NSS now. If you have /photos and in /photos/.meta you put a triple stating that the Container is a giraffe, The next time you visit /photos, the triple stating it is a giraffe will be there just as if you had put it in the turtle. That doesn't seem all that useful for containers because we can just add triples in their turtle directly. But we can't do that with non-RDF files and it would be really useful to be able to.

[jeff-zucker]

And an observation from experimenting with NSS: unlike .acl file .meta files do not block a container from being deleted. If the container has only a .acl file in it, we get a 409 if we try to delete. But if it has only a .meta file, the delete succeeds.

[jeff-zucker]

I imagine metadata files working something like this:

A container containing a single png file.

  .../photos/
      <> a ldp:BasicContainer;
          ldp:contains <foo.png>.

      <foo.png> a png:Resource.

  .../photos/foo.png
      nothing to see here, png files can't talk.

Same container with .meta files

  .../photos
      <> a ldp:BasicContainer;
          sch:title "Family Photos";
          ldp:contains <foo.png>.

      <foo.png>
          a png:Resource;
          sch:about "my last birthday".

  .../photos/.meta
      <> a meta:Resource; sch:about <./>.
      <./> sch:title "Family Photos".

 .../photos/foo.png
      still can't talk.

  .../photos/foo.png.meta
      <> a meta:Resource; sch:about <foo.png>.
      <foo.png> sch:about "my last birthday".

[jeff-zucker]

The above would be an app developer's dream come true compared to all the gets and link header parsing one would need to do otherwise. As I said, containers already work like this in NSS, so maybe it would not be so much work to do the same for resources.

[jeff-zucker]

Doing it as above rather than making the app get the same data would be save one extra GET on the container's meta and a HEAD on each item then a GET on its meta. That's a lot of hits.

[csarven]

nodeSolidServer/node-solid-server#1040 proposes to simplify the interface for container read/write and meta handling.

[jeff-zucker]

Would this be a good summary of why we need metadata, how it works now, and how it could work? Is the bit about exposing triples in the container an agreed on goal? If so, app developers can depend on that regardless of how NSS or others implement it. And, If so, shouldn't it be part of the spec? If not, what is the goal and how does it provide the ability to easily find metadata for non-RDF resources?

[RubenVerborgh]

Although I obviously like the view realized with metadata, we shouldn't create a false dichotomy. The goal of "readable titles for non-RDF files" can be realized in several ways, one of which is .meta. The question is rather whether .meta is the desired mechanism to achieve this and the other goals.

[csarven]

I think with the exception of NonRDFSource case, the notion of "meta" as a distinct resource can disappear.

[jeff-zucker]

The goal, as I understand it is to allow non-RDF resources to be described with RDF in a way that supports them becoming part of the same universe of discourse as RDF resources which can talk for themselves. Desktop apps do this by inserting data into the resource itself (e.g. digikam with EXIF, XMP, etc. data and photos). Using .meta "sidecar" files puts the data squarly outside the resource itself which brings other problems. Has anyone proposed using headers instead? A GET gives you the resource and the metadata, a HEAD gives you the metadata without the resource, there are no extraneous sidecar resources which need to behave differently from other resources. The server can implement however it wants , giving users no access to where the metadata is actually stored, only supporting user interaction via headers.

[csarven]

I'm not sure if the headers is a good place for this. For navigational purposes, perhaps one can get away with Link perhaps.. and that the relation is strictly about the resource and no fragments involved. How would the fragment of a NonRDFSource be described through headers eg. video.

Edit: I also don't think it is particularly safe to expose arbitrary properties through headers. The headers is something the server should have good control over and not easily manipulated by an application.

[jeff-zucker]

I think there are ways around your first point, but your second point is probably a show-stopper. [edit: meaning : oh well, no, headers is not a good idea]

[jeff-zucker]

What if the user can send a header that says only "I am talking to the metadata, not the resource" such that a GET on foo.png with that header sends back metadata and one without sends back the resource. And a PUT/POST/PATCH on foo.png with that header edits the metadata and without the header writes to the resource itself.