@@ -394,8 +394,8 @@ Note that in some previous experimental versions of the RAFS DDMS, this DDMS too
Preparing for graduation, the RAFS DDMS team kept the "samplesanalysis" v2 endpoint unchanged (as stable as possible). However, we added capabilities under the "dev" version since the M24 release, to add new functionality for visibility into potential new capabilities, opening the opportunity for testing, feedback, and refinement.
The RAFS DDMS team considers the "dev" endpoint in the "alpha" testing phase.
ME
The RAFS DDMS team considers the "dev" endpoint in the "alpha" testing phase. ME
* The ["dev" endpoint is documented here](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/rock-and-fluid-sample/rafs-ddms-services/-/tree/main/docs/dev), along with its filtering capabilities.
* The ["v2" endpoint is documented in the tutorial here](https://community.opengroup.org/osdu/platform/domain-data-mgmt-services/rock-and-fluid-sample/rafs-ddms-services/-/tree/main/docs/dev?ref_type=heads#available-metadata-fields), along with its filtering capabilities.
...
...
@@ -411,3 +411,11 @@ Aliases, as they are implemented within OSDU, are not directly referenced in the
On retrieval of data through a query within the RAFS DDMS API service, aliases will not be directly supported. It would be the responsibility of downstream applications to resolve a query using an alias via the OSDU search service and then run an API call using the reference-data alias' proper ID string.
On ingest and data preparation, data loading applications can check the reference lists within OSDU directly using the search service external to RAFS DDMS, and resolve the alias into its ID string prior to ingestion into RAFS DDMS.
### 16. For the data type, PVT.ConstantCompositionExpansion (CCE), when the test is done at different temperatures, how is that handled by the catalog and content schemas?
For some Sample Analysis Types (e.g. lab tests), part of the lab process is to perform the test at varying temperatures and pressures. In this case, a temperature is captured at each test step in the content schema. This is true, for example, for `PVT.MultiStageSeparatorTest`. In this scenario, there would be a single SamplesAnalysis WPC to catalog this dataset, which contains varying temperatures.
By contrast, for `PVT.ConstantCompositionExpansion` (CCE), the test process does not require varying temperatures. There is a single temperature value for the entire test; This is reflected in the content schema.
In cases in which additional partial CCE tests were run and partial datasets were produced in order to determine the appropriate saturation pressure for the main test, the temperature on those partial tests may indeed vary compared to the main test. In this scenario, each of those tests - the partial and the main tests - would be cataloged by their own instance of a SamplesAnalysis WPC. In order to associate these partial and main tests together if desired, best practice would be to use a form of [OSDU data lineage](https://community.opengroup.org/osdu/data/data-definitions/-/blob/master/Guides/Chapters/05-Provenance.md#53-lineage-assertion), such as Lineage Assertions (the simpler choice) or Activity (a more detailed choice).
