Change Proposal: Move the Time-Annotated Model from the Core to a Profile
Authors
SimonMiles
2009 July 21, extracted from previous discussion in
ChangeProposalRemoveNonCore.
Subject
Core OPM specification
Background
Along with other proposed changes, the aim is to remove possible unnecessary complexity and length of the specification, and the discouragement of adoption which that may bring.
Problem addressed
The time-annotated model is not essential to using the rest of the core model so, I argue, adds length and complexity to it unnecessarily.
Proposed solution
Remove the time-annotated model and formalism and put them into a profile instead.
Rationale for the solution
Time is not obviously essential to causality, whether defined purely in terms of use, derivation and generation, or by a general definition such as counterfactual causation. The debate over how best to provide annotations of time could be held separately from the core model. The time annotations seem an ideal candidate for putting into a profile.
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
With the timed OPM model, what seems to be added are particular kinds of annotation for answering particular kinds of provenance question. I agree time is important and interoperability requires some standard way to include it with OPM data, but what would be lost by putting this in a profile? Moreover, separating the core causal graph model from the time-annotated model allows each to be refined separately. For example, if the community successfully argued that the time annotations should explicitly identify the clock from which the time readings came, then this could change the profile without affecting users of the core model.
comment 3 by Ben Clifford
I agree that time be removed from the core specification and made into a profile . The present OPM time stuff feels to me to be like "just another annotation".
Comment 4 by Luc on the revised proposal
Is this a cosmetic change or a fundamental change? I don't understand. I think we are stating that the way to provide time annotation is the one we propose and not any other. This does not seem to be a profile to me.
Comment 5 by Simon Miles in reply to Comment 4
It is not a fundamental change, but one for the purposes of usability and management of the specifications. As we will probably do with collections (
ChangeProposalMoveCollectionsOut), I don't think putting something in a profile means it is not important for interoperability or that there is not a standard way to do it. But I think that there are good reasons for not having the annotations in the core specification.
First, anything which simplifies and reduces the length of the core specification means there is less of a psychological barrier to adopting it. Second, it is not necessary for the rest of the core model: people can start recording in OPM and then look at the time annotations profile when they need to record those annotations. Third, it is untested: as said in Comment 1, PC3 did not test everything through its queries and this is an aspect that was not tested. Fourth and related to the last point, the time model is not undisputed (I believe Ben disputed it in the workshop) and it can be argued over separately from the rest of the core specification without hampering the stabilisation of the core.
Comment 6 by Luc in reply to Comment 5
Abundance of optional profiles fail to lead to inter-operability. We must be careful: an opm specification that is too thin will be perceived as vacuous. Whenever I spoke about OPM, i had questions about time, especially from computer scientists, because it's so important. Several things are untested (e.g. accounts), doesn't mean they shouldn't be in the specification.
Comment 7 by Paolo Missier
After reading all of your comments I was tempted to vote "yes" right away on grounds that are similar to those that Simon stated. However, it seems to me that the discussion arises from an ambiguity in the purpose of profiles. I would like to see the spec as moving towards modularity, without necessarily implying that some of the modules are optionals. If adding profiles is currently the only way we can modularize, and we assert that those are optionals, then we are probably not using them properly?
Would it help to say that profiles provide modularization, and some of them are optional?
If we agree on making this distinction, then I would vote for extracting Time into a non-optional profile.
More generally, have we ever clarified what it means for a part of the spec to be optional, i.e., do we have compliance levels associated to implementations of OPM.
Comment 8 by Simon Miles in reply to Comment 6, 7
I agree with Paolo. I assumed profiles were "optional" only in the sense that you could use OPM without any particular profile if you don't need its contents, but are non-optional in the sense that if you want to do something particular covered by an endorsed profile (express time, collections, map from dublin core etc.) you must follow that profile to preserve interoperability and allow tools to make use of the effects of that profile. This is effectively the same as saying profiles are modules of the core spec that you won't always need.
I personally don't think the core spec is in any danger of being vacuous as long as it retains a coherent definition of annotated causal graphs, but this may be my stance on the complexity standards should have - I prefer SOAP to BPEL any day :-). I can't really see the difference in argument between the proposals to move time to a profile and to move collections to a profile, and I agree with both.
comment by Joe Futrelle
Tough call. My vote is no, because the spec is already written so that OPM graphs without time annotations are complete and coherent. As long as it's clear to readers of the spec that time annotations are optional, there's no problem (as a point of comparison, imagine the utility of HTTP/1.1 without its detailed development of HTTP caching semantics). I disagree with Simon's statement that collections and time would be the same kind of profile and so should be handled identically--timing bears directly on causality in a way collections (as I understand them) don't.
comment 9 by Paul Groth
I was under the (maybe wrong) impression that profiles could "compiled down" into the core OPM spec. So, for example, we can convert the collections representation into an plain old OPM Graph. However, it's hard to think how time annotations (which seem primary) can follow this compiled down approach. Also, I agree with Joe that time is directly related to causality as far as I know.
Additionally, along the lines of what Paolo was saying, I think we discussed the idea of Profiles becoming endorsed while other profiles would remain optional. This should be detailed somewhere perhaps in the governance doc.
comment 10 by Jan Van den Bussche
An annotation of an OPM graph with time instants is more than just yet another annotation. Time annotations of OPM graphs are the semantic structures that underly the temporal semantics of OPM.
Vote
Luc Moreau, no (since we want a unique way to represent time, I think, and profiles are essentially optional).
Simon Miles, yes (but with caveats on the status of profiles, see comments 7 and 8 on optionality)
Joe Futrelle, no
Paul Groth, no
NataliaKwasnikowska, yes if a profile is seen as an extension of OPM
PaoloMissier - 23 Sep 2009, no -- subject to approval of
ChangeProposalProfileGuidance
Jan Van den Bussche, no see my comment
Outcome
The ballot (No: 5, Yes: 2).
Given that profiles are intended to be translated into core OPM, then it is not possible to express time as a profile. The concern of modularity is
important, and we need to make sure that Time OPM is described in a distinct section (as it currently is).
So proposed resolution: No.
--
SimonMiles - 21 Jul 2009
to top