Re: [Specifications] Adding already existing resources as collection members

The more I read this the more complicated it seems. First - graphs - what for do we need those? It's kind'a RDFish and I believe it's main purpose was to organize data. In those examples I've got feeling that the graph acts a bigger role. BTW, are we going to force in the spec requirement of using the graphs?

HTTP LINK/UNLINK seems more natural as these are supposed to create relations between resources. With those you could LINK /users/elfpavlik with /videos/144522067 by a sor:likes relation, i.e:
```
LINK /users/elfpavlik
Link: </videos/144522067>; rel="http://purl.org/net/soron/likes"
```

This way client doesn't need to know anything about URL's and how to compose those as required in PUT. It still has all the PUT's benefits like idempodency. The resulting collection resource available would be actually a _view_ over sor:likes relations:
```
GET /users/elfpavlik/likes
{
  "@context": { ... },
  "@id": "/users/elfpavlik/likes",
  "manages": {
    "subject": "/users/elfpavlik",
    "property": "sor:likes"
  },
  "member": {
    "/videos/144522067"
  }
}
```

UNLINK would act as a retraction of the relations created effectively removing items from collection without actually removing the resources.
Drawback of that approach is that client would need to create the resources in the API first, then it would link them to any other resource required.

-- 
GitHub Notification of comment by alien-mcl
Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/134#issuecomment-334290002 using your GitHub account

Received on Wednesday, 4 October 2017 21:08:35 UTC