-
Notifications
You must be signed in to change notification settings - Fork 121
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is stored in RepresentationMetadata #18
Comments
It can be lazy though.
Yes.
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. |
Some more metadata questions: What needs to happen with metadata when passing through a converter of some sort? E.g. input data is 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 + (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 |
Metadata should probably reflect the actual current contents indeed.
For the entity body? That would likely be preserved.
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.
It would also be relevant for non-binary input, for instance to indicate content-language.
Oh, feel free to drop it for now. |
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? |
If you do a |
Might be interesting to have a |
My current thoughts were to rely on laziness; so if the data is not read, don't generate it. But yes, could be an optimization if needed. |
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 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. |
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. |
Mostly answered by #65 |
Some other issues already mention this as well. One of the mandatory fields of a RepresentationMetadata is the raw array of Quads. Does that mean that a BodyParser has to convert all the corresponding headers to triples for an incoming representation? And I guess this gets stored in the corresponding
.metadata
entry then? Is it necessary to store these as well for incoming triples (which would make things like contentType a bit weird)?The text was updated successfully, but these errors were encountered: