On 23 Feb 2023, at 16:22, Andrii Berezovskyi <andriib@...> wrote:

Hi,

Adding some comments from my side inline:

With the introduction of resource versions in OSLC Configuration Management, bi directional navigation can no longer be based on “backlinking”. 

This is not true. You cannot have proper backlinks to resources in a given configuration context only because you refuse to have different links for different versions of the same resource (which is a practice I personally disagree with because it would interfere with reasoning but OSLC endorses for the sake of simplicity in technical terms). If a link is unique per resource per configuration context, backlinking would work perfectly. I would be strongly in favor of adding “persistent” URLs for configuration-managed resources at a given context.

It is TBD whether the specification accounts for multiple link discovery service providers or provides guidance on how to deal with multiple providers.

I think it is essential to ensure that there is either discovery of an LDS provider or an ability to configure a link to one. And then implementers can work out the multi-LDS deployment once the basic flexibility is there.

considering true north incl. suspicious linking

I am not sure if it’s helpful to bring suspect link classification into the picture, as it would make the main part of the spec harder to standardize.

either via replication of selections or via get(config resource, config context)

My understanding was that this is exactly how “Therefore, the incoming link inquiries shall specify configuration contexts for the links” was supposed to be implemented.

–Andrew.

On 23 Feb 2023, at 11:15, Ulrich Martin (BD/PLM5) <Martin.Ulrich@...> wrote:

Hi Eran,

 

thanks for your proposal.

 

Please find my comments attached

 

Mit freundlichen Grüßen / Best regards

Martin Ulrich 

IoT Engineering Digital Realities, Collaboration and Engineering Simulation (BD/PLM5)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY | www.bosch.com
Tel. +49 711 811-30414 | Mobil +49 152 28822142 | Telefax +49 711 811-5181990 | Martin.Ulrich@...

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer; Geschäftsführung: Dr. Stefan Hartung, 
Dr. Christian Fischer, Filiz Albrecht, Dr. Markus Forschner, Dr. Markus Heyn, Dr. Tanja Rückert 
​

Von: Eran Gery <eran.gery@...> 
Gesendet: Dienstag, 21. Februar 2023 13:21
An: Jad El-Khoury <jad@...>; Andrii Berezovskyi <andriib@...>
Cc: Jim Amsden <jamsden@...>; rbaillargeon@...; Herzog Erik <Erik.Herzog@...>; Ulrich Martin (BD/PLM5) <Martin.Ulrich@...>; Jim Gammon <james_e_gammon@...>; e.gentry@...; Axel Reichwein <axel.reichwein@...>
Betreff: RE: OSLC impact call monthly - first draft of link discovery spec intent

 

Something to discuss today

 

Not sure if I missed someone

 

Eran Gery – Global Industry Solutions Lead, IBM ELM

CC the mailing list.

On 23 Feb 2023, at 18:48, David Honey2 <david.honey@...> wrote:



The issue with backlinks in a configuration aware world is perhaps best illustrated by an example:

Currently, ELM only stores the forward link. If I have a test case that validates a requirement you might have:
TestCaseA-1 ---validatesRequirement---> RequirementA-1

In this example, the links are always to concept resources.

 

Now consider what might happen if you also stored the backlink:
TestCaseA-1 ---validatesRequirement---> RequirementA-1
            <--validatedByRequirement--

Now consider the case where there is a new version of the test case in which that link is removed.

TestCaseA-1 ---validatesRequirement---> RequirementA-1
            <--validatedByRequirement—

TestCaseA-2                             

The question is what to do about the backlink. If you do nothing, then requirement version 1’s backlink to the test case is inconsistent with the test case version 2’s forward link.

 

You can only remove it by creating a new version of requirement.

TestCaseA-1 ---validatesRequirement---> RequirementA-1
            <--validatedByRequirement—

TestCaseA-2                             RequirementA-2                  

 

Even having done that, if you have a configuration context that resolves to test case version 1 and requirement version 2, you have an inconsistent view of the forward links vs the backlinks. It also results in creating more versions of artifacts.

 

These were the drivers to ELM only storing forward links in configuration aware environments.

 

Best regards,
David

 

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Andrii Berezovskyi
Sent: 23 February 2023 15:23
To: Ulrich Martin (BD/PLM5) <Martin.Ulrich@...>
Cc: Eran Gery <eran.gery@...>; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>; rbaillargeon@...; Herzog Erik <Erik.Herzog@...>; Jim Gammon <james_e_gammon@...>; e.gentry@...; Axel Reichwein <axel.reichwein@...>; oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] OSLC impact call monthly - first draft of link discovery spec intent

 

CC the mailing list. –Andrew. On 23 Feb 2023, at 16: 22, Andrii Berezovskyi <andriib@ kth. se> wrote: Hi, Adding some comments from my side inline: With the introduction of resource versions in OSLC Configuration Management, bi directional

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

CC the mailing list.

 

–Andrew.

On 23 Feb 2023, at 16:22, Andrii Berezovskyi <andriib@...> wrote:

 

Hi,

 

Adding some comments from my side inline:

 

With the introduction of resource versions in OSLC Configuration Management, bi directional navigation can no longer be based on “backlinking”. 

 

This is not true. You cannot have proper backlinks to resources in a given configuration context only because you refuse to have different links for different versions of the same resource (which is a practice I personally disagree with because it would interfere with reasoning but OSLC endorses for the sake of simplicity in technical terms). If a link is unique per resource per configuration context, backlinking would work perfectly. I would be strongly in favor of adding “persistent” URLs for configuration-managed resources at a given context.

 

It is TBD whether the specification accounts for multiple link discovery service providers or provides guidance on how to deal with multiple providers.

 

I think it is essential to ensure that there is either discovery of an LDS provider or an ability to configure a link to one. And then implementers can work out the multi-LDS deployment once the basic flexibility is there.

 

considering true north incl. suspicious linking

 

I am not sure if it’s helpful to bring suspect link classification into the picture, as it would make the main part of the spec harder to standardize.

 

either via replication of selections or via get(config resource, config context)

 

My understanding was that this is exactly how “Therefore, the incoming link inquiries shall specify configuration contexts for the links” was supposed to be implemented.

 

–Andrew.

On 23 Feb 2023, at 11:15, Ulrich Martin (BD/PLM5) <Martin.Ulrich@...> wrote:

 

Hi Eran,

 

thanks for your proposal.

 

Please find my comments attached

 

Mit freundlichen Grüßen / Best regards

Martin Ulrich 

IoT Engineering Digital Realities, Collaboration and Engineering Simulation (BD/PLM5)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY | www.bosch.com
Tel. +49 711 811-30414 | Mobil +49 152 28822142 | Telefax +49 711 811-5181990 | Martin.Ulrich@...

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer; Geschäftsführung: Dr. Stefan Hartung, 
Dr. Christian Fischer, Filiz Albrecht, Dr. Markus Forschner, Dr. Markus Heyn, Dr. Tanja Rückert 
​

Von: Eran Gery <eran.gery@...> 
Gesendet: Dienstag, 21. Februar 2023 13:21
An: Jad El-Khoury <jad@...>; Andrii Berezovskyi <andriib@...>
Cc: Jim Amsden <jamsden@...>; rbaillargeon@...; Herzog Erik <Erik.Herzog@...>; Ulrich Martin (BD/PLM5) <Martin.Ulrich@...>; Jim Gammon <james_e_gammon@...>; e.gentry@...; Axel Reichwein <axel.reichwein@...>
Betreff: RE: OSLC impact call monthly - first draft of link discovery spec intent

 

Something to discuss today

 

Not sure if I missed someone

 

Eran Gery – Global Industry Solutions Lead, IBM ELM

 

All, 

On 23 Feb 2023, at 17:48, David Honey2 <david.honey@...> wrote:

The issue with backlinks in a configuration aware world is perhaps best illustrated by an example:

Currently, ELM only stores the forward link. If I have a test case that validates a requirement you might have:
TestCaseA-1 ---validatesRequirement---> RequirementA-1

In this example, the links are always to concept resources.

 

Now consider what might happen if you also stored the backlink:
TestCaseA-1 ---validatesRequirement---> RequirementA-1
            <--validatedByRequirement--

Now consider the case where there is a new version of the test case in which that link is removed.

TestCaseA-1 ---validatesRequirement---> RequirementA-1
            <--validatedByRequirement—

TestCaseA-2                             

The question is what to do about the backlink. If you do nothing, then requirement version 1’s backlink to the test case is inconsistent with the test case version 2’s forward link.

 

You can only remove it by creating a new version of requirement.

TestCaseA-1 ---validatesRequirement---> RequirementA-1
            <--validatedByRequirement—

TestCaseA-2                             RequirementA-2                  

 

Even having done that, if you have a configuration context that resolves to test case version 1 and requirement version 2, you have an inconsistent view of the forward links vs the backlinks. It also results in creating more versions of artifacts.

 

These were the drivers to ELM only storing forward links in configuration aware environments.

 

Best regards,
David

 

 

 

From: oslc-op@... <oslc-op@...> On Behalf Of Andrii Berezovskyi
Sent: 23 February 2023 15:23
To: Ulrich Martin (BD/PLM5) <Martin.Ulrich@...>
Cc: Eran Gery <eran.gery@...>; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>; rbaillargeon@...; Herzog Erik <Erik.Herzog@...>; Jim Gammon <james_e_gammon@...>; e.gentry@...; Axel Reichwein <axel.reichwein@...>; oslc-op@...
Subject: [EXTERNAL] Re: [oslc-op] OSLC impact call monthly - first draft of link discovery spec intent

 

CC the mailing list. –Andrew. On 23 Feb 2023, at 16: 22, Andrii Berezovskyi <andriib@ kth. se> wrote: Hi, Adding some comments from my side inline: With the introduction of resource versions in OSLC Configuration Management, bi directional 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

CC the mailing list. 

 

–Andrew.

On 23 Feb 2023, at 16:22, Andrii Berezovskyi <andriib@...> wrote:

 

Hi,

 

Adding some comments from my side inline:

 

With the introduction of resource versions in OSLC Configuration Management, bi directional navigation can no longer be based on “backlinking”. 

 

This is not true. You cannot have proper backlinks to resources in a given configuration context only because you refuse to have different links for different versions of the same resource (which is a practice I personally disagree with because it would interfere with reasoning but OSLC endorses for the sake of simplicity in technical terms). If a link is unique per resource per configuration context, backlinking would work perfectly. I would be strongly in favor of adding “persistent” URLs for configuration-managed resources at a given context.

 

It is TBD whether the specification accounts for multiple link discovery service providers or provides guidance on how to deal with multiple providers.

 

I think it is essential to ensure that there is either discovery of an LDS provider or an ability to configure a link to one. And then implementers can work out the multi-LDS deployment once the basic flexibility is there.

 

considering true north incl. suspicious linking

 

I am not sure if it’s helpful to bring suspect link classification into the picture, as it would make the main part of the spec harder to standardize.

 

either via replication of selections or via get(config resource, config context)

 

My understanding was that this is exactly how “Therefore, the incoming link inquiries shall specify configuration contexts for the links” was supposed to be implemented.

 

–Andrew.

On 23 Feb 2023, at 11:15, Ulrich Martin (BD/PLM5) <Martin.Ulrich@...> wrote:

 

Hi Eran,

 

thanks for your proposal.

 

Please find my comments attached

 

Mit freundlichen Grüßen / Best regards

Martin Ulrich 

IoT Engineering Digital Realities, Collaboration and Engineering Simulation (BD/PLM5)
Robert Bosch GmbH | Postfach 30 02 20 | 70442 Stuttgart | GERMANY | www.bosch.com
Tel. +49 711 811-30414 | Mobil +49 152 28822142 | Telefax +49 711 811-5181990 | Martin.Ulrich@...

Sitz: Stuttgart, Registergericht: Amtsgericht Stuttgart, HRB 14000;
Aufsichtsratsvorsitzender: Prof. Dr. Stefan Asenkerschbaumer; Geschäftsführung: Dr. Stefan Hartung, 
Dr. Christian Fischer, Filiz Albrecht, Dr. Markus Forschner, Dr. Markus Heyn, Dr. Tanja Rückert 
​

Von: Eran Gery <eran.gery@...> 
Gesendet: Dienstag, 21. Februar 2023 13:21
An: Jad El-Khoury <jad@...>; Andrii Berezovskyi <andriib@...>
Cc: Jim Amsden <jamsden@...>; rbaillargeon@...; Herzog Erik <Erik.Herzog@...>; Ulrich Martin (BD/PLM5) <Martin.Ulrich@...>; Jim Gammon <james_e_gammon@...>; e.gentry@...; Axel Reichwein <axel.reichwein@...>
Betreff: RE: OSLC impact call monthly - first draft of link discovery spec intent

 

Something to discuss today

 

Not sure if I missed someone

 

Eran Gery – Global Industry Solutions Lead, IBM ELM

 

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU

All, 

On 23 Feb 2023, at 18:23, David Honey2 <david.honey@...> wrote:

Eran,

 

I was responding to Andrew’s email where he stated the following was not true:

With the introduction of resource versions in OSLC Configuration Management, bi directional navigation can no longer be based on “backlinking”. 

 

I agree the specification does not need to describe any of this.

 

David.

 

From: Eran Gery <eran.gery@...> 
Sent: 23 February 2023 17:10
To: David Honey2 <david.honey@...>
Cc: oslc-op@...; andriib@...; Ulrich Martin (BD/PLM5) <Martin.Ulrich@...>; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>; rbaillargeon@...; Herzog Erik <Erik.Herzog@...>; Jim Gammon <james_e_gammon@...>; e.gentry@...; Axel Reichwein <axel.reichwein@...>
Subject: Re: OSLC impact call monthly - first draft of link discovery spec intent

 

All, 

I do not think that we need to explain why backlinking is suboptimal and problematic in this spec.

 

One advantage we have in 2023 vs. Early days if OSLC is that now we evolve the standard based on experience and industry needs vs. the bootstraping work we did before implementations existed.

 

This is why I emphasised in the scope document that link discovery providers have already been implemented, and we are standardizing this experience. This is the optimal state for defining a standard. 

 

Eran

 

David,

David,

First of all, let me apologize for confusing many of you. As David correctly presumed, I am proposing (imagining, for a brief second) a (somewhat) radical change to how Config works. Confusingly, I reused oslc_config:VersionResource to denote a union of the current oslc_config:VersionResource and a concept resource at a given version, which would have better been called oslc_config_x:ResourceAtVersion:

On 24 Feb 2023, at 13:29, David Honey2 <david.honey@...> wrote:

The decision to use the concept URI for most of the properties of a versioned object was intentional and became a pivotal part of the design that was agreed more than 8 years ago. There were some essential elements of that design:

1. Links are to concept resources, so those links naturally find the properties of versioned resources.
2. A query for the properties of a concept will, with configuration scoping, deliver the expected results.
3. If you have a scope that spans multiple versions of the same concept, you see the union of property values across those versions. In some use cases, querying against an all data endpoint is useful.

 

Your proposal would be incompatible with this and all the existing implementations compliant with OSLC Configuration Management.

 

David.

 

From: Andrii Berezovskyi <andriib@...> 
Sent: 23 February 2023 19:34
To: oslc-op@...; David Honey2 <david.honey@...>
Cc: Ulrich Martin (BD/PLM5) <Martin.Ulrich@...>; Eran Gery <eran.gery@...>; Jad El-Khoury <jad@...>; Jim Amsden <jamsden@...>; rbaillargeon@...; Herzog Erik <Erik.Herzog@...>; Jim Gammon <james_e_gammon@...>;e.gentry@...; Axel Reichwein <axel.reichwein@...>
Subject: [EXTERNAL] Re: [oslc-op] OSLC impact call monthly - first draft of link discovery spec intent

 

First of all, let me apologize for confusing many of you. As David correctly presumed, I am proposing (imagining, for a brief second) a (somewhat) radical change to how Config works. Confusingly, I reused oslc_config: VersionResource to denote

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

First of all, let me apologize for confusing many of you. As David correctly presumed, I am proposing (imagining, for a brief second) a (somewhat) radical change to how Config works. Confusingly, I reused oslc_config:VersionResource to denote a union of the current oslc_config:VersionResource and a concept resource at a given version, which would have better been called oslc_config_x:ResourceAtVersion:

 

:conceptResourceA-at-version17

    a oslc_config_x:ResourceAtVersion;

    a :someType ;

    dcterms:isVersionOf :conceptResourceA .

    oslc_config:versionId "17" ;

    dcterms:title "Concept Resource A" ;

    :color "red" ;

    dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

 

While OSLC explicitly specifies that there is no such thing as a “main type” of a resource, we know that many implementations designate some types to be more equal than the others. My proposed resource structure would make using the ResourceAtVersion problematic in such cases. In academia and functional programming, there is concept of Lens that could help but we won’t go into that.

 

Also, the radical change I was imagining above could be integrated into OSLC without breaking compatibility:

 

GET https://example.com/conceptResourceA

Configuration-Context: https://example.com/configurations/myConfiguration1

 

Response:

 

Configuration-Context: https://example.com/configurations/myConfiguration1

OSLC-Uri-At-Version: https://example.com/conceptResourceA/version17 

 

 

:conceptResourceA-version17

    a oslc_config:VersionResource ;

    dcterms:isVersionOf :conceptResourceA .

:conceptResourceA

    a :someType ;

    oslc_config:versionId "17" ;

    dcterms:title "Concept Resource A" ;

    :color "red" ;

    dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

 

And then, a GET on https://example.com/conceptResourceA/version17 would return:

:conceptResourceA-at-version17

    a oslc_config_x:ResourceAtVersion;

    a :someType ;

    dcterms:isVersionOf :conceptResourceA .

    oslc_config:versionId "17" ;

    dcterms:title "Concept Resource A" ;

    :color "red" ;

    dcterms:description "Concept resource A as it appears in the state with the URI :conceptResourceA-version17" .

 

 

With this, one could obtain resource representations that don’t conflict with each other when being considered at the same time (and “next-gen-config-aware” clients would be free to discard the first response and to replace links to :conceptResourceA that they know to have been be made to a config-managed resource withhttps://example.com/conceptResourceA/version17). I would also like to add that I am not a big fan of “clever” use of graphs and reification and (except for a narrow set of cases), consider their use a failure in the ontology definition (modelling).

 

Though, to be clear, I understand (most of) the problems that come with such a design. Still, I would take those problems over the uncertainty that exists otherwise.

 

Regarding TRS (I will reply in the same email):

 

Re: This way, if we pull the data via TRS into one large RDF graph, the links would still make sense. Right now, if we do this (enumerating over all available contexts, of course), we’d end up with nonsense in the graph due to statements about different conceptual entities being asserted in RDF on the same subject. 

Neither LQE nor LDX does this. By definition, each fetchable resource is its own graph. Triple stores like Jena TDB allow you to query against a union graph which is, at run time, effectively the union all of the individual graphs. In a configuration scoped world, you perform a query scoped to a specified configuration context, and this excludes the RDF graphs for version resources that are not selected by that configuration context. The query only considers data for version artifacts that are selected by that configuration context. So the “nonsense” you describe doesn’t happen. We do something similar for the new relational store solution for Jazz reporting.

 

Yes, if you query without configuration scoping, you see all the graphs for all versions. The results of such queries, especially for traceability reporting, are rarely useful. ELM customers do not do that.

 

 

While I understand the need to use a graph per response if resources with different semantics yet same URI are floating around, I’ve never seen an authoritative reference in the RDF/Linked Data world that would prescribe storing different resources in different graphs. Otherwise, it would mean that AAA doesn’t apply any more, or, rather, applies to something in a parallel (graph) universe (aka Star Trek chess, this time with graphs). Also, queries over a union of a variable number of graphs  (given that we are now agreeing that interpreting a union of all graphs may not make much sense without any preliminary changes) were never specified as a key use case in SPARQL, making them unoptimized in most cases. I think Stardog and some others are good at this, seeing how graphs are (ab)used in the real world. RDF-Star could change things, however (I can imagine how a good RDF-Star implementation would make triple-level authz simple and performant).

 

If OSLC wants to prescribe some specific way of interpreting its resources w.r.t graphs, it could use TriG instead of Turtle etc. to return graphs (it only does so in a non-normative example for Config). Also, if “each fetchable resource is its own graph”, how should we interpret TriG with graphs inside? Graphs inside of a graph? Thus, I remain convinced that having multiple OSLC endpoints return responses that don’t make sense once put together into one graph is bad (because combining data from multiple sources/endpoints is the essential task in integration).

 

–Andrew.

On 23 Feb 2023, at 18:28, David Honey2 via lists.oasis-open-projects.org<david.honey=ibm.com@...> wrote:

 

Responding to Andrew…

 

The OSLC configuration management specification describes that almost all of the properties of a version resource are made against a subject that is the concept URI of that resource. That was a pivotal point of the design. Are you proposing a change here?

 

In terms of what the target of a link is, while the configuration management spec recommends the use of concept resources that are solved in a separately supplied configuration context, it does not prohibit the use of links to version resources. There are some limited use cases where this might be beneficial, but these are usually exceptional cases. ELM currently only uses links to concept resources.

 

David.

 

Unless otherwise stated above:

IBM United Kingdom Limited
Registered in England and Wales with number 741598
Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU