Change Proposal: Remove Process Values

Authors

SimonMiles 2009 July 21, extracted from previous discussion in ChangeProposalRemoveNonCore.

Subject

Core OPM specification

Background

Problem addressed

Values for processes are undefined and ambiguous in the specification, and so unhelpful for interoperability and adoption. It seems that the information which could be conveyed by them would be better expressed in annotations.

Proposed solution

Remove "Processes contain a placeholder for domain specific values or references." from the Provenance Graph Definition.

Define Process as mapped to just a set of accounts in the formalism.

Rationale for the solution

If the value field of a process is just an extensibility point for data about the process, then how is it different from the process node itself? If the process can be annotated arbitrarily, then why would you have one annotation called value whose object is an extensibility point, i.e. something arbitrary?

If we want to express the library name of a process, for example, why not use a libraryName annotation? The process is an instant of that library's execution, not the library itself, so suggesting it is the value of the process in the same way as an artifact's value seems misleading. Similarly for WSDL interface, version number, source code language etc.

Comments

Community is invited to provide comments on proposals.

comment 1 by Luc Moreau

PC3 had a limited set of Questions (I believe not as broad as in PC1/PC2) and therefore didn't exercise the full OPM model. PC1 had a temporal question (Q4) which would require time annotations. Questions 7, 8, 9 of PC1 also refer to a "user", notion intended to be captured by agents. A question such as identify the code that created the database could make use of the value field in a process. So I would be against removing these issues on the ground that we have not used them in PC3. I agree however that more justification/explanation is required. The issue of agents was raised at the first OPM workshop. We should discuss that in its own sake, as is it the right way to model user/funding bodies/etc.

comment 2 by Simon Miles in reply to comment 1

I agree that absence of use in PC3 does not necessarily mean concepts in core OPM are non-essential. However, the fact that a challenge can be completed without using some part could suggest that it is essential only in some circumstances, and so perhaps more suitably expressed in a profile.

Comment 3 by Luc on the revised proposal

I am opposed to removal the value field of processes. Where are we going to attach the library/procedure name? the wsdl interface? The value field is an extensibility point that allows such application specific information to be attached. If a better name "value" is found, I am fine with it. I am also fine with adopting an agreed annotation for this kind of information.

Comment 4 by Simon Miles in reply to Comment 3

I agree that it is important to allow information of that kind to be recorded, but I see it as an argument in favour of allowing annotations on processes.

The problem I have with "value" is that a data artifact, as a snapshot, really does seem to have a value: the data content of that artifact at that instant. It seems ambiguous to talk about the value of a process in the same way.

If the value field of a process is just an extensibility point, then how is it different from the process node itself? If the process can be annotated arbitrarily, then why would you have one annotation called value whose object is an extensibility point, i.e. something arbitrary?

If we want to express the library name, why not use a libraryName annotation? The process is an instant of that library's execution, not the library itself, so suggesting it is the value of the process in the same way as an artifact's value seems misleading. Similarly for WSDL interface, version number, source code language etc.

I have copied this argument to the "rationale" section above, and added it to ChangeProposalAnnotations.

-- JimMyers - 17 Sep 2009

I'm not sure if this proposal is stanalon or is an ammendment to the annotation proposal (I don't think OPM currently talks about a value but could be mistaken...)

In any case, I would argue the same way as for other annotations - if they do not result in additional constraints/inference rule linking the new vocabulary with core OPM, they should not be a profile on the spec. If we need then for the challenges, the challenge should specify what non-OPM voabularies will be used within the challenge

Comment 6 by Simon Miles in reply to Jim above

OPM does currently talk about a process having a value, and this is what I am arguing should be removed.

The proposal is in a sense dependent on annotations being introduced, in that removing process values without adding annotations leaves no way to express metadata. However, there is plenty more lost by disallowing annotations anyway, and the same can be argued for artifacts regardless of this proposal.

Vote

Simon Miles, yes

Luc Moreau, I believe we need to be able to annotate processes (I am assuming therefore that ChangeProposalAnnotations will converge to a satisfactory solution). Given this, I am fine to rename the property value into something more explanatory, hasWsdl, or hasLibrary. So conclusion, conditional yes.

Paul Groth, yes in the context of the annotation proposal

NataliaKwasnikowska, yes, agree with Paul

Jan Van den Bussche, yes, will be replaced by annotations

Joe Futrelle, yes

PaoloMissier, yes, I agree with those who propose to use the general annotation mechanism, assuming it is approved, to capture value information for processes

Outcome

The result of the ballot is: Yes: 7/No: 0.

The outcome is that we will use annotations for such values (or whatever property name we want to use).

-- SimonMiles - 21 Jul 2009
to top