In general, the minting of hash-URIs/IRIs with CoIN may be a bit
underspecified. While I have defined a fragmentTemplate property for
that, I actually think that most of what I've used it for is possible
to do without it.
So, to describe the construction of a URI value of:
   "https://www.w3.org/ns/prov#hadDerivationByRemoval"
using CoIN, you just need a space like:
   @prefix coin: <https://purl.org/court/def/2009/coin#> .
   <https://www.w3.org/ns/prov/uri-space#> a coin:URISpace;
       coin:base "https://www.w3.org/ns/prov";
       coin:template [
               coin:uriTemplate "#{name}";
               coin:binding [ coin:variable "name"; coin:property coin:slug ]
           ] .
This, combined with data like:
   [] a rdf:Property; coin:slug "hadDerivationByRemoval" .
would produce the expected URI.
But I wonder if this really warrants use of CoIN? It may be easier to
skip the extra step of picking the fragment name from a property
(coin:slug, or any other property suitable for the fragment name), and
just mint the IRI mechanically?
Granted, this is a case where it might be desirable to declare some
more intricate transform rules. E.g. to enable one to pick the value
of an rdfs:label (possibly also matching on language), and transform
that using a newly defined coin:ToLowerLeadingCamelCase transform
rule. Is that what you'd prefer?
Do you use CoIN to mint URIs for things identified with bnodes, or to
verify URIs against existing descriptions? I primarily use it for the
latter, and for structured documentation of the construction
principles. Of course, I aim for CoIN to be usable also for minting
URIs during the initial creation of a resource description. I just
haven't yet worked a lot with that.