|
Jim,
Thank you, I think the points you raise are valid and acting on any of my suggestions would threaten breaking compat. I also think that w/o constraining anything the shapes do not carry any force. It's almost like teasing someone "oslc:serviceProvider" should
point to something that at least has type oslc:serviceProvider but hey, it can also point to whatever the developers wish.
At this point, I would just suggest to leave OSLC Shapes be and consider adding W3C SHACL support that has much stricter semantics regarding conformance and other matters.
/A
The problem with constraining the links to specific types ends up limiting integration options if the integrated tools have limited extensibility. Its also keeping things in the spirit
of RDF open-world assumptions, and not using resource shapes to over-constrain the vocabularies so they become brittle, fixed data structures.
Any server implementation is free to add additional constraints for its purposes. So not putting them in the standard makes sense. It easier to add constraints than remove them.
Version headers aren't needed as long as the variability is discoverable.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From: Andrii Berezovskyi <andriib@kth.se>
To: "oslc-domains@lists.oasis-open.org" <oslc-domains@lists.oasis-open.org>
Date: 01/17/2019 03:41 PM
Subject: Re: [oslc-domains] oslc:range oslc:AnyResource or more specific resource type?
Sent by: <oslc-domains@lists.oasis-open.org>
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 <jamsden@us.ibm.com>:
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
|