...
- Ross Wayland (UVA/Hydra Project)
- Asger Blekinge-Rasmussen (State+Univ Lib of Denmark/DOMS Project)
- Aaron Birkland
- Andrew Woods
- Bill Branan
- Thorny Staples
- Rick Moore
- Dan Davis
- Carol Minton Morris
- Sandy Payette
- Paul Gearon
Notes
Intro of 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.
...