Re: [Specifications] Retracting operations (#246)

> Do I interpret you correctly in that this is thus not something we can (or at least should) solve in Hydra Core?

It's somewhere in-between. If you take away the `sh:` bit, what remains is a `hydra:Class` with an operation. If the server would use the SHACL rule (ie. "draft article is editable") to assert the type dynamically, then it's just an implementation detail. If the client would need to process such rules (SHACL, OWL, or otherwise), then it goes beyond Core.

Now that I wrote the above paragraph, I see that it all comes back to the same idea of asserting `<> a </api/EditableArticle>`. It boils down to how the rules are expressed and when they are processed. N3 rules would also work for that, such as

```turtle
{ ?x schema:status </api/Draft> } => { ?x a </api/EditableResource> } .
```

> But as it stands right now, the additive approach does not allow us to say "operation X is not available at this moment", which is what this pull request is trying to fix.

Yes, and I do see the usefulness of that.

---

Okay @alien-mcl, after some consideration, I agree that we should add a way to announce unavailable operations but I'm not agreeing with the proposed method. Maybe that could be "detached" from the resource itself in its representation. I don't remember now, but at some point we did discuss that the representation could be composed of multiple graphs. To illustrate

```turtle
graph </api> {
  </api/Article> 
    hydra:supportedOperation [
      hydra:method "POST" ; a schema:UpdateAction ;
    ] ;
    hydra:supportedOperation </api/DeleteOperation> .

  </api/DeleteOperation> hydra:method "DELETE" .
}

graph </article/foo> {
  # both operations available
  </article/foo> a </api/Article> .
}

graph </article/bar> {
  </article/bar> a </api/Article> .

  # retracts update operation type
  [ 
    a hydra:ForbiddenOperation ;
    hydra:retractedOperation schema:UpdateAction ; 
    schema:target </article/bar> ;
    hydra:description "You do not have permission to update" ;
  ] .
}

graph </article/baz> {
  </article/baz> a </api/Article> .

  # retracts delete operation by operation URI
  [ 
    # (implicitly)
    a hydra:UnavailableOperation ;
    hydra:retractedOperation </api/DeleteOperation> ;
    schema:target </article/baz> ;
    hydra:description "Published articles cannot be deleted" ;
  ] .
}
```

I just came up with this, so please be gentle :).

1. The `rdf:type` of these blank resources would match the proposed `hydra:Availability` only that there would never be the positive `hydra:Available` - only negations
1. I did not want to reuse `hydra:operation` because of its domain/range and definition
2. `schema:target` could be replaced with `hydra:target` but again, saves one additional term

-- 
GitHub Notification of comment by tpluscode
Please view or discuss this issue at https://github.com/HydraCG/Specifications/pull/246#issuecomment-1373569670 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 6 January 2023 12:34:42 UTC