Interpretation of POST operation given large relationship collections

The primary (only?) way of updating a Hydra resource is through an operation using the POST method. This would seem to have some small conflict with the use of hydra:Collection to manage resources having a potentially large number of relationships.

Imagine an entity such as a Movie, with a large number of reviews. It might be reasonable to manage the reviews through a paged collection, due to the potential for a very large number of such reviews:

<GoneGirl> a schema:Move;
  schema:name "Gone Girl";
  hydra:hasCollection <GoneGirl/reviews> .
<GoneGirl/reviews> a schema:PagedCollection;
  hydra:manages [hydra:subject <GoneGirl>; hydra:property schema:review ]

schema:Movie would be extended as a hydra:Class, with schema:review as a supportedProperty. schema:review would also be a hydra:Link. Using the existing SupportedProperty, this might look like the following:

schema:Movie a hydra:Class;
  hydra:supportedProperty [
    a hydra:SupportedProperty;
    hydra:property schema:review;
    hydra:readonly false;
    hydra:writeonly false
  ];
  hydra:supportedOperation [
    a hydra:Operation;
    hydra:method "POST";
    hydra:expects schema:Movie;
    hydra:returns schema:Movie
  ] .

A client has know way to know that schema:review is managed by a collection without retrieving the resource (fine). From an RDF perspective, the schema:review triples all have the same subject <GoneGirl> pointing to different reviews. When I retrieve the resource, I don't get all these reviews, even if I indirect through the paged collection, maintaining all triples referencing the review could take a fair amount of space.

The point of the question is, what is the interpretation of POST? Does it replace all the triples having the same subject (presumably including referenced/referenced resources having a BNode subject including those managed through a collection? Does it exclude resources managed by a collection? What about if there is a propertyPath specifying the subject resource using a reverse relationship?

Perhaps marking the property readonly: true would give sufficient information that the property can't be managed this way, and operations must be performed on the associated collection or using a LINK/UNLINK method on the resource? Otherwise, requiring the client to post all such relationships is unfeasible, and we have no other communication mechanism to say that they should/must be excluded from the resource representation when doing a POST.

Thoughts?

Gregg Kellogg
gregg@greggkellogg.net

Received on Sunday, 12 October 2014 19:36:59 UTC