Re: [Specifications] use manages block to advertise type of collection members

Review status: all files reviewed at latest revision, 3 unresolved discussions.

---

*[drafts/use-cases/1.1.security-considerations.md, line 18 at r2](https://reviewable.io:443/reviews/hydracg/specifications/132#-KrUSFWcxbytETQ1yIEc:-KraHnt_nrVC66Hc7fyf:b-gpmnig) ([raw file](https://github.com/hydracg/specifications/blob/8c2db652e54f3e4ed52b855e05c73330d9d2d2ea/drafts/use-cases/1.1.security-considerations.md#L18)):*
<details><summary><i>Previously, elf-pavlik (elf Pavlik) wrote…</i></summary><blockquote>

> only clients written for a specific API will understand the contents of the given collection anyway.

I think we need to disambiguate between *vocabs* (schemas), *APIs* and *datasets*. Preferably around use cases included in our repo. In case where particular client wants to interact with **multiple** servers, each of those servers exposing a dataset via API but all those datasets use a common vocab (eg. schema.org). Preferably client only needs to implement Hydra spec and understand schema.org vocab to interact with all those servers exposing all those datasets.

If any of those servers defines some custom `hydra:Link` it can't expect such generic client to understand it. In our case relating collection of events from entry point with something as simple as `rdfs:seeAlso` and using `hydra:manages` block to hint type of all the members seems sufficient for client looking for 'collection of events in this dataset'

> Also, this PR assumes that the content of a collection is inline. If you only got the target URL, the hydra:collection conveys completely no information.

I think while discussing collection design we have considered using `rdfs:seeAlso` but then decided to add `hydra:collection` to the vocab. I would see this property (the information it conveys) as something close to `rdfs:seeAlso` and 'void:subset'.

> won't this lead to { ... } how useful is it now?

For example [Solid mandates](https://github.com/solid/solid-spec/blob/master/solid-webid-profiles.md#extended-profile) clients MUST load and parse all resources linked from personal WebID profile to get combined 'extended profile'. Clients which don't find enough information about collection inlined in entry point, can simply fetch it. We should still encourage publishers to inline information relevant for discovery in entry point.
BTW for the *friends*, *enemies*, *interests* manages block still seems more practical than trying to make up some `hydra:Link`instances
* http://purl.org/vocab/relationship/friendOf
* http://purl.org/vocab/relationship/enemyOf
* http://smiy.sourceforge.net/cco/spec/cognitivecharacteristics.html#interest

</blockquote></details>

The element type of `friends` and `enemies` will both be a Person in the manages block? Again, the client cannot distinguish between two collection having clearly different meaning...

---


*Comments from [Reviewable](https://reviewable.io:443/reviews/hydracg/specifications/132)*
<!-- Sent from Reviewable.io -->


-- 
GitHub Notification of comment by tpluscode
Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/132#issuecomment-322483761 using your GitHub account

Received on Tuesday, 15 August 2017 14:29:17 UTC