- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Tue, 27 Jan 2015 00:48:49 +0100
- To: <public-hydra@w3.org>
On 23 Jan 2015 at 10:16, Dietrich Schulten wrote:
> some questions about the new collection design.
>
> {
> "@id": "/alice",
> "collection": {
> "@id": "/alice/friends",
> "@type": "Collection",
> "manages": {
> "property": "schema:knows",
> "subject": "/alice"
> }
> }
> }
>
>
> 1. [...]
We already discussed 1 yesterday
> 2. As I read the example, the actual list of friends is a separate
> resource,
Correct
> so what we express here is a link to a json collection - as
> long as there is no :member property on the collection.
No, it always is a Collection. You explicitly declared it as one ("@type": "Collection")
> We could also embed the members (Alice's friends).
Right
> But this poses the more general
> question: how does the client decide whether it should dereference to
> get the actual friends
If it is interested in finding the friends it would do that. A Hydra client not only looks for schema:knows on /alice but also tries to find a hydra:collection on /alice which manages /alice schema:knows
> (or for object properties, the actual object).
We have a separate discussion about that I guess (ISSUE-91)
> Checking for the :member property or any sub-properties that are
> expected for an object to see if another GET is needed seems weird.
Why?
--
Markus Lanthaler
@markuslanthaler
Received on Monday, 26 January 2015 23:49:19 UTC