Re: Interpretation of POST operation given large relationship collections

Hi Gregg

> On October 12, 2014 at 9:36 PM Gregg Kellogg <gregg@greggkellogg.net> 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 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 ]
>

I was attempting to work my way through an example like this using SKOS instead
on Schema.org [1].
Following best SemWeb practices I had modeled the entity and the information
about it as separate resources, in your example that might be:

<GoneGirl> a hydra:Resource ;
  foaf:primaryTopic <GoneGirl#id> .
<GoneGirl#id> a schema:Movie ;
  schem:name "Gone Girl" ;
  hydra:collection <GoneGirl/reviews> .
<GoneGirl/reviews> a hydra:PagedCollection ;
  hydra:manages [hydra:subject <GoneGirl#id> ; 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?
>

I'd expect that a POST on <GoneGirl> would append any triples in the request
body to the <GoneGirl> resource, but perhaps a PUT would better apply here to
replace the resource with the request body?

If I wanted to add a new review, would I POST a representation of that review to
the <GoneGirl> or <GoneGirl/reviews> resource? Personally would expect the
latter in the case where a hydra:Collection is used.

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

In case where a hydra:Collection is used to manage the schema:Review list, I'd
expect the schema:review property to not even be present in the <GoneGirl>
resource.

I'm wondering what I need to POST to the <GoneGirl/reviews> resource.
As my new review has no identity yet, it'd be a blank node I assume.

_:b0 a schema:Review ;
  schema:itemReviewed <GoneGirl> ; # or <GoneGirl#id>
  schema:reviewBody "What a great film" ;
  schema:reviewRating 5 .

Would I also need to explicitly include the triple linking the movie to the
review:

<GoneGirl> schema:review _:b0 .
# <GoneGirl#id> schema:review _:b0 .

And/or the triple stating the review is a member of the collection:

<GoneGirl/reviews> hydra:member _:b0 .

Or is it reasonable to assume the server will add these?

In the case of using LINK/UNLINK this would only be possible if the
schema:Review already had an identitiy URI, so assume the client would have
already had to POST it to some other generic <allReviews> collection.
And I'm not sure how I would use LINK/UNLINK in the case that the movie used the
hash URI pattern <GoneGirl#id>?

> Thoughts?
>
> Gregg Kellogg
> gregg@greggkellogg.net
>
>

John

[1] https://github.com/jaw111/skos-api