Re: 22.9 oslc-op Weekly Contributors Meeting
Apologies if I’ve got the names wrong here, but isn’t the OSLC spec called Config Mgmt? And the IBM software capability is called Global Configurations?
Not meaning to be a pedant, just important to be clear I think.
I guess I’ve also not been clear on some other points – please see response to Eran below.
So what is your policy for link storage?
Which side stores the link?
With PTC, always the tool that is used to create the link – the client – stores the link, and only that tool. We have considered creating “backlinks” – i.e. a link on both sides, but have concerns on how these would be maintained over time. (For example when a linked object get deleted, or say a package full of linked objects are deleted in one operation. It would require the backlinks to also be deleted in the external tool(s) – which probably wouldn’t scale)
Personally I feel having a “centralized link repository” that all lifecycle tools can connect to, where all links are stored and can be accessed, makes a lot of sense architecturally. But practically speaking it would be challenging to implement, especially if connecting tools are from different vendors.
From: oslc-op@... <oslc-op@...> On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Sent: Monday, September 26, 2022 3:54 PM
To: Ollerton, Patrick <pollerton@...>; oslc-op@...; jamsden@...
Subject: Re: [oslc-op] 22.9 oslc-op Weekly Contributors Meeting
As I said I’m really glad to see other vendors joining the conversation.
How we make links really does depend on whether we are in a global configuration aware environment or not. In a global configuration aware environment we don’t need to make back link, and indeed should make them because the system becomes very brittle and reuse becomes difficult.
Applications should not be forced to create backlinks just because some other applications may not understand or support global configurations. (Recall that global configurations are also an OSLC specification).
I really don’t see any other solution than to have two modes.
From: Ollerton, Patrick <pollerton@...>
I’m a Product Manager for PTC – specifically for Windchill Modeler our MBSE tool. Me and Tanu Jolly (PM for Windchill PLM) are now more engaged in this community and hoping to contribute. PTC have implemented OSLC in several of our tools already – Windchill Modeler, Windchill RV&S (formerly Integrity) and also Windchill PLM. (Demos here: https://www.youtube.com/watch?v=FceIwmq25hw ) We’re planning to add Codebeamer to that list very soon.
I would be cautious using term like “GC aware” as I don’t think a standard should be tied to a particular software vendor’s capabilities or terminology. One of the criticisms I hear of OSLC is that it’s designed to work for IBM tools, not generalized for the majority. I don’t think that is totally accurate, but IBM tools are the main frame of reference, as you state.
PTC have implemented a level of bi-directional capabilities in our tools using queries - we call it reverse lookup. Crucially, we don’t have the situation where there may be a huge number of providers in our tools though, so we are able to easily discover providers to query (or have it pre-defined) and for it to scale by running queries on multiple providers simultaneously. Although this might not work in cases where there numerous providers involved, it can be made to work if OSLC is implemented in a certain way.
On Behalf Of Gentry, Edward via lists.oasis-open-projects.org
Agree: ResourceShape and the list. But this is not nearly enough for a link profile.
For our link profile I would suggest two sections:
As I’ve argued before since the goal of the link profile is interoperability, and since IBM-ELM is still has the largest install base of OSLC providers, some level of the link profile must insure that interoperability with IBM-ELM works out-of-the-box. I have no love or loyalty more for IBM-ELM; I’m thinking pragmatically about the customer value of a link profile specification with which does not insure interoperability with IBM-ELM.
On a related note: last week, I had an interesting conversation with a product manager from PTC/Codebeamer. He indicated intention to increase their support for OSLC. Perhaps as more tools join the party force IBM-ELM to fix the many places where it is not even OCLS 2.0 compliant (or has defects), and perhaps move in the 3.0+ world.
On Behalf Of Jim Amsden via lists.oasis-open-projects.org
You could just use a normative table of outgoing and incoming link types (i.e., property and inverse properties). However, it would be nice if this was machine readable, and an extension to ResourceShapes would do that.
We could also decide to declare property and inverse properties in the OSLC vocabularies. That wouldn’t require any extensions. Since OSLC does not rely on RDF inferencing, this shouldn’t create any problems.
From: <oslc-op@...> on behalf of Eran Gery <eran.gery@...>
Ed, Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM. Can you comment on that. One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.
Jim did not accept the text as he is not sure that the “store on outgoing side” is respected by ELM.
Can you comment on that.
One comment I have is that it is enough that it is the 90% case as a principle. We can document exceptions.
There are clearly exceptions in opt-out mode that there are still backlinks with CCM. We can document that as an exception.
Jim suggested that we may have to use OSLC shapes to determine the owner, IMO it is a no go for the reason that the maturity level of the bi-diretional profile is far from mandating OSLC shapes. Actually, none of the linking profile require support for shapes.
So the only options I see
Please speak up…
On Behalf Of "Eran Gery"
Ed Please review the link ownership text Link ownership In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless
Please review the link ownership text
In bi-derctional linking scenarios both OSLC participants are aware of links across their owned resources and enable link visibility and navigation at each side. Nevertheless, storing a link at both sides is considered an ill-practice as it is essentially replication of data. This may result in inconsistencies as links are updated or deleted, since maintaining consistency requires synchronization across the providers on any update. Therefore, the recommended practice is to store links on one of the participants, and use link discovery by the other participant. Therefore, there needs to be an agreed convention on which side should store the link. OSLC links have an incoming and outgoing sides, determined by the role of the link. Usually one side will have an active predicate name, for example "implements" and the other side will have a passive predicate name, in this example it would be "implemented by". The active side is also considered the outgoing side, and the passive the incoming side. The convention is that the link is stored with the resource on the outgoing side, i.e. the resource with the active predicate. The incoming side would discover the links with one of the discovery methods discussed in the following sections. Note the creation of the link may be initiated by both providers. In case that the link is initiated by the incoming side provider, it needs to store it with the resource on the outgoing side provider. This is discussed in the put on resources section.
From: Gentry, Edward <e.gentry@...>
Hi All, I’m traveling today and so will miss our meeting this afternoon. @David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes.
I’m traveling today and so will miss our meeting this afternoon.
@David Honey2, could you please arrange a meeting with John Vasta for me regarding the authentication in the link Profile? We should be able to keep it to 30 minutes. Find something that works for him in the morning and I’ll make it work.