- From: Tomasz Pluskiewicz via GitHub <sysbot+gh@w3.org>
- Date: Tue, 16 Feb 2021 20:20:23 +0000
- To: public-hydra-logs@w3.org
After careful consideration, I support @alien-mcl in keeping all of these terms **hydra:Resource** I think it's now well established that `hydra:Resource` denotes explicit promise dereferencability (regardless of the server will actually respond successfully). Thus, it is quite useful in itself. For example, in my APIs, I have been using this also on the server, where any resource which is typed as `hydra:Resource` is indeed directly served using a generic handler. **hydra:Class** While I have not been relying much on this class so far, I would also like to keep it. I plan to build APIs which the server dynamically discovers its capabilities by looking up instances of `hydra:Class` from a store. In this scenario, every such instance is a separate resource and adding or removing `hydra:Class` would serve as a form of feature toggling. **hydra:title/hydra:description** Also here, I think these terms have their place. Analogous to `sh:name` and `sh:description` from SHACL, these are quite useful in providing app-specific labels specifically for the use on the UI, where any `rdfs:label` and the like could be inappropriate. That would be the case especially when an API is dynamically composed of existing vocabularies. -- GitHub Notification of comment by tpluscode Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/90#issuecomment-780093955 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 16 February 2021 20:20:25 UTC