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

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

Ah, I think I recall. This is for when one resource doesn't have an actual relation in dataset but only in hypermedia. So in RDF you don't have a `api:entrypoint vocab:friends api:collection` triple but want to be able to include a link between the two in Hydra representation. Correct?
</blockquote></details>

Not sure if I understood. In case `/some-person` of `socrel:friendOf` or 'cco:interest` relations exist in the dataset, not between the `/some-person` and`hydra:collection` but between `/some-person` and each member. In case of `rdf:type` no relation meaningful for the dataset seems to exist between each `schema:Event` and the `hydra:EntryPoint` (except something like `void:inDataset`). If client would use SPARQL or Triple Pattern Fragments interface, the `hydra:collection` seems not needed and IMO often may come just as artifact of trying to provide some tree-ish layout for REST inteface to access the graph-y dataset. I think to really clarify that, we have to keep working with more and more use cases and for each one take a look how accessing the same dataset would differ if using SPARQL interface or HyDRA interface - which data we add just for the sake of creating HyDRA interface layout.
For the sake of this PR I think that Markus gave really good answer in another thread, the one with examples like *all entries in Y have a a specific property set to a specific value:*. Main improvement in this PR comes with switching to generalized approach relying on already existing terms in common vocabs and nod needing to improvise terms like `mysnowflakevocab:events` which go against benefits of *shared understanding* provided by commonly used vocabs and enabling interoperability.

---


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


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

Received on Wednesday, 16 August 2017 12:37:37 UTC