Purpose

To share what we know about how people are using Fedora to support workflow, and to discuss potential new technical features for enabling improved integrations. Here's one in particular that we'll talk about: https://fedora-commons.org/jira/browse/FCREPO-454

Attendees

• Ross Wayland
• Asger Blekinge-Rasmussen [*]
• Aaron Birkland
• Andrew Woods
• Bill Branan
• Thorny Staples
• Rick Moore
• Dan Davis
• Carol Minton Morris
• Sandy Payette
• Paul Gearon
• Chris Wilper
• Kai Strnad [*]

[*] limited; had trouble connecting to teleconf#

Notes

• Chris: (introduced motivation of meeting: FCREPO-454)
• Sandy: There is some use of Active/Inactive/Deleted. XACML Policies
• Bill: Code: modify not allowed if "Deleted".
• Chris: Any prob with moving hardcoded to XACML?
• Sandy: deny-*-if-deleted
• Bill: By default, should put policies on a given state?
• Thorny: Case where people want separate workflow "state" vs "active"
• Chris: Similar to what Asger mentioned
• Bill: Used for visibility?
• Chris: Some services do
• Dan: Used state in ERA with external engine
• Rick: Prob with one thing for state is that requirements for BPEL, etc might be different.  Seems better to have workflow state datastream .
• Dan: Having uniform place for some workflow state in Fedora datamodel could help with interop
• Sandy: Could have both; use of existing attribute for easy cases
• Thorny: Helpful to store in FOXML itself, not as part of DS
• Chris: What about storing in one new attribute?
• Sandy: Can still use existing attrib?
• Thorny: Get Stanford's reaction to this (1 or 2 attributes?)  Also, Matthias.
• Rick: In CMSes, having two variables could work for simple cases.
• Chris: Visibility can be controlled with policy.
• Dan: Stanford uses workflow datastream
• Ross: Yes, use it to keep track of object as it goes thru workflow.  They also index this info in Solr, and it helps to manage queues in the workflow.
• Chris: Do they use the state attribute.
• Ross: Don't think so.  Called "Work-Do".  Will see more formal description of 3 workflow models being used in Hydra at OR'09.
• Bill: Any of those workflows considered using a workflow state attribute in Fedora?  Would have been helpful?
• Ross: Haven't got to visibility concerns much yet.  Might be useful to have visibility state as separate.
• Dan/Bill: Value to providing simple low-barrier capability
• Chris: Doing existing attrib vs 2 still a question.  Doing it with 1 doesn't preclude from with with 2 later.  Any problems with this?
• Thorny: More input from workflow-savvy people on 1 or 2 before doing anything.  Doing with 1 first might confuse things.
• Rick: Maybe need to rename "STATE" to visibility, then use a new attrib that is "workflow state".
• Dan/Thorny: (agree)
• Ross: Visibility is an access control issue.  Like a unix filesystem, for example, groups can have read permissions.
• Thorny: Availability / Visibility: inactive is tied to repo admin or object owner.
• Dan: Can provide usecase.  Agree that it seems that the property is one for the repo admin.  If a given object is considered externally accessible, but the workflow says it's only visible to Editors, the AuthZ module may need to do further reflection to see if it's visible to a given editor.
• Rick: Ross, does "availability" make more sense to your user than "visibility"
• Ross: Would use "in process" or "incomplete" then could write policy to disallow access to general public.  Not sure having a separate attribute would really help.  Could just as easily add more existing states and write an appropriate policy for that.
• Andrew: Barrier to entry for using workflow.  Provide workflow engine out-of-box?
• Chris: Not aware of current efforts to do this.  Workflow working group?
• Thorny: Working group effort has ended; didn't deliver an engine
• Sandy: Need to enable for the Mellon grant by end of year
• Thorny: Might make sense to have new WG for this.  Purpose: to provide an engine impl (or recommendations?)
• Thorny: Rutgers has been talking about making an engine available as open source.
• Rick: Fedora-specific
• Thorny: Possibly
• Rick: Can also see what's going on with Paul Allen and participation with Kepler.  Might want to participate if new WG is formed.
• Thorny: Thinks time is right for WG.  More technical than prev group.
• Dan: Volunteers to help with starting this.
• Sandy: Fan of simplicity here, easy entry.
• Thorny: Scope of group?
• Sandy: Inform core features, not sure if would include deliverable of an actual engine.
• Rick: Ideal is to look at who's doing what and provide that as an out-of-box.
• Bill: Implications for FCRepo service still important
• Ross: Hydra group felt activebpel was overkill.  Most use cases they were after were simpler.  Wanted to stay away from heavyweight solutions.  Nice to have workflow info stored inside data object.
• Thorny: This group should be more technical
• Dan: Would volunteer to pull this group together.
• Chris: Will send out followup for another meeting of this group.  In 1 or 3 weeks.
• Sandy: Likes idea of this being more tech group.
• Thorny: Will also be a BOF at OR'09 on this.
• Dan: This meeting would inform this effort.
• Chris: Thanks all...will send email on next steps.