Allow to set vocabulary when hydrating class and property

[jimsafley]

See #2428

This change makes it possible to assign a vocabulary to a resource class or property via the API.

[zerocrates]

Hmm... enabling this would make it easy to, say, update a member by moving it from one vocab to another. I'm not sure whether we want to improve the api stuff for vocabs and members individually, or instead push the RDF importer via the API and have that be the intended entry point like it is for the UI.

I haven't looked closely at this in a while but if I remember correctly these will work through the API, just only if edited/created via their parent vocab.

[jimsafley]

I haven't looked closely at this in a while but if I remember correctly these will work through the API, just only if edited/created via their parent vocab.

Running the following will delete all existing properties, replacing them with the "Foo" property.

PATCH /api/vocabularies/1

{
    "o:property": [
        {
            "o:local_name": "foo"
            "o:label": "Foo",
        }
    ]
}

For a PATCH that's not expected and certainly destructive. The only way to safely create a property via the vocabulary endpoint is to include ID'd references to all existing properties as well. Note that when GETing a vocabulary, the response does not include its members.

[zerocrates]

Well it's how patch works everywhere we have it. Patch an item with one file and you'll delete the others, etc. Though yes, that the output doesn't include these may make it a more likely mistake.

The design of what we have is based on the assumption that you'll create the vocab all at once with its members. In that case it's not really an issue, but editing/adding after the fact, it doesn't offer much for that.

If creation of new members is the main concern we could hydrate the vocab only on create, that's an option.