What is stored in RepresentationMetadata

[communitysolidserver]

What is stored in RepresentationMetadata

[RubenVerborgh]

Does that mean that a BodyParser has to convert all the corresponding headers to triples for an incoming representation?

It can be lazy though.

And I guess this gets stored in the corresponding .metadata entry then?

Yes.

Is it necessary to store these as well for incoming triples (which would make things like contentType a bit weird)?

Yes.

However, I would implement this on an as-needed basis. We found triples the most extensible mechanism to also account for future link headers etc. But I don't think it's a priority.

[joachimvh]

Some more metadata questions:

What needs to happen with metadata when passing through a converter of some sort? E.g. input data is text/turtle but this gets converted to Quad[] in the BodyParser, and then ingested into a SPARQL store. Should metadata fields (and triples in raw) that reflect byteSize, contentType, etc. get removed and/or changed then?

What is supposed to happen with the metadata during a PATCH request?

If I understand correctly metadata is supposed to have its own URI (in the current client this is uri + .metadata). This is then returned in a Link header when accessing the resource (which will have the same problem as #16 on how to get that header to the output, should probably be an issue on its own). Can this have its own metadata then?

(I think the answer to all of the above could potentially be that metadata is only used for binary input, but then the field would have to be optional probably).

The only non-optional field according to the architecture (besides raw) is profiles. It was mentioned before that this was not really relevant yet, but it feels a bit weird to currently have to add it as an empty array every time.

[RubenVerborgh]

What needs to happen with metadata when passing through a converter of some sort? E.g. input data is text/turtle but this gets converted to Quad[] in the BodyParser, and then ingested into a SPARQL store. Should metadata fields (and triples in raw) that reflect byteSize, contentType, etc. get removed and/or changed then?

Metadata should probably reflect the actual current contents indeed.

What is supposed to happen with the metadata during a PATCH request?

For the entity body? That would likely be preserved.

If I understand correctly metadata is supposed to have its own URI (in the current client this is uri + .metadata).

I don't think we currently have this in the spec. This would likely just be a convention for a filesystem-based backend, but not exposed.

(I think the answer to all of the above could potentially be that metadata is only used for binary input, but then the field would have to be optional probably).

It would also be relevant for non-binary input, for instance to indicate content-language.

The only non-optional field according to the architecture (besides raw) is profiles. It was mentioned before that this was not really relevant yet, but it feels a bit weird to currently have to add it as an empty array every time.

Oh, feel free to drop it for now.

[joachimvh]

If I understand correctly metadata is supposed to have its own URI (in the current client this is uri + .metadata).

I don't think we currently have this in the spec. This would likely just be a convention for a filesystem-based backend, but not exposed.

I forgot to mention this but I got my information about the metadata URI from the "spec" here

If it would not be exposed though, do we need a way to access metadata without getting the representation?

[RubenVerborgh]

I forgot to mention this but I got my information about the metadata URI from the "spec" here

solid-spec has some outdated parts still; I don't think .meta is relevant at the moment, @csarven?

If it would not be exposed though, do we need a way to access metadata without getting the representation?

If you do a HEAD, it would be in the HTTP headers.

[joachimvh]

If you do a HEAD, it would be in the HTTP headers.

Might be interesting to have a getMetadata function in the ResourceStore interface to get the metadata without having to do potential work to acquire the data stream?

[RubenVerborgh]

Might be interesting to have a getMetadata function in the ResourceStore interface

My current thoughts were to rely on laziness; so if the data is not read, don't generate it.
Because I don't think HEAD will be all that common.

But yes, could be an optimization if needed.

[joachimvh]

Some more metadata musings:

Regarding the incoming and outgoing metadata. Currently the BodyParser would handle both data stream (usually by doing nothing, but potentially validation and in the case of PATCH parsing), and the metadata. But chances are the different BodyParsers would handle the metadata the same (just parsing headers to an object and to triples), so either we need a separate MetadataParser next to the BodyParser or as constructor argument for most BodyParsers.

We also have metadata going the other way, when requesting a Representation from a ResourceStore. Getting the raw metadata triples should be easy since those are stored by the ResourceStore, but who is going to convert them to the members of the RepresentationMetadata object? We could have a (another ;) ) ResourceStore that simply handles the conversion of those triples to actual object values. But that would mean the original stores output "invalid" metadata objects with only triples and no filled in fields. Although those fields are optional so it could be said that they are not required to be filled in if the triples are there, it feels wrong to do so. That would imply that checking if the contentType field is filled in is not sufficient (which is what I do already in some cases), you would also always have to check if the triples are potentially present, making the other fields somewhat redundant.

Makes me wonder if we should only make use of the triples when passing from BodyParser to ResourceStore, or from ResourceStore to ResponseWriter (who would then have to convert those back to headers, so another place conversion will be needed). Other classes that need actual header values somewhere inbetween could call a parser that returns a filled in RepresentationMetadata object. Still feels a bit muddy since there will still be several places where metadata conversion will happen.

[csarven]

I forgot to mention this but I got my information about the metadata URI from the "spec" here

Please use solid/specification as canonical reference. Alternatively, for the time being, use https://solid.github.io/specification/ as what's currently drafted.

Ruben is right that ".meta" naming convention is not relevant because the Solid spec does not define a URI Template for servers to use when naming auxiliary resources, and in this case it is descriptive resources (discovered through rel=describedby on resource that's directly associated with). How servers manage that association is deemed to be an implementation detail.

[joachimvh]

Mostly answered by #65