1. Topics
  2. Link Discovery Management Specification WD

Link Discovery Management Specification WD

Jim Amsden
 

I have created a new folder specs/ldm and an initial WD https://github.com/oslc-op/oslc-specs/blob/master/specs/ldm/link-discovery-management-spec.html. This document is direct HTML using ReSpec, and is not using the Markdown facility we created for the linking profile spec.

 

I think we agreed yesterday that:

 

1. The LDM specification does not need to address how the LDM server gets its link content, how it stores those links, or any query endpoint it might provide (including OSLC Query). TRS is one possible way for LDM server to get links contributed from other OSLC servers, but there may be other ways. LDM spec only addresses the services an LDM server must provide to a client to discover incoming links.

 

2. LDM servers must provide a response containing triples that provide the incoming links given a list of target resources (at least one), an optional list of RDF predicate URIs (all returned by default( and optionally a Configuration-Context if the links are version managed.

 

3. LDM server should provide a collection of OSLC Service Provider resources that contributed links to the LDM server.

 

4. How LDM servers themselves are discovered uses exiting server discovery capabilities described in OSLC core, and possibly refined in the linking profile specification. Nothing further should be needed in the LDM specification.

 

 
David Honey2
 

#1 Yes


#2 Yes

 

#3 – Was this discussed in the 1st half. I don’t recall this being in the 2nd half that I attended.

What is the use case for this?
In general, a TRS, by itself, does not provide any information about the service providers of the tracked resources described in that TRS. Each tracked resource may optionally represent that using oslc:serviceProvider, but it’s optional. ILinkIxdexService does not currently support this.

 

#4 – There were multiple opinions on this, including that the spec should not describe discovery, but that we might provide non-normative guidance. It might be a server implementation issue. For example, have a configurable property that specifies the URI of that REST service.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: 24 February 2023 14:35
To: oslc-op@...
Subject: [EXTERNAL] [oslc-op] Link Discovery Management Specification WD

 

I have created a new folder specs/ldm and an initial WD https: //github. com/oslc-op/oslc-specs/blob/master/specs/ldm/link-discovery-management-spec. html. This document is direct HTML using ReSpec, and is not using the Markdown facility we created

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I have created a new folder specs/ldm and an initial WD https://github.com/oslc-op/oslc-specs/blob/master/specs/ldm/link-discovery-management-spec.html. This document is direct HTML using ReSpec, and is not using the Markdown facility we created for the linking profile spec.

 

I think we agreed yesterday that:

 

1. The LDM specification does not need to address how the LDM server gets its link content, how it stores those links, or any query endpoint it might provide (including OSLC Query). TRS is one possible way for LDM server to get links contributed from other OSLC servers, but there may be other ways. LDM spec only addresses the services an LDM server must provide to a client to discover incoming links.

 

2. LDM servers must provide a response containing triples that provide the incoming links given a list of target resources (at least one), an optional list of RDF predicate URIs (all returned by default( and optionally a Configuration-Context if the links are version managed.

 

3. LDM server should provide a collection of OSLC Service Provider resources that contributed links to the LDM server.

 

4. How LDM servers themselves are discovered uses exiting server discovery capabilities described in OSLC core, and possibly refined in the linking profile specification. Nothing further should be needed in the LDM specification.

 

 

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
"Eran Gery"
 

David

You are correct, 3 was discussed briefly towards the end. 
We should discuss it further. I believe the motivation is to enable scalability by having different incoming links providers each focusing on a subset of the resource providers.

In the meantime we focus on 2 for the spec writing.

Regards,
Eran



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


#1 Yes #2 Yes #3 – Was this discussed in the 1st half. I don’t recall this being in the 2nd half that I attended. What is the use case for this? In general, a TRS, by itself, does not provide any information about the service providers of the
ZjQcmQRYFpfptBannerStart
This Message Is From an External Sender
This message came from outside your organization.
 
ZjQcmQRYFpfptBannerEnd

#1 Yes


#2 Yes

 

#3 – Was this discussed in the 1st half. I don’t recall this being in the 2nd half that I attended.

What is the use case for this?
In general, a TRS, by itself, does not provide any information about the service providers of the tracked resources described in that TRS. Each tracked resource may optionally represent that using oslc:serviceProvider, but it’s optional. ILinkIxdexService does not currently support this.

 

#4 – There were multiple opinions on this, including that the spec should not describe discovery, but that we might provide non-normative guidance. It might be a server implementation issue. For example, have a configurable property that specifies the URI of that REST service.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: 24 February 2023 14:35
To: oslc-op@...
Subject: [EXTERNAL] [oslc-op] Link Discovery Management Specification WD

 

I have created a new folder specs/ldm and an initial WD https: //github. com/oslc-op/oslc-specs/blob/master/specs/ldm/link-discovery-management-spec. html. This document is direct HTML using ReSpec, and is not using the Markdown facility we created

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I have created a new folder specs/ldm and an initial WD https://github.com/oslc-op/oslc-specs/blob/master/specs/ldm/link-discovery-management-spec.html. This document is direct HTML using ReSpec, and is not using the Markdown facility we created for the linking profile spec.

 

I think we agreed yesterday that:

 

1. The LDM specification does not need to address how the LDM server gets its link content, how it stores those links, or any query endpoint it might provide (including OSLC Query). TRS is one possible way for LDM server to get links contributed from other OSLC servers, but there may be other ways. LDM spec only addresses the services an LDM server must provide to a client to discover incoming links.

 

2. LDM servers must provide a response containing triples that provide the incoming links given a list of target resources (at least one), an optional list of RDF predicate URIs (all returned by default( and optionally a Configuration-Context if the links are version managed.

 

3. LDM server should provide a collection of OSLC Service Provider resources that contributed links to the LDM server.

 

4. How LDM servers themselves are discovered uses exiting server discovery capabilities described in OSLC core, and possibly refined in the linking profile specification. Nothing further should be needed in the LDM specification.

 

 

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 Honey2
 

We briefly touched on the idea of having multiple LDMs.

This isn’t something that ELM supports today.

 

I’m not sure I understand how this would help for the use case you describe.

 

All a server might know are the service providers for the target resources it owns. It is unlikely to know what service providers might be associated with source artifacts of links that point to those target resources. Those resources are likely to be stored in other servers. If you have multiple LDMs, I think the only way to find all incoming links to those target resources is to ask all of them.

 

Consider the following scenario:

 

LDM1 indexes data from QMServer1, and GCMServer1.

LDM2 indexes data from QMServer2, and GCMServer1.

LDM3 indexes data from CCMServer1, and GCMServer1

 

Note that GCMServer1 has to be indexed by all the LDMs in order for configuration scoping to work, and none of them index an RM server.

 

An RM server wants to discover the incoming validatesRequirement links for a specified requirement in that RM server.  Knowing the service providers for LDM1, LDM2, and LDM3 doesn’t help. The RM server would have to ask LDM1, LDM2, and LDM3.

 

If you wanted to support being able to determine which subset of LDMs might be applicable, you might do so knowing the range of the specified link types. For example, you might determine that validatesRequirement only comes from test cases.

If you knew that only LDM1 and LDM2 indexed test cases, you’d know you should ask LDM1 and LDM2, but need not ask LDM3.

 

Such a design works well when the range of an OSLC property is constrained to specific types. If the range is, for example, oslc:Resource, or is not specified, then the source resource might be of any type, and you have to query all LDMs.

 

If, for each query, you had to ask every LDM what RDF types it indexes, in order to work out a subset, that potentially negates the benefit of such a design. You might be better off sending requests to LDM1, LDM2, and LDM3 concurrently.

 

Best regards,

David.

 

From: Eran Gery <eran.gery@...>
Sent: 24 February 2023 15:22
To: oslc-op@...; David Honey2 <david.honey@...>
Cc: Jim Amsden <jamsden@...>
Subject: Re: [EXTERNAL] Re: [oslc-op] Link Discovery Management Specification WD

 

David

 

You are correct, 3 was discussed briefly towards the end. 

We should discuss it further. I believe the motivation is to enable scalability by having different incoming links providers each focusing on a subset of the resource providers.

 

In the meantime we focus on 2 for the spec writing.

 

Regards,

Eran

 



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



#1 Yes #2 Yes #3 – Was this discussed in the 1st half. I don’t recall this being in the 2nd half that I attended. What is the use case for this? In general, a TRS, by itself, does not provide any information about the service providers of the

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

#1 Yes


#2 Yes

 

#3 – Was this discussed in the 1st half. I don’t recall this being in the 2nd half that I attended.

What is the use case for this?
In general, a TRS, by itself, does not provide any information about the service providers of the tracked resources described in that TRS. Each tracked resource may optionally represent that using oslc:serviceProvider, but it’s optional. ILinkIxdexService does not currently support this.

 

#4 – There were multiple opinions on this, including that the spec should not describe discovery, but that we might provide non-normative guidance. It might be a server implementation issue. For example, have a configurable property that specifies the URI of that REST service.

 

From: oslc-op@... <oslc-op@...> On Behalf Of Jim Amsden
Sent: 24 February 2023 14:35
To: oslc-op@...
Subject: [EXTERNAL] [oslc-op] Link Discovery Management Specification WD

 

I have created a new folder specs/ldm and an initial WD https: //github. com/oslc-op/oslc-specs/blob/master/specs/ldm/link-discovery-management-spec. html. This document is direct HTML using ReSpec, and is not using the Markdown facility we created

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

I have created a new folder specs/ldm and an initial WD https://github.com/oslc-op/oslc-specs/blob/master/specs/ldm/link-discovery-management-spec.html. This document is direct HTML using ReSpec, and is not using the Markdown facility we created for the linking profile spec.

 

I think we agreed yesterday that:

 

1. The LDM specification does not need to address how the LDM server gets its link content, how it stores those links, or any query endpoint it might provide (including OSLC Query). TRS is one possible way for LDM server to get links contributed from other OSLC servers, but there may be other ways. LDM spec only addresses the services an LDM server must provide to a client to discover incoming links.

 

2. LDM servers must provide a response containing triples that provide the incoming links given a list of target resources (at least one), an optional list of RDF predicate URIs (all returned by default( and optionally a Configuration-Context if the links are version managed.

 

3. LDM server should provide a collection of OSLC Service Provider resources that contributed links to the LDM server.

 

4. How LDM servers themselves are discovered uses exiting server discovery capabilities described in OSLC core, and possibly refined in the linking profile specification. Nothing further should be needed in the LDM specification.

 

 

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
1 - 4 of 4