- Attendees
- Agenda
- Current status
- Status of the Taverna plugin
- Status of myexperiment.org
- Status of Plato integration
- Status of toolwrapper/component publishing
- Profiles
- Other open issues
- Notes
- Taverna Component Plugin status
- myExperiment status
- PLATO integration
- Toolwrapper/Component publishing
- Updates to Wiki
- Dependencies
- Actions
- Decisions
Attendees
- Donal Fellows (UNIMAN)
- Finn Bacall (UNIMAN)
- Markus Plangg (TUW)
- Hélder Silva (KEEPS)
- Carl Wilson (OPF)
- Christoph Becker (TUW)
- Alan Williams (UNIMAN)
Agenda
Current status
Status of the Taverna plugin
- Last published version
is 0.2
Allows to select individuals, issues with permissions of published components, Missing SCAPE specific GUI. - Latest source
is 0.3-SNAPSHOT
Allows selection of permissions. Missing SCAPE specific GUI?- Migration Paths
- Parameters
- Some smaller problems when using plugin
Status of myexperiment.org
- Sandbox vs normal version?
Which should we use for testing? - Sandbox
Newer REST version on sandbox? Taverna plugin cannot "Copy component" to sandbox. Upload via webpage shows 500 error. - Normal
Query does not find components: e.g. this queryshould find http://www.myexperiment.org/workflows/3426.html
Status of Plato integration
Status of toolwrapper/component publishing
Profiles
Updates to Wiki? http://wiki.opf-labs.org/display/SP/Preservation+Component+Profiles
Other open issues
Dependencies
Currently selecting individuals generated from debian Packages file.
The debian repository only contains stuff packaged by scape, e.g. imagemagick convert wrapped by toolwrapper but not the imagemagick package itself. This is quite restrictive as does not allow to create a dependencies outside of the toolwrapper.
Get licence of packages from Debian repository?
Notes
Taverna Component Plugin status
Work in progress, mainly on addressing how to deal with publishing a component with an appropriate license. Release policy complex because of coupling to myExperiment updates. Markus is experimenting with 0.3-SNAPSHOT version retrieved from source repo. Work required on supporting open-world properties (i.e., string valued or string+defined sample values). Support for complex properties requires a SCAPE-specific plugin? (What happened to the proof of concept stuff that David was working on? Was it just demonstrating viability of the SPI for refined GUIs?)
Note: it is strongly desired to have one component supporting multiple migration paths. (E.g., imagemagick can convert almost anything to a defined format)
myExperiment status
Sandbox is ahead of main site, but has some 500 failures. Still, use that for testing.
Querying doesn't know ontology at all, and doesn't currently support any query that has anonymous nodes in (i.e., only shallow queries). Finn looking at fixing, but requires improved RDF querying support for Ruby. Carl said in chat that he knows some people to ask.
PLATO integration
Mainly blocked waiting for improved ability to query.
Toolwrapper/Component publishing
Possible issue to do with addition of description how to do extraction of metrics from characterization tools; should this go in the component or be done externally? (If the former, the input descriptor document needs to give the information.)
For now, will use Taverna to do any extraction necessary as it has many suitable shim services (XPath, Beanshell, etc.)
Updates to Wiki
Substantial amount of text was deleted from page by Asger Blekinge; need to review those changes. (Main change appears to be removal of “Quality assurance property comparison component” section; is this something we desire? Can't just roll back; there are subsequent less-controversial changes by someone else.)
Dependencies
How to gather information about what debian packages are depended-upon and to put that information in the component (so that tools can query over it). Package names and versions are not closed-world entities; licenses are closed-world (or at least we can maintain a list). License information cannot come from Debian package descriptors (which just don't have the info, unlike with RPM spec files) but they are described in the SCAPE toolwrapper/component descriptor.
Information should be attached to the tool service node in the workflow, not to the top level. (Deals with case where multiple tools are used in one component.) Need RDF for doing it, but not expected to be problematic.
Actions
ACT.130307.01 Finn: Give estimate for how long it will take to improve querying over RDF in myExp. (Key Q: In time for us to demo at review or not?)
ACT.130307.02 Finn: Check whether myExp supports OR queries (needed for component license checks given that there's no ontology support)
ACT.130307.03 Finn: Check timeline for updates to myExp; when will things go live?
ACT.130307.04 Finn: Allow myExp to tolerate anonymous nodes; mustn't crash!
ACT.130307.05 Finn: Solution for how to do SCAPE-specific queries for review.
ACT.130307.06 Carl: Review wiki changes properly (also Markus)
ACT.130307.07 Carl: Ask Asger about his changes
ACT.130307.08 Markus: Check if Bolette's changes make sense in detail
ACT.130307.09 Markus: Create characterization example
ACT.130307.10 Markus: Use jplyzer as example (coordinate with Carl, Johann, TUW)
ACT.130307.11 Alan: Update plugin (0.9?)
ACT.130307.12 Alan: SCAPE-specific GUI for migration path & parameters
Decisions
DEC.130307.01: Location of tool description RDF in component workflow: on tool, not on workflow.
DEC.130307.02: Keep components that wrap tools simple prior to review.