Skip to end of metadata
Go to start of metadata

Agenda and Minutes

Coordinator: Khalid

Apologies: Marco

Participants: Oscar, Graham, Sean, Rafa, Raúl, Piotr

Call will use Oxford's Webex: http://www.wf4ever-project.org/wiki/display/private/Telecons#Telecons-ARCHTFTelecon

Chat log: WebEx Chat Log

What are the next steps with the RO model? 

Minimal information model. Matt will present something next week.

Preservation, digital libraries and the layer cake: We started the discussion with the figure about the layer cake created by Carole.

Based on this, we have mainly concentrated so far on the lower part (the concrete implementation), which makes sense for the time being, but we need to abstract out and provide clear documentation about what we are doing, and what we can and cannot do with the concrete implementation, in terms of the tasks that users have to do for the preservation of their workflows. 

Raúl also commented (e-mail sent 18/10/2011) about the current activity in dLibra for including preservation of digital objects, with the following modules (which should be all available by the end of 2012):

  1. Data management module, including ingestion, retrieval and visioning of digital objects. Metadata for each object is stored in the METS format.
  2. Data modification module, including migration services, conversion services and advanced data delivery services. In order to provide migration, conversion or delivery support for particular type of object a new service has to be developed and registered in the system.
  3. Migration management module, which is responsible for monitoring the data. Based on the monitoring results (e.g. by assessing risk of data loss for particular data format) it will automatically perform migration and/or send notification to administrator.
  4. OAI-PMH module which is primarily responsible for publishing metadata via OAI-PMH. It is also possible to set up a central system which aggregates metadata from local ones and then acts as a central access point to metadata.
  5. Rights management module, which determines access rights of users to objects.

There was also some discussion about how much dLibra is OAI-oriented.

  • Graham: last time I looked, OAI-PMH was XML based, needing declared schema for exported metadata.  OAI-ORE as used for RO manifest is RDF.  Is there intenbded to be any overlap here?  E.g. are you thinking OAI-PMH can be used to harvest RO manifest metadata?
  • Raúl: @graham, where is OAI-ORE used for RO manifest? THe OAI-PMH could be used to harvest manifest metadata, but we haven't really talked about this yet, do you have some particular scenario in mind? 
  • Graham: @raul per http://www.wf4ever-project.org/wiki/display/docs/RO+model ORE is used for specifying aggregation in RO

As a result, the following actions were identified:

  • ACTION (Oscar/Gema, next RO call): provide a list of the micro-services from one of the tools that Gema presented, and checklist whether they are applicable to our preservation requirements, and how they are related to preservation-related tasks of users.
  • ACTION (Oscar/Gema/Raúl, next RO call): take thisgrouping of new preservation modules in dLibra, combine it with the list of micro-services aforementioned, and checklist how many of those services and broad functionalities are needed by our Astro and Bio users. This action subsumes the previous one.
  • ACTION (Oscar): once the list is ready, put it on the wiki to gather comments from everybody. It will be here.
  • ACTION (Raúl/Gema/Rafa): assessment of OAIS compliance of dLibra, and preservation functionality compliance of dLibra

Preservation as you go or Curation as you go. Sean commented that in digital libraries it seems that preservation is an explicit action. Why don't we try to see whether it is possible to make it occur as an implicit action, that is, a byproduct of normal activity.

  • No explicit action, but consider this as a very interesting possibility to make preservation more lightweight, although still considering a preservation methodology.

Workflow Decay: What are the different classes of workflow decay?

We need to describe what we mean by workflow decay. For instance, the iPRES paper a useful starting point for discussing workflow decay.

Examples:

  • Graham: Focus on external dependencies that might change.
  • Khalid: Decay of the service being used
  • Oscar: Decay on the type of data that can be accepted (example of protein names that Daniel had to fight with in his work with Yolanda Gil).

The following actions were agreed:

  • ACTION (all): prepare a set of examples of workflow decay in our use cases and also external (e.g., Daniel's example of proteins' decay in his work with Yolanda) and discuss about it in a specific RO call
  • ACTION (Oscar): ask users about workflow decay examples

Are annotations used for describing the RO and its components part of the RO?

There was an agreement that for the time being we will consider that annotations are conceptually part of the RO (physical inclusion is just an implementation issue). And we will see later what happens.

  • Potential advantages of having them as part of the RO: we have the context of where the annotations were made
  • Potential disadvantages: what would happen then if somebody (RO creator or 3rd party) adds annotations later? What happens with inconsistencies between annotations? (this last point could be also valid in the case that annotations are part of the RO, although more relevant with 3rd party annotations).

This has an impact on the evolution model: if one adds annotations, is that a new version of the RO? Is that covered by the RO evolution model? When should we consider that a new version is created? It seems that we should determine which are the elements that are important to determine a new version of an RO: if a dataset changes, is this something that can generate a new version? if an annotation is added, is this something that generates a new version?

We may have multiple forms of nesting: an RO may have annotations inside, but then there could be other annotations about the RO that are included in another RO that includes that RO (Groucho Marx dixit ;-))

The MIM work may have something to say about "fixing" some internal annotations for ROs.

No actions.

Actions

  • ACTION (Oscar/Gema, next RO call): provide a list of the micro-services from one of the tools that Gema presented, and checklist whether they are applicable to our preservation requirements, and how they are related to preservation-related tasks of users.
  • ACTION (Oscar/Gema/Raúl, next RO call): take thisgrouping of new preservation modules in dLibra, combine it with the list of micro-services aforementioned, and checklist how many of those services and broad functionalities are needed by our Astro and Bio users. This action subsumes the previous one.
  • ACTION (Oscar): once the list is ready, put it on the wiki to gather comments from everybody.
  • ACTION (Raúl/Gema/Rafa): assessment of OAI compliance of dLibra, and preservation functionality compliance of dLibra
  • ACTION (all): prepare a set of examples of workflow decay in our use cases and also external (e.g., Daniel's example of proteins' decay in his work with Yolanda) and discuss about it in a specific RO call
  • ACTION (Oscar): ask users about workflow decay examples

Next Call

Next call: 26/10/2011 (main topic: Minimal Information Model)

  • No labels