OSLC-OP 2023-03-16 Meeting Minutes

Jim Amsden

OSLC OP Meeting minutes (Mar 02, 2023)

Chairs: Jim Amsden, Jad El-khoury


  • [x] Jim Amsden (KTH)
  • [x] Jad El-khoury (KTH)
  • [ ] Gray Bachelor (IBM)
  • [x] David Honey (IBM)
  • [x] Eran Gray (IBM)
  • [ ] Jim Gammon (Raython Technologies)
  • [ ] Partrick Ollerton (PTC)
  • [ ] Michael Rowe (IBM)
  • [ ] Ed Gentry (MID)
  • [ ] Tanu (PTC)
  • [ ] Frej (SodiusWillert)
  • [ ] Andrew Berezovskyi (KTH)
  • [x] Ralph Schoon (IBM)
  • [ ] Axel Reichwein (Koneksys)
  • [x] Martin Ulrich (Bosch)

Previous minutes: https://github.com/oslc-op/oslc-admin/blob/master/minutes/2022/2023-03-09.md


  • [ ] Change Management errata review and merge
  • [ ] Linking Profiles specification editing progress
  • [ ] Link Discovery Management Topics
  • [ ] Configuration Management Topics - establishing the scope for config 1.1?
    • [ ] Change Set Delivery
    • [ ] History
    • [ ] PLM versioning alignment


Change Management

Pull request pending reviews. May need ot add a section describing the erreata. 

Prep for PGB meeting

The Quarterly PGB meeting is Tuesday 21 March. Proposed agenda:

  1. Status on OSLC Specifications (TRS 3.0 COS, Configuration Management 1.0 COS, Change Management errata)
  2. Status of Linking Profile 
  3. Status of Link Discovery Management spec
  4. Proposal for OSLC Product Workgroup

LDM Specification review

using POST to {query endpoint} Config-Context header (optional) query request body: list of object URI references list of predicats Response: triples including: (incoming subject, predicate, reference object) The format of the POST entity request body can be specified ha having Content-Type application/x-www-form-urlencoded, multipart/form-datam, application/json, application/xml, etc. The LDM specification will need to state what Content-Types are supported and provide their request body formats. 

Discovery of LDM servers URIs follows the same guidelines as in OSLC Core (e.g., rootservices, OPTIONS, etc.). LDM spec does not need to address this further

We agree that federating multiple LDM servers is out of scope, clients could use multiple LDM servers is they want, but how they do that is up to them. It could be to cluster multiple LDM servers that have the same data, or multiple LDM servers that have the same or possibly overlapping data. 

An LDM server has a server URI, some descriptor URI that provides some metadata about the server. In that descriptor is the URI of the {query endpoint} referenced above.

The LDM spec needs to define: 1. GET on LDM serverURI results 2. URI to access and content for LDM metadata 3. queryBase URI for the POST query endpoint

IBM LDX is a TRS consumer. So it is possible to view the Admin page of that server to see what TRS providers are used as its data sources. This provides a means of determining what information is available in that LDX server. 

LDM needs to optionally provide some similar mechanism to allow clients to discover the scope of links that are available from that server. It is possible that an OSLC ServiceProvider URL could provide minimal information.

This information might also include a means of discovering the predicates that are available. 

Action items

  • [ ] Jim (or Jad?) to publish NS files - with help of Andrew. Config Management PSD01 was published, but not TRS? Andrew says PSD01 files were published for TRS 
  • [ ] Jim to publish NS files for PS01 Config and TRS, not wait until OS. COS is not really a published stage, just a milestone 
  • [ ] Jim will check the release tags, at least the latest revision is tagged.
  • [ ] Jim will continue the process to submit Config Management 1.0 for COS - pending 3rd SoU
  • [ ] Patrick & Tanupreet to provide a SoU for Config Managemnet 1.0 (They got an email from Andrew with info)