Discussion PR: remove `vf:notApplicable` and `vf:PairsWith` in owl schema

Hi! After this pr and the included discussion I started working with the vf model more (converting to rust) and realized something I'd like to bring up for discussion. Keep in mind, these modifications took all of 30s to make, so if ultimately the decision is made to reject this PR I will not be hurt at all.

Effectively I think it makes sense to remove vf:notApplicable and vf:PairsWith. When converting the rdf spec into rust, I ran into issues where essentially I was hardcoding logic like "if this contains vf:notApplicable then the type should be able to return NULL (None in rust)" and "if we encounter vf:PairsWith ignore it entirely because in reality it's a subset of vf:Action which is already defined."

Once logic like this starts sneaking, my first instinct is to ask "am I doing something wrong?"

Then I realized a way this could be done without hardcoding. Remove all instances of vf:notApplicable:

vf:transfer-custody a       owl:NamedIndividual ,
                            vf:Action ;
        vf:inputOutput      vf:notApplicable ;
        vf:pairsWith        vf:notApplicable ;
        vf:resourceEffect   vf:decrementIncrement ;
        rdfs:comment        "Give physical custody and control of a resource, without full accounting or ownership rights." ;
        rdfs:label          "transfer-custody" ;
        vs:term_status      "unstable" .

vf:use a                    owl:NamedIndividual ,
                            vf:Action ;
        vf:inputOutput      vf:input ;
        vf:pairsWith        vf:notApplicable ;
        vf:resourceEffect   vf:noEffect ;
        rdfs:comment        "For example a tool used in process; after the process, the tool still exists." ;
        rdfs:label          "use" ;
        vs:term_status      "unstable" .

becomes

vf:transfer-custody a       owl:NamedIndividual ,
                            vf:Action ;
        vf:resourceEffect   vf:decrementIncrement ;
        rdfs:comment        "Give physical custody and control of a resource, without full accounting or ownership rights." ;
        rdfs:label          "transfer-custody" ;
        vs:term_status      "unstable" .

vf:use a                    owl:NamedIndividual ,
                            vf:Action ;
        vf:inputOutput      vf:input ;
        vf:resourceEffect   vf:noEffect ;
        rdfs:comment        "For example a tool used in process; after the process, the tool still exists." ;
        rdfs:label          "use" ;
        vs:term_status      "unstable" .

Given that the ObjectProperties for vf:pairsWith and vf:inputOutput are defined on the enum, the implementor can now say Action::TransferCustody should be able to return a pairs_with() or input_output() value but they are not defined in all cases therefor it makes sense to allow the return types to be nullable (which is effectively what the hardcoded vf:notApplicable logic was doing anyway).

By extension, if vf:notApplicable becomes redundant, vf:PairsWith outlives its usefulness as well (since it only exists to union vf:notApplicable with a subset of vf:Action).

The only part that I don't know is if this is idiomatic owl/rdf/etc or if this would hurt the undertanding of others trying to parse the schema. If you define an ObjectProperty on an enum value, is it "ok" for the enum values to not return a value for that property?

Hopefully this all makes sense, I can expand further if needed, and like I said, want this to be more of a discussion. I thought a PR instead of an issue might be appropriate since I know exactly what change I'm envisioning.

Thanks!