Profile Guidance

Authors

Paul Groth - Sept. 22, 2009

Subject

This proposal suggests changing the Governance document to clarify OPM profiles.

Background

Before and during PC3, a variety of community participants noted that having a mechanism to extend OPM without alternating the core OPM was needed. It was proposed that this could be done through the introduction of profiles that defined extensions or specializations of core OPM. The Governance document included the following paragraph on profiles:

==OPM Profiles, i.e. specializations of OPM, with specfic focus or for spe- cific application domains are encouraged. Authors should feel free to submit such profiles by posting them on the OPM twiki. To gain community endorsement, such profiles should go through the same revision process.==

However, during the discussion of change proposals for OPM v1.1, confusion about the role of profiles and their intended use arose. Additionally, the meaning of "endorsing" a profile is not clear. See

• ChangeProposalMoveTimeToProfile
• ChangeProposalDublinCoreMapping

Problem addressed

Confusion over what a profile is and what endorsing a profile means.

Proposed solution

The proposed solution is to add the following text to the governance document to better define profiles and endorsement:

1. A profile is a specialization or extension of core OPM.
2. Any additional syntax that a profile introduces must be able to be translated to core OPM.
3. Endorsement of a profile means wide acceptance by the community as shown by multiple users/implementations and a community vote.

Rationale for the solution

The solution provides required guidance without being overly cumbersome.

Comments

Community is invited to provide comments on proposals.

Comment by Paolo

(2) seems to imply that extensions should be expressible in the core. If this is the case, then I guess the Time proposal should be rejected on the grounds that if you take it out and make it into a profile, then there is no other way to express temporal dependencies in the core?

Response to Paolo by Paul Groth

My first response would be yes as it's hard to convert temporal dependencies with causal links. But if time is just an annotation then it's compatible with the core even if it were in a profile. It depends on how rich you want to make any time profile. Personally, I think time should remain in the core part of OPM.

-- JimMyers - 23 Sep 2009

re: 2 - I tried to frame two options for profles in a comment buried on one of the proposals: things that make sense as metadata that we find ourselves wanting to include in provenance searches, e.g. author/creator, versions, etc. and things more like time where not only do we want to seach for them, but core OPM statements can constrain them (the creation date of the output should not be before that of the output). (Creator and version may fit the latter category as well but assume they don't for now.) I was arguing there that only the latter should be a profile but I think either definition would work (and if we don't allow profiles of the first kind, I'd still like the community to sway opinions by, for example, identifying Dublin Core, etc. as used in the provenance challenges). In any case, I'm not sure how to ma these definitions to a 'must be able to be translated to core OPM' phrase - is that more like my latter definition where you want some interaction between the profile and the core? If so, would a broader definition that profiles should define metadata that can translate to OPM core concepts, or can be inferred/constrained by core OPM or vice versa? Time keeps coming up as the best example, but the connection between agent and dc:creator, versioning and causal dependence, etc. might be things that could be formalized enough to make those vocabularies connect with core OPM.

re:3 - Do we want votes to mean endorsement versus something more like an assessment of consistency. I'm more interested (for example) in stopping a profile about 'colors' that claims one can infer the colors of output objects from that of input objects where we think the inference is not true for all processes than stopping a "2nd Law" profile that argues one can always infer that the entropy of all outputs is greater than that of all inputs and that provenance can be used to infer constraints on entropy values and or missing inputs/outputs. While this latter example may not be used, I would guess that it is (at least at the level of the example) consistent with the semantics of process as the OPM community thinks about it whereas the first one is not.

I guess this leads to an argument that a yes vote on a profile should mean that the OPM community agrees that the profile is conistent with the core OPM semantics - it adds some new semantics but does not alter the core semantics.

Joe Futrelle

Since I was pushing for the notion of a profile, I'll try to help here.

Profiles need not extend the semantics of OPM. They can just be usage guidelines--this is a common and useful sort of profile that is used among digital library curators as they use metadata standards that provide them with choices of how to represent information. A profile can guide how someone generating the metadata should make those choices.

For example in OPM a profile might just specify a controlled vocabulary for annotations, to meet some specific interoperability use case. Again, if the OPM model just provides a way of associating an annotation with an OPM node, but doesn't limit which annotations one can use, the profile is there to provide guidance and in that case could even be used to automatically determine if an OPM graph is consistent with the profile (e.g., it isn't missing a "required" annotation from the profile).

OPM graphs conforming to these two kinds of profiles (guidance, guidance + controlled vocabulary) need not be translated into core OPM, because they're core OPM graphs to begin with.

Further, a profile could specialize or generalize the OPM model. Again, translation of an OPM graph conforming to such a profile into a core OPM graph just means ignoring the more general and more specific parts of it. That is analogous to Dublin Core's notion of "qualification" or "graceful degradation". Qualified DC elements are just specializations of elements from the unqualified model, so you can replace them with unqualified terms without violating the semantics of the unqualified model.

If a proposal changes the core semantics of OPM I don't think the term "profile" is appropriate. That kind of proposal needs to be handled with a different, more heavyweight process. The notion of profile serves to facilitate a lightweight process for reaching agreement around a standard without embroiling the standard revision process in the minutia of use cases that don't really affect the core model. But there's no way around the heavier-weight kind of agreement needed on the semantics of a widely shared standard.

Part of the value of profiles is that they explicitly don't need broad agreement. A profile can represent an agreement between some set of users of a standard about how to use it, without impacting other sets of users.

So my vote is no: I see a useful distinction being blurred between refinement of OPM and modification of OPM, and under this proposal we're out of sync with the way the term "profile" is being used in other directly relevant communities, such as digital libraries.

---

Comment by Luc

The tentative proposal we wrote on collections is a good example of what I would call a profile. Subclasses of processes and artifacts, and rules. An OPM graph compliant with the collection profile can be converted in an OPM graph, where there is no requirement to know anything about the profile.

I think that Paul made a mistake in his description by saying specialization or extension of core OPM. The collection profile was a specialisation of OPM. An extension is something totally different: for instance, I introduce a notion of probabilistic causal dependency. This would require an entirely new semantics to OPM.

So, if a profile designer establishes that the intended meaning of its profile is fully captured by a translation into core OPM, then it means that we are not changing the meaning of OPM. Of course the outcome may not necessarily be consistent and useful. A profile that states that from any A1 -> A2 edge we can infer A2 -> A1, then we would have broken one of the rules of OPM. It simply means we cannot express anything consistent with such a profile, according to the OPM semantics.

So, Joe seems to argue against Paul's proposal because of the term 'extension of'. It should be removed.

Joe says that some profiles may not require a translation to OPM (in fact, the translation is the identity function). That's correct (say, when you define a set of edge types for a given application domain, and you don't have any other inferences).

I would suggest that the definition of proposal should make these points very clear.

I don't know whether the hierarchical refinement is a profile or not. That was one of my questions.

---

---

Vote

-- PaulGroth - 22 Sep 2009, yes

-- NataliaKwasnikowska, yes (the proposal for multiple hierarchical refinement is an extension to OPM)

-- PaoloMissier - 23 Sep 2009, yes.

Jan Van den Bussche, yes

Joe Futrelle, no

Luc Moreau, yes if we remove 'extension'

Outcome

Vote count: yes: 3/conditional yes: 1/no: 1.

Profiles are a key notion of our OPM philosophy. It's important to get their definition right. It is proposed that this definition is refined till we obtain unanimity.
to top