Closed elf-pavlik closed 3 years ago
RubenVerborgh
commented
4 years ago I'm a big fan of the above indeed. Just want to note that @timbl is not, his primary concerns relating to resource integrity/copyability (i.e., what triples actually belong to the resource).
That could be addressed with profiles though https://ruben.verborgh.org/articles/fine-grained-content-negotiation/, with anything non-bare requiring a specific profile.
csarven
commented
4 years ago For example where Resource Description of container includes human readable label for that container, server may want to optimize responses by including that information directly in representation of the container.
A human-readable "label" is not "metadata" especially for RDF bearing documents.
Injecting or embedding as you describe is an anti-pattern we have already moved away from ie. the describedby resource's contents appearing in the resource that it describes - like a label. The point was that each resource is distinct and can be self-describing. If a container needs a label, it should say so itself. Moreover, handling information becomes problematic if something like a label magically appears in some other resource. That opens up a far more complicated and unnecessary design. Rather solve the simple case first. This is also aligned with Tim's concerns. See https://gitter.im/solid/node-solid-server?at=5c3d3d3a35350772cf315ca8 which is an agreement that was reached at the root of being able to update containers directly.
elf-pavlik
commented
4 years ago If a container needs a label, it should say so itself. Moreover, handling information becomes problematic if something like a label magically appears in some other resource.
We need human readable labels for Non-RDF Sources, having label in Resource Description metadata doesn't seem magical to me. ShEx has Named Graphs proposal which would cover requirements like specifying that rdf:label should appear in a specific graph. (See around Using the following syntax we can define that for a certain arc the triple are stored in another graph )
I also see support for not allowing PUT on the container, which may create special case of a resource which allows PATCH but doesn't allow PUT. Since for Non-RDF Sources label has to go in resource description. I think implementers could actually find it easier to always store it there, instead of:
Plus for displaying labels, for example listing of a container, application needs to fetch actual resource instead of just fetching resource description. If container has mixed RDF and Non-RDF content client first would need to do HEAD on each resource to avoid fetching binary files while just trying to get label to display for each contained item.
Anyways, since possibility of embedding metadata in resource representation comes as an optimization, I think we can defer discussions on possible ways of doing it for later.
csarven
commented
4 years ago We need human readable labels for Non-RDF Sources, having label in Resource Description metadata doesn't seem magical to me.
I was referring to RDF bearing documents (containers). Their labels need not go into the "metadata" resource linked via describedby.
If I'm looking for the label of:
I create this issue as follow up to https://github.com/solid/specification/issues/144#issuecomment-580391937
For example where Resource Description of container includes human readable label for that container, server may want to optimize responses by including that information directly in representation of the container.
I think this could work in very clean way especially for quad based representations. It reminds me of @RubenVerborgh's article https://ruben.verborgh.org/blog/2015/10/06/turtles-all-the-way-down/ In that case I would consider hypermedia of the resource as another type of its metadata.
Even for triple based representation we could consider embedding resource description in resource representation. In that case client would not know from which graph embedded triple came from so it couldn't make writes to source of those statements.
Possibly we could only recommend embedding for quad based representations and triple based representations would require following link relations and fetching resource description separately. With HTTP/2 I don't think it makes any significant difference.