`sh:closed` is rejecting valid txns (when using `insert` on `server`)

[aaj3f]

Description

An example of using sh:closed (which previously worked to demonstrate Fluree allowing/disallowing txns that did or didn't conform to a closed shape) is now rejecting valid txns against that closed shape.

The following default conn context is being used:

{
  "ex": "http://example.org/",
  "f": "https://ns.flur.ee/ledger#",
  "foaf": "http://xmlns.com/foaf/0.1/",
  "owl": "http://www.w3.org/2002/07/owl#",
  "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
  "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
  "schema": "http://schema.org/",
  "sh": "http://www.w3.org/ns/shacl#",
  "skos": "http://www.w3.org/2008/05/skos#",
  "wiki": "https://www.wikidata.org/wiki/",
  "xsd": "http://www.w3.org/2001/XMLSchema#"
}

This is the create txn:

{
    "@context": "https://ns.flur.ee",
    "ledger": "cookbook/closed-shape",
    "insert": {
        "@id": "ex:UserShape",
        "@type": ["sh:NodeShape"],
        "sh:targetClass": {"@id": "ex:User"},
        "sh:property": [
            {
                "sh:path": {"@id": "schema:name"},
                "sh:datatype": {"@id": "xsd:string"}
            }
        ],
        "sh:ignoredProperties": [{"@id": "@type"}],
        "sh:closed": true
    }
}

This is the valid txn that is being rejected for using schema:name on ex:User, despite schema:name being whitelisted

{
    "@context": "https://ns.flur.ee",
    "ledger": "cookbook/closed-shape",
    "insert": {
        "@id": "ex:dolly",
        "@type": ["ex:User"],
        "schema:name": "Dolly Parton"
    }
}

Here are some useful logs and the error message returned:

:first #Flake [211106232532994 0 "http://schema.org/name" 1 -1 true nil]
...
"SHACL shape is closed, extra properties not allowed: [211106232532994]"

Considerations

@zonotope has mentioned some recent changes to predicate id handling. It would be understandable if the use of "sh:path": {"@id": "schema:name"} and the use of "insert": { ..., "schema:name": "Dolly Parton" } were somehow not resolving to the same property described in the rule and described in the transaction