In CM 2.0 there are a number of property names that include both the meaning of the property (implements) and the expected type of the target/object (Requirement), you we have things like oslc_cm:implementsRequirement [1]. This has provided some usefulness in being able to know from a client perspective what to expect. This has also limited what a client thinks it can put or expect as the target of that link. What had motivated the previous design may not be best practice anymore. So I'd like to use this email to make people aware of this topic and gather some feedback. Also I'd like to discuss strategies to introduce new predicates, such as oslc_cm:implements and how to potentially phase out or deprecate things like oslc_cm:implementsRequirement Another example of simplification would be to replace all oslc_cm:related* with dcterms:relation. We can produce some guidance and explain how tools can efficiently know what type of resource is the target of the link without having to encode into the property name.
This is not a 2.0 issue, suggesting this as a topic for how we evolve the vocabulary in 3.0. I've heard this issue from a number of adopters who needed to invent new properties that were "like" currently defined ones, it would be good if they weighed in as well. [1] - http://open-services.net/bin/view/Main/CmSpecificationV2#Resource_ChangeRequest Thanks, Steve Speicher IBM Rational Software OSLC - Lifecycle integration inspired by the web -> http://open-services.net
