|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child item that the parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link direction)
regards
______________________________
Jad El-khoury,
PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
|
|
|
Jad
Suspect links related to any oslc link. not specific to “parent/child”. A classical use case is a link between a requirement and a design element that refines it.
Also, Suspect information depends on a configuration. A link can be suspect in one configuration and valid in another.
The way it is implemented in Jazz is based on a dedicated service. Applications need to interact with the service to retrieve and update the state of a link.
Eran
On 1 Nov 2022, at 1:25, Jad El-Khoury <jad@...> wrote:
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices? For example,
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child item that the parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link direction)
regards
______________________________
Jad El-khoury,
PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary, but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with a
content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
toggle quoted message
Show quoted text
From: oslc-op@... <oslc-op@...>
On Behalf Of Jad El-Khoury
Sent: 01 November 2022 05:25
To: oslc-op@...
Subject: [EXTERNAL] [oslc-op] Suspect links
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some
good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child item that the
parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
|
|
|
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Eran
On 1 Nov 2022, at 5:25, David Honey2 <david.honey@...> wrote:
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published vocabulary for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary, but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with a
content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
From: oslc-op@... <oslc-op@...>
On Behalf Of Jad El-Khoury
Sent: 01 November 2022 05:25
To: oslc-op@...
Subject: [EXTERNAL] [oslc-op] Suspect links
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some
good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child item that the
parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
|
|
|
The point about using a content hash is that it is not necessarily state-specific. For example, a user might change a custom property on a requirement, and because that is not used
for the content hash, that change would result in the same content hash and hence not affect the link validity for a test case
validates requirement link to that new version of requirement compared to its history predecessor.
The original design supported the idea, in the future, of multiple link validity profiles. A profile represents some aspect of link validity and the subset of data from which a content
hash is computed. For example, one might have the default profile, and a separate safety critical profile which might consider more data on each resource for the content hash. Each tool might define the set of data that is used for the content hash for a specific
profile. Hence a link might have multiple link validity status values, up to a maximum of one per profile. In practice, ELM only supports one profile (the default profile) and there are currently no plans to support multiple profiles.
Best regards,
David
toggle quoted message
Show quoted text
From: Eran Gery <eran.gery@...>
Sent: 01 November 2022 10:06
To: oslc-op@...; David Honey2 <david.honey@...>
Cc: jad@...
Subject: Re: [EXTERNAL] Re: [oslc-op] Suspect links
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published vocabulary
for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary,
but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with a
content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some
good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child item that the
parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
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
|
|
|
Thanks Eran and David for your help
Sounds like the content hash fullfills the same functionality as the ETag?
From your link (https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity),
I read that “If your project does not use configuration management, you can enable suspect link traceability for the project.”.
So suspect seems to be the same as validity for non-CM scenarios.
It would be useful to have a standard approach to deal with suspect/validity.
regards
______________________________
Jad El-khoury,
PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
toggle quoted message
Show quoted text
From: David Honey2 <david.honey@...>
Sent: Tuesday, 1 November 2022 11:23
To: Eran Gery <eran.gery@...>; oslc-op@...
Cc: Jad El-Khoury <jad@...>
Subject: RE: [oslc-op] Suspect links
The point about using a content hash is that it is not necessarily state-specific. For example, a user might change a custom property on a requirement, and because that
is not used for the content hash, that change would result in the same content hash and hence not affect the link validity for a test case
validates requirement link to that new version of requirement compared to its history predecessor.
The original design supported the idea, in the future, of multiple link validity profiles. A profile represents some aspect of link validity and the subset of data from
which a content hash is computed. For example, one might have the default profile, and a separate safety critical profile which might consider more data on each resource for the content hash. Each tool might define the set of data that is used for the content
hash for a specific profile. Hence a link might have multiple link validity status values, up to a maximum of one per profile. In practice, ELM only supports one profile (the default profile) and there are currently no plans to support multiple profiles.
Best regards,
David
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published
vocabulary for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary,
but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with
a content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good
hints on some good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child
item that the parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link
direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
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
|
|
|
Sounds like the content hash fullfills the same functionality as the ETag?
No, they serve different purposes and have different usage. An Etag header value directly represents the state of a resource. If any aspect of the RDF representation of a resource
changes, the Etag must be different. This is required so that proxy HTTP servers can function correctly. The content hash is a hash of some subset of the data and only changes if that subset changes.
toggle quoted message
Show quoted text
From: Jad El-Khoury <jad@...>
Sent: 01 November 2022 10:50
To: David Honey2 <david.honey@...>; Eran Gery <eran.gery@...>; oslc-op@...
Subject: [EXTERNAL] RE: [oslc-op] Suspect links
Thanks Eran and David for your help Sounds like the content hash fullfills the same functionality as the ETag? From your link (https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Thanks Eran and David for your help
Sounds like the content hash fullfills the same functionality as the ETag?
From your link (https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity), I read
that “If your project does not use configuration management, you can enable suspect link traceability for the project.”.
So suspect seems to be the same as validity for non-CM scenarios.
It would be useful to have a standard approach to deal with suspect/validity.
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
The point about using a content hash is that it is not necessarily state-specific. For example, a user might change a custom property on a requirement, and because that is not used
for the content hash, that change would result in the same content hash and hence not affect the link validity for a test case
validates requirement link to that new version of requirement compared to its history predecessor.
The original design supported the idea, in the future, of multiple link validity profiles. A profile represents some aspect of link validity and the subset of data from which a content
hash is computed. For example, one might have the default profile, and a separate safety critical profile which might consider more data on each resource for the content hash. Each tool might define the set of data that is used for the content hash for a specific
profile. Hence a link might have multiple link validity status values, up to a maximum of one per profile. In practice, ELM only supports one profile (the default profile) and there are currently no plans to support multiple profiles.
Best regards,
David
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published vocabulary
for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary,
but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with a
content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some
good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child item that the
parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
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
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
|
|
|
David
It does represents a state within the resource, not necessarily the total state represented by its memory footprint. This is similar to where we use explicit state models of objects, that abstract away properties which are not relevant for a viewpoint.
Just saying “hash” does not convey the idea that validity does consider states of of the resources, across which the are considered valid.
Br
Eran
On 1 Nov 2022, at 6:22, David Honey2 <david.honey@...> wrote:
The point about using a content hash is that it is not necessarily state-specific. For example, a user might change a custom property on a requirement, and because that is not used
for the content hash, that change would result in the same content hash and hence not affect the link validity for a test case
validates requirement link to that new version of requirement compared to its history predecessor.
The original design supported the idea, in the future, of multiple link validity profiles. A profile represents some aspect of link validity and the subset of data from which a content
hash is computed. For example, one might have the default profile, and a separate safety critical profile which might consider more data on each resource for the content hash. Each tool might define the set of data that is used for the content hash for a specific
profile. Hence a link might have multiple link validity status values, up to a maximum of one per profile. In practice, ELM only supports one profile (the default profile) and there are currently no plans to support multiple profiles.
Best regards,
David
From: Eran Gery <eran.gery@...>
Sent: 01 November 2022 10:06
To: oslc-op@...; David Honey2 <david.honey@...>
Cc: jad@...
Subject: Re: [EXTERNAL] Re: [oslc-op] Suspect links
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published vocabulary
for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary,
but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with a
content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some
good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child item that the
parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
|
|
|
I was trying to distinguish the content hash from state. If you create a new version of a versioned artifact and change none of its data, that will create a new state, and that state
will be associated with an Etag.
The important point about the design is the abstraction between the link validity resource and the source resource(s) and target resource(s) to which it might apply. A link validity
resource does not reference specific versions of resources. It only references the content hash of the source and of the target. That was an intentional part of the design so that a link might remain valid and not become suspect when inconsequential changes
are made to either the source or the target of the link.
toggle quoted message
Show quoted text
From: Eran Gery <eran.gery@...>
Sent: 01 November 2022 10:58
To: David Honey2 <david.honey@...>
Cc: oslc-op@...; Jad El-Khoury <jad@...>
Subject: Re: [EXTERNAL] Re: [oslc-op] Suspect links
David
It does represents a state within the resource, not necessarily the total state represented by its memory footprint. This is similar to where we use explicit state models of objects, that abstract away properties which are not relevant
for a viewpoint.
Just saying “hash” does not convey the idea that validity does consider states of of the resources, across which the are considered valid.
The point about using a content hash is that it is not necessarily state-specific. For example, a user might change a custom property on a requirement, and because that is not used
for the content hash, that change would result in the same content hash and hence not affect the link validity for a test case
validates requirement link to that new version of requirement compared to its history predecessor.
The original design supported the idea, in the future, of multiple link validity profiles. A profile represents some aspect of link validity and the subset of data from which a content
hash is computed. For example, one might have the default profile, and a separate safety critical profile which might consider more data on each resource for the content hash. Each tool might define the set of data that is used for the content hash for a specific
profile. Hence a link might have multiple link validity status values, up to a maximum of one per profile. In practice, ELM only supports one profile (the default profile) and there are currently no plans to support multiple profiles.
Best regards,
David
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published vocabulary
for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary,
but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with a
content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some
good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child item that the
parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
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
|
|
|
I think I got the rough idea. Thanks guys.
And one conclusion is that I don’t need to dig into the standard to try to find something. This seems to be Jazz-specific.
Regards
______________________________
Jad El-khoury,
PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
toggle quoted message
Show quoted text
From: David Honey2 <david.honey@...>
Sent: Tuesday, 1 November 2022 12:05
To: Eran Gery <eran.gery@...>
Cc: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: [oslc-op] Suspect links
I was trying to distinguish the content hash from state. If you create a new version of a versioned artifact and change none of its data, that will create a new state,
and that state will be associated with an Etag.
The important point about the design is the abstraction between the link validity resource and the source resource(s) and target resource(s) to which it might apply.
A link validity resource does not reference specific versions of resources. It only references the content hash of the source and of the target. That was an intentional part of the design so that a link might remain valid and not become suspect when inconsequential
changes are made to either the source or the target of the link.
David
It does represents a state within the resource, not necessarily the total state represented by its memory footprint. This is similar to where we use explicit state models of objects, that abstract away properties which
are not relevant for a viewpoint.
Just saying “hash” does not convey the idea that validity does consider states of of the resources, across which the are considered valid.
The point about using a content hash is that it is not necessarily state-specific. For example, a user might change a custom property on a requirement, and because that
is not used for the content hash, that change would result in the same content hash and hence not affect the link validity for a test case
validates requirement link to that new version of requirement compared to its history predecessor.
The original design supported the idea, in the future, of multiple link validity profiles. A profile represents some aspect of link validity and the subset of data from
which a content hash is computed. For example, one might have the default profile, and a separate safety critical profile which might consider more data on each resource for the content hash. Each tool might define the set of data that is used for the content
hash for a specific profile. Hence a link might have multiple link validity status values, up to a maximum of one per profile. In practice, ELM only supports one profile (the default profile) and there are currently no plans to support multiple profiles.
Best regards,
David
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published
vocabulary for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary,
but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with
a content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good
hints on some good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child
item that the parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link
direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
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
|
|
|
Jad
This is correct. But imo we need to put it in the standard roadmap. Validity is essential for linked data processes to stay outside.
Eran
On 1 Nov 2022, at 8:27, Jad El-Khoury <jad@...> wrote:
I think I got the rough idea. Thanks guys. And one conclusion is that I don’t need to dig into the standard to try to find something. This seems to be Jazz-specific. Regards ______________________________
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
ZjQcmQRYFpfptBannerEnd
I think I got the rough idea. Thanks guys.
And one conclusion is that I don’t need to dig into the standard to try to find something. This seems to be Jazz-specific.
Regards
______________________________
Jad El-khoury,
PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
From: David Honey2 <david.honey@...>
Sent: Tuesday, 1 November 2022 12:05
To: Eran Gery <eran.gery@...>
Cc: oslc-op@...; Jad El-Khoury <jad@...>
Subject: RE: [oslc-op] Suspect links
I was trying to distinguish the content hash from state. If you create a new version of a versioned artifact and change none of its data, that will create a new state,
and that state will be associated with an Etag.
The important point about the design is the abstraction between the link validity resource and the source resource(s) and target resource(s) to which it might apply.
A link validity resource does not reference specific versions of resources. It only references the content hash of the source and of the target. That was an intentional part of the design so that a link might remain valid and not become suspect when inconsequential
changes are made to either the source or the target of the link.
David
It does represents a state within the resource, not necessarily the total state represented by its memory footprint. This is similar to where we use explicit state models of objects, that abstract away properties which
are not relevant for a viewpoint.
Just saying “hash” does not convey the idea that validity does consider states of of the resources, across which the are considered valid.
The point about using a content hash is that it is not necessarily state-specific. For example, a user might change a custom property on a requirement, and because that
is not used for the content hash, that change would result in the same content hash and hence not affect the link validity for a test case
validates requirement link to that new version of requirement compared to its history predecessor.
The original design supported the idea, in the future, of multiple link validity profiles. A profile represents some aspect of link validity and the subset of data from
which a content hash is computed. For example, one might have the default profile, and a separate safety critical profile which might consider more data on each resource for the content hash. Each tool might define the set of data that is used for the content
hash for a specific profile. Hence a link might have multiple link validity status values, up to a maximum of one per profile. In practice, ELM only supports one profile (the default profile) and there are currently no plans to support multiple profiles.
Best regards,
David
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published
vocabulary for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary,
but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with
a content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good
hints on some good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child
item that the parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link
direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
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
|
|
|
Agree
And at the risk of being inaccurate again (comparing ETag with Content Hash), we can start with the simple non-CM suspect tagging (just to indicate that the other end
might have changed). And then of course tackle Validity.
regards
______________________________
Jad El-khoury,
PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
toggle quoted message
Show quoted text
From: Eran Gery <eran.gery@...>
Sent: Tuesday, 1 November 2022 13:34
To: Jad El-Khoury <jad@...>
Cc: David Honey2 <david.honey@...>; oslc-op@...
Subject: RE: [oslc-op] Suspect links
Jad
This is correct. But imo we need to put it in the standard roadmap. Validity is essential for linked data processes to stay outside.
On 1 Nov 2022, at 8:27, Jad El-Khoury <jad@...> wrote:
I think I got the rough idea. Thanks guys. And one conclusion is that I don’t need to dig into the standard to try to find something. This seems to be Jazz-specific.
Regards ______________________________
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
I think I got the rough idea. Thanks guys.
And one conclusion is that I don’t need to dig into the standard to try to find something. This seems to be Jazz-specific.
Regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
I was trying to distinguish the content hash from state. If you create a new version of a versioned artifact and change none of its data, that will create a new state,
and that state will be associated with an Etag.
The important point about the design is the abstraction between the link validity resource and the source resource(s) and target resource(s) to which it might apply.
A link validity resource does not reference specific versions of resources. It only references the content hash of the source and of the target. That was an intentional part of the design so that a link might remain valid and not become suspect when inconsequential
changes are made to either the source or the target of the link.
David
It does represents a state within the resource, not necessarily the total state represented by its memory footprint. This is similar to where we use explicit state models of objects, that abstract away properties which
are not relevant for a viewpoint.
Just saying “hash” does not convey the idea that validity does consider states of of the resources, across which the are considered valid.
The point about using a content hash is that it is not necessarily state-specific. For example, a user might change a custom property on a requirement, and because that
is not used for the content hash, that change would result in the same content hash and hence not affect the link validity for a test case
validates requirement link to that new version of requirement compared to its history predecessor.
The original design supported the idea, in the future, of multiple link validity profiles. A profile represents some aspect of link validity and the subset of data from
which a content hash is computed. For example, one might have the default profile, and a separate safety critical profile which might consider more data on each resource for the content hash. Each tool might define the set of data that is used for the content
hash for a specific profile. Hence a link might have multiple link validity status values, up to a maximum of one per profile. In practice, ELM only supports one profile (the default profile) and there are currently no plans to support multiple profiles.
Best regards,
David
Worth adding that the hash represents a state of a resource, as validity is across particular resource states.
A specific way to encode a state is considering a version of a resource. That means that every time a resource in a configuration gets a new version, it will get a new hash value, and change validity status.
Jad, I sounds like you’re describing link validity. See https: //www. ibm. com/docs/en/elm/7. 0. 1?topic=traceability-link-validity There is a published
vocabulary for it at https: //jazz. net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Jad,
I sounds like you’re describing
link validity. See https://www.ibm.com/docs/en/elm/7.0.1?topic=traceability-link-validity
There is a published vocabulary for it at
https://jazz.net/wiki/bin/view/LinkedData/JazzLinkValidityVocabulary,
but none of this is covered by OSLC.
There is no eventing/notification for changes to the link validity of links because the data model doesn’t work that way. Each versioned resource is associated with
a content hash which an application computes based on some subset of the data it sees as relevant. A link validity resource describes a relationship type, source content hash, target content hash, a status and optional comment. ELM applications discover
the link validity status for a specific link in a configuration context using a proprietary private REST API. Report Builder can report on link validity providing the source resources, target resources, and link validity resources are indexed in the
Lifecycle Query Engine.
Best regards,
David
Hi When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good
hints on some good practices? For example,
|
This Message Is From an External Sender
|
|
This message came from outside your organization.
|
|
|
Hi
When creating links between applications, is there some OSLC mechanism to identify and tag “Suspect” OSC links? If not covered by OSLC, any good hints on some good practices?
For example,
* how can an OSLC Application know that a resource it links to (in another application) has been changed?
* how can an OSLC Application inform another application that a resource it links to has been changed?
To my understanding
- suspect links are only relevant on a parent-child relationship when the parent has changed (to warn the child
item that the parent has changed)
- And, with OSLC, we don’t really have the semantics of parent-child semantics (which is different from the link
direction)
regards
______________________________
Jad El-khoury, PhD
KTH Royal Institute of Technology
School of Industrial Engineering and Management, Mechatronics Division
Brinellvägen 83, SE-100 44 Stockholm, Sweden
Phone: +46(0)8 790 6877 Mobile: +46(0)70 773 93 45
jad@...,
www.kth.se
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
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
|
|
|
