ISO-TC211/XML

ambiguous LI_Source usage for lineage process step (19115-2 2017)

Opened this issue · 7 comments

smrgeoinfo commented

in Extended Lineage Information revision (19115-2 2017), LE_Process step can have a source association directly to an LI_Source (or LE_Source), OR can have a processingInformation.LE_Processing.parameter.LE_ProcessParameter.resource.LI_Source. Having two paths to encode the same information creates challenges for interoperability. It will be unclear when a source should be linked as a parameter.resource (could be an input or output), or as processStep.source or processStep.output.
Perhaps need a constraint that if one source is represented as a parameter resource then all sources must be represented as parameter resources (in and out); something like '(count(mrl:source) >0) and (count(mrl:resource) > 0) = FALSE. (probably requires schematron to test...).

tedhabermann commented

I think the use case for the LI_Source in LE_Process_Parameter was processSteps where a source was an input parameter. Note the constraint on the LE_ProcessParameter, there must be a value or a resource for the parameter. Perhaps some examples would help us understand this. If we had a situation where a DEM was being used as input to a processStep. The DEM could (actually should) be described as a LE_Source associated directly with the Process Step. Would it also be needed for the ProcessParameter? Or maybe the correct answer is to use the ProcessParameter only for Records that are input for the process - i.e. drop the LI_Source?

smrgeoinfo commented

I like the drop LI_Source and make the processParameter data type a record.

ebleys commented

Hi Guys
I seem to be missing the UML for this?
Is there a risk in making LE_Processing|LE_ProcessStep.processParameter of type record (and dropping the link to a L?_Source) that all consistency will be lost below that point and data source for a process step will be difficult to identify?
Cheers
E

tedhabermann commented

On Steve's suggestion - the LE_Processing class already includes a Record/RecordType combination as otherProperty/otherProperyType. If the parameter is just a Record, then it seems to me that it would be redundant. The idea of making it a SV_Parameter was to pick up name, direction, description, optionality, and repeatability. These concepts would not be available in a standard way if parameter was just a Record. Are these properties important? I think so.

So I like bringing these properties into the LE_ProcessParameter in a new class and dropping the LI_Source.

Does that work?

smrgeoinfo commented

That looks like what's in teh model now, so the proposal is to drop the 'resource' property on LE_ProcessParameter. That works for me. Its not clear to me what the use case would be for a parameter 'resource' that couldn't be represented using the value/valueType construct. At this level of specificity, I'm not sure interoperability is really possible outside of a small community (one service profile...) that could define its own conventions for the value/valueType content.

tedhabermann commented

The proposal is currently is to 1) delete the resource/LI_Source property and 2) add the properties that are currently in SV_Parameter.

The result is LE_ProcessingParameter that includes:

  • name : MemberName (gives name/type of parameter)
  • direction: codelist (in, out, in/out)
  • description: CharacterString [0..1]
  • optionality: Boolean
  • repeatability: Boolean
  • valueType: RecordType [0..1]
  • value: Record [0..*]
smrgeoinfo commented

+1 on the proposal. This will decouple the lineage extensions package from the srv package, which I think is a good idea.