- From: Tomasz Pluskiewicz via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Jul 2021 20:15:46 +0000
- To: public-hydra-logs@w3.org
Fair enough, let's do core if others will agree. > Not really. I can imagine there is a supported operation for resources of class Collection, but resources of class ReadOnlyCollection would have that operation disabled on the API documentation level (I know that example is a long shot ;)) This is exactly the reason I opted for an extension. Either we make it as simple as possible, or not core. Maybe more verbose, but retracting surgically on individual resources is easy to reason about. This is not OOP, where I gather a term like `ReadOnlyCollection` would originate. And this is the only ***sane*** way I ca propose to retract operations supported by properties. This concept is difficult enough on its own... > Marking operations with logical behavior like `schema:RemoveAction` is outside of the spec and seems not be unique enough How is it outside of the spec? Not unique? Yes, you would introduce custom operation/action types for more precise semantics. For example ```turtle :Article a hydra:Class ; hydra:supportedOperation [ a schema:UpdateAction , api:SendArticleToReviewerQueue ] . # This is by no means ambiguous ;) </article/a> hydra:operation [ a hydra:UnsupportedOperation , api:SendArticleToReviewerQueue ] . ``` -- GitHub Notification of comment by tpluscode Please view or discuss this issue at https://github.com/HydraCG/Specifications/issues/241#issuecomment-878565073 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 July 2021 20:15:50 UTC