RE: Interpretation of POST operation given large relationship collections

Hi Gregg,

On 12 Okt 2014 at 21:36, Gregg Kellogg wrote:
> The primary (only?) way of updating a Hydra resource is through an
> operation using the POST method. This would seem to have some small

As you probably know, you can use whatever method you want.


> 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> .

We decided to call this hydra:collection and not hydra:hasCollection.


> <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;

Right, but you should probably use a more specific operation here to tell
the client what happens if that POST is send.

>     hydra:method "POST";
>     hydra:expects schema:Movie;
>     hydra:returns schema:Movie

Did you really intend to write schema:Movie here or was this intended to be
schema:Review?

>   ] .
> 
> A client has know way to know that schema:review is managed by a
> collection without retrieving the resource (fine). From an RDF

I think to remember that we discussed adding a flag to indicate that a while
ago (maybe when I met you in SF?). Something like hydra:managedByCollection
on SupportedProperty. I haven't thought about that much and am actually not
sure we need it but it is certainly an option to introduce that if we find
use cases that would benefit from it.


> 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.

That's why you made it a paged collection in the first place, right?


> 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?

Well, we don't know because you didn't specify it. You would need to type
the operation with something more explicit. That's the whole purpose of
typing operations.


> Perhaps marking the property readonly: true would give sufficient

I assume you are talking about the review property, right?


> 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?

I think you are talking about a PUT here and wanted to describe how to
update the movie, right? The problem then is what to do with the reviews
property. I think marking it as read-only would be a good idea. That way a
client would know that it can't change it directly. It would then need to
figure out that there's a collection managing that subject-predicate pair by
looking at the information in hydra:collection (or evaluating the
hydra:managedByCollection flag described above, but I think it isn't really
necessary). As soon as it found that information there, it would also know
how to interact with that collection. That could either be operations using
LINK or POST, which I think makes more sense in this example as the review
will always be bound strictly to a specific movie.

Does that answer your question?


--
Markus Lanthaler
@markuslanthaler

Received on Tuesday, 14 October 2014 11:52:27 UTC