Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
smrgeoinfo opened this issue Jan 23, 2017 · 7 comments
Open

Comments

@smrgeoinfo
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

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

@ebleys
Copy link

ebleys commented May 29, 2017

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
Copy link
Contributor

tedhabermann commented May 29, 2017

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants