Use fcr:metadata to assign properties to resources

[awead]

Whereas fcr:content used to return the content of a resource, now fcr:metadata will allow you to define properties on a resource that also has binary content.

[cbeer]

And, like with fcr:tombstone, don't just use .../fcr:metadata. Get the path to the description from the describedby Link header on the binary.

[jcoyne]

@awead Did you have a specific use case here, beyond what is already supported in the code (versions)?

[escowles]

Following up on questions raised about datastream properties and versioning:

• You can assign arbitrary properties to a content node with SPARQL Update. So if you have a content node /rest/obj1/ds1, you can PATCH /rest/obj1/ds1/fcr:metadata with the query "insert data { <http://localhost:8080/rest/obj1/ds1> <http://purl.org/dc/elements/1.1/title> 'test title 1'}".
• When versioning a content node, the properties in fcr:metadata are versioned too.
• The main use case for attaching properties to a content node is for technical metadata, such as format name/verison, codecs used, resolution/bitrate/etc., scanner make/model, etc. These are properties of the bitstream itself, not the Work/Component: for example, a Work might have a master content file and derivatives. The technical metadata would describe each individual file and be different for each one.

[awead]

@jcoyne I was thinking we'd use fcr:metadata to hold all the non-content data about the bitstream, such as original_name, mime_type, and any arbitrary fields that @escowles mentioned. It could also be where you'd put rights metadata if we wanted to be able to control rights access to different datastreams.

[jcoyne]

@awead those properties in particular already have a place in the headers:

• Content-Type (mime_type)
• Content-Length (size)
• Content-Disposition (original_name)

[awead]

@jcoyne what about rights metadata or the other technical metadata @escowles describes? This would also allow us to enforce restrictions at the datastream, which has always been a need in the community.

[awead]

Fixed via #582