oslc-domains message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-domains] oslc:range oslc:AnyResource or more specific resource type?
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: "oslc-domains@lists.oasis-open.org" <oslc-domains@lists.oasis-open.org>
- Date: Fri, 18 Jan 2019 10:41:19 -0500
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]