Re: Link profiles

Robert Baillargeon

Indeed I agree that this is a good start to the discussion.  But as Jim identifies here we have some variability in the definition of where the link storage and inverse are stored.  If we go on the path that these are implementation-specific this will erode the value of OSLC and consistent integrations and portability for OSLC collaborations.  It needs to be formalized in the vocabularies of the standard or more desirable grow to a discovery method to allow for flexibility in the implementations that can arbitrate behaviors.  

Basically put as we look at the future of OSLC for consistency and scalability we are going to need to support ...
  1. Vocabulary that includes link types, link storage location (local attribute, local & backlink, discovery) , and link inverse discovery mechanisms (trs index, oslc query, etc.)
  2. Domain vocabulary discovery so endpoints can declare, extend, and discover new domains.
I agree that there is a need near-term to better declare a profile that states the basics of a good collaborating OSLC end-point (rather than just an endpoint that consumes some OSLC interfaces).  But we also need to look to the future to better support PLM and other domain tools (rather than overloading AM) and have consistent patterns of interaction and UX experiences.

We are looking forward to collaborating on these.  Let's focus on the current baseline profiles, but we should be also starting to draft where we want to go so that we can recruit other tooling to the OSLC Enterprise.


Chief Product Officer – Linked Data

418 N. Main Street 2nd Floor/Suite 200, Royal Oak, Michigan 48067, USA
Ph: 716 261 8338



Try out our Jira and Confluence OSLC Tools on the Atlassian Marketplace

From: oslc-op@... <oslc-op@...> on behalf of Jim Amsden via <>
Sent: Thursday, May 26, 2022 1:46 PM
To: Andrii Berezovskyi <andriib@...>; Eran Gery <eran.gery@...>; David Honey2 <david.honey@...>; e.gentry@... <e.gentry@...>
Cc: oslc-op@... <oslc-op@...>
Subject: Re: [oslc-op] Link profiles

This is a good start, but we should understand how it supports the use cases and common practice.


On the issues we’ve been discussing on links: the OSLC specifications define vocabularies and shapes that specify links that would be reasonably considered inverses. Requirement validatedBy TestCase and TestCase validatesRquirement Requirement is one such example. However, OSLC does not specify which one is the property, which would be considered the inverse property, which or  “owed by” any particular server that supports RM and/or QM domains. Rather this is a server implementation decision, often driven by use cases/scenarios that support a particular work-flow – i.e., requirements vs. test driven develop in this case.


Fundamentally OSLC ResourceShape constraints have no way of indicating what a server expects to store vs. expects another server involved in a link relationship expects/can/has to store. So, implementations do what works for them and what is stored where must be documented outside OSLC discovery.


Added to that, OSLC delegated dialogs don’t establish a clear distinction between the requester and provider of the delegated dialog and who’s supposed to “own” the link – that is, which link property the pair of tools considers the actual source and target of the link, and whether the source or target resource will be the subject of the link property triple. tools attempt to make this transparent, so the user doesn’t have to know which server is storing the link, or how the incoming links are stored or calculated. This is purely a usability issue. However, the participating servers do have to know because even through the creation of the link can be created from either direction, the servers must know which one stores it and implement the link creation accordingly. Again, there is no way to discover this.


We could expand ResourceShape to define inverse property constraints to provide a discoverable way for clients and servers to interoperate when creating links from either direction. I expect that might be a better approach than defining a number of profile special cases.




From: Andrii Berezovskyi <andriib@...>
Date: Thursday, May 26, 2022 at 11:49 AM
To: Eran Gery <eran.gery@...>, David Honey2 <david.honey@...>, Jim Amsden <jamsden@...>, "e.gentry@..." <e.gentry@...>
Cc: "oslc-op@..." <oslc-op@...>
Subject: [EXTERNAL] Link profiles


Hi, I put together a simple table for the possible profiles after the call: Please look at them and tell me what you think. Thanks to Eran


This Message Is From an External Sender

This message came from outside your organization.




I put together a simple table for the possible profiles after the call:


Please look at them and tell me what you think. Thanks to Eran for taking extra time to explain some things to me.



Join to automatically receive all group messages.