- From: elf Pavlik via GitHub <sysbot+gh@w3.org>
- Date: Sat, 01 Jul 2017 20:06:22 +0000
- To: public-hydra-logs@w3.org
Besides suggested `void:classPartition` I previously posted on mailing list to evaluate [`solid:TypeRegistration`](https://github.com/solid/solid/blob/master/proposals/data-discovery.md#type-index-registrations) @RubenVerborgh in case you had chance to take a closer look at Solid maybe you have some insights on those two optins. In general I think we should consider different audiences and different requirements. 1. Developers who will always use a client and rely on interface provided by it - for them it shouldn't matter what we decide to use 2. Developers who will work with data as JSON(-LD), possibly always relying on compacting it with hydra JSON-LD context (which may hide possible fact of using terms from different namespaces) 3. Developers will work with data as RDF triples/quads and don't care about any particular framing of JSON but care how things work in terms of RDF(S)/OWL I propose to focus on the first case and take advantage of ongoing effort to implement a reference client [Heracles](https://github.com/HydraCG/Heracles.ts). This way we can consider separately an interface provided by the client and the complexity of implementing various approaches in the client itself. Later we can look at different requirements of developers who don't want to rely on hydra clients and work on a lower level with data, both formated & framed JSON and raw RDF triples/quads. -- GitHub Notification of comment by elf-pavlik Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/126#issuecomment-312453003 using your GitHub account
Received on Saturday, 1 July 2017 20:06:28 UTC