- From: elf Pavlik via GitHub <sysbot+gh@w3.org>
- Date: Wed, 16 Aug 2017 12:37:32 +0000
- To: public-hydra-logs@w3.org
*[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