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

I think `"@container": "@graph"` suggestion from my side came as bit of a distraction. Server could respond with expanded and flattened JSON-LD or client could even negotiate for Trig or N-Quads. I just found it interesting as a possible way to format example snippets in an elegant way.

What I find important to this case here relates to the *shared understanding* between clients and servers. In case of *liking a video* or *having interest in an event* or *having attended an event*, it seems that interaction would rely on shared understanding of particular instance of `rdf:Property`, for liking something like `sor:likes` and for interests something like `cco:interest`. In addition [hydra Collection Design](https://www.w3.org/community/hydra/wiki/Collection_Design) provides `hydra:manages` block which can reference any instance of `rdf:Properety` with `hydra:property`. Having that shared understanding, to create particular relationship (expressed with particular instance of `rdf:Property`) client would have to 'add' to the collection which `hydra:manages` that property for intended resource.
For liking on Vimeo, each person has such collection explained in https://developer.vimeo.com/api/endpoints/likes#GET/users/{user_id}/likes

I see one possible *gotcha* here, to have the `hydra:manages` block work as intended, for collection:
```json
{
  "@context": { ... },
  "@id": "/users/elfpavlik/likes",
  "manages": {
    "subject": "/users/elfpavlik",
    "property": "sor:likes"
  },
  "member": [...]
}
```
We want to IRI denoting the video to appear as member, not the new resource we would PUT, so ` "member": ["/videos/144522067"]` NOT ` "member": ["/users/elfpavlik/likes/144522067"]` (which differs from how `ldp:contains` works in LDP).

If instead of having a resource (named graph) like
```http
GET /users/elfpavlik/likes/144522067
```
```json
{
  "@context": { ... },
  "@graph": [
    {
      "@id": "/users/elfpavlik",
      "sor:likes": "/videos/144522067"
    }
    {
      "@id": "/users/elfpavlik/likes",
      "member": "/videos/144522067"
    }
  ]
}
```
We would like to have a resource representing a [Qualified Relation](http://patterns.dataincubator.org/book/qualified-relation.html) ('foo:Liking' or whatever), it seems that it would not work any more with intended design of `hydra:manages` block. We can't anymore rely on direct (binary) relationships expressed with instances of `rdf:Property`. IMO we shouldn't expect that vocabularies on which *shared understanding* depends will provide qualified version for each relationship.

If for cases like above, we intend `hydra:member` to work more like `ldp:contains`, we might need to adjust `hydra:manages` to always have `subject`, `property`, `object` where either `s` or `o` would have an array. something like:

```json
{
  "@context": { ... },
  "@id": "/users/elfpavlik/likes",
  "manages": {
    "subject": "/users/elfpavlik",
    "property": "sor:likes",
    "object": ["/videos/144522067"]
  },
  "member": ["/users/elfpavlik/likes/144522067"]
}
```
In above, client still don't know which resource it would have to `DELETE` to remove triple with particular `object` (as unlike), so we might needs something like:
```json
 [
  {
    "@id": "https://media.example/users/elfpavlik/likes",
    "@graph": [{
      "@id": "https://media.example/users/elfpavlik/likes",
      "http://www.w3.org/ns/hydra/core#manages": {
        "http://www.w3.org/ns/hydra/core#subject": "https://media.example/users/elfpavlik",
        "http://www.w3.org/ns/hydra/core#property": "http://purl.org/net/soron/likes",
        "http://www.w3.org/ns/hydra/core#object": ["https://media.example/videos/144522067"]
      },
      "http://www.w3.org/ns/hydra/core#member": ["https://media.example/users/elfpavlik/likes/144522067"]
    }]
  },
  {
    "@id": "https://media.example/users/elfpavlik/likes/144522067",
    "@graph": [{
      "@id": "https://media.example/users/elfpavlik",
      "http://purl.org/net/soron/likes": "https://media.example/videos/144522067"
    }]
  }
]
```

`"@container": "@graph"` seemed to me like a potential alternative but possibly leaving to much implicit
```json
{
  "@context": { ... },
  "@id": "/users/elfpavlik/likes",
  "manages": {
    "subject": "/users/elfpavlik",
    "property": "sor:likes"
  },
  "member": {
    "/users/elfpavlik/likes/144522067": "/videos/144522067"
  }
}
```

But at least here client knows clearly which resource it has to `DELETE` to remove which member.

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

Received on Wednesday, 4 October 2017 16:27:10 UTC