Jim,
Makes sense to leave AnyResource for compatibility. But then, what kind of interoperability can be achieved with this? I see this analogous to writing a lot of code in C using only "void*" (or Object in Java).
I also think this shows that progress without breaking compatibility is not always possible. Now I am even more confident that keeping the version header might actually do more to help OSLC remain viable in the long term rather than fragment the ecosystem
(don't shoot yourself in the foot disclaimer applies). I still support the commitment to keep OSLC 3 100% backwards compatible.
--
/Andrew
17 jan. 2019 kl. 21:13 skrev Jim Amsden <>:
I got my analysis mixed up. The more specific oslc:range assertions came from the resource shapes created for RQM. The QM 2.0 spec,
https://archive.open-services.net/bin/view/Main/QmSpecificationV2.html,uses
any for all the relationship names. So I think we should be consistent with the 2.0 spec and leave the oslc:AnyResource.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
