I like fewer terms (one desired state)... the resource shape (aka resource definition table text) is where the "is likely to be an X" should live. That's domain-specific, so it does not pollute the vocabulary term's definition. Domain CM reusing a Domain!=CM term might cause some "ick, it's a cross-domain dependency" knee-jerk reactions, but if we're comfortable re-using DC then Automation is no different in principle, i.e. while we might hate cross-domain SPEC dependencies, we should be completely comfortable with cross-domain VOCABULARY re-use. I tend to split the difference on the descriptions; I've seen in many contexts that when we try to be completely generic, the result is incomprehensible to anyone not in That Meeting(s), so I add an a specific concrete example (clearly marked as such) alongside it. I.e. <oslc_auto:desiredState > a rdfs:Property ; rdfs:comment "The intended (domain- or provider-dependant) value of a resource's (domain-dependant) 'state' property after some (future, present or past) process, transition or change. It is expected that this will be a resource reference to a definition of a valid state on the service provider. For example, in the OSLC Automation domain this is used to indicate the desired state of the Automation Request based on values defined in the OSLC Automation specification and, optionally, by the service provider." ; rdfs:seeAlso oslc:StateTransitionAction ; .
Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
